On Fri, Dec 12, 2014 at 04:33:38PM -0500, Rob Clark wrote:
> On Fri, Dec 12, 2014 at 3:57 PM, Laurent Pinchart
> wrote:
> > Hi Rob,
> >
> > On Wednesday 10 December 2014 12:17:51 Rob Clark wrote:
> >> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> >> formats. Especially in t
On Sat, Dec 13, 2014 at 7:08 PM, Ben Widawsky
wrote:
> Any GEM driver which has very large objects and a slow CPU is subject to very
> long waits simply for clflushing incoherent objects. Generally, each
> individual
> object is not a problem, but if you have very large objects, or very many
> ob
If we're moving a bunch of buffers from the CPU domain to the GPU domain, and
we've already blown out the entire cache via a wbinvd, there is nothing more to
do.
With this and the previous patches, I am seeing a 3x FPS increase on a certain
benchmark which uses a giant 2d array texture. Unless I m
The caller of the cache flush APIs can sometimes do useful things with the
information of how the cache was flushed. For instance, when giving buffers to
the GPU to read, we need to make sure all of them have properly invalidated the
caches (when not using LLC). If we can determine a wbinvd() occur
Any GEM driver which has very large objects and a slow CPU is subject to very
long waits simply for clflushing incoherent objects. Generally, each individual
object is not a problem, but if you have very large objects, or very many
objects, the flushing begins to show up in profiles. Because on x86
When the original drm code was written there were no centralized functions for
doing a coordinated wbinvd across all CPUs. Now (since 2010) there are, so use
them instead of rolling a new one.
Cc: Intel GFX
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_cache.c | 12 +++-
1 file ch
While looking at a recent benchmark on a non-LLC platform, Kristian noticed that
the amount of time simply spent cflushing buffers was not only measurable, but
dominating the profile. It's possible I'm oversimplifying the problem, but it
seems like for cases where we have a slow CPU, and when you k
page 267402830, read from TC (72)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141213/6559c228/attachment-0001.html>
thout dynamic power managemenent for the GPU.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141213/55389559/attachment.html>
close it and I'll
reopen if it happens again.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141213/631af226/attachment.html>
Kernel: 3.18.0-rc7
libdrm: 2.4.58
mesa: git-gc97cbd7
llvm: 3.5
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141213/cc29b
d a few times:
radeon: The kernel rejected CS, see dmesg for more information.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachment
he bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141213/e28a3bab/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=89661
--- Comment #1 from Bernd Steinhauser ---
Created attachment 160441
--> https://bugzilla.kernel.org/attachment.cgi?id=160441&action=edit
Picture of the kernel panic output
--
You are receiving this mail because:
You are watching the assignee o
https://bugzilla.kernel.org/show_bug.cgi?id=89661
Bug ID: 89661
Summary: Kernel panic when trying use amdkfd driver on Kaveri
Product: Drivers
Version: 2.5
Kernel Version: 3.18.0 + drm-next branch
Hardware: x86-64
OS: Linux
hics detail + FXAA + 2xSSAA). It can also of course change
with future updates.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/201
When compiling in module some symbol aren't missing,
export them correctly.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drm_plane.c | 1 +
drivers/gpu/drm/sti/sti_hqvdp.c | 1 +
drivers/gpu/drm/sti/sti_layer.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/driver
|normal |major
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141213/843e0617/attachment.html>
his mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141213/35e913d4/attachment-0001.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141213/ded4b227/attachment.html>
sts.freedesktop.org/archives/dri-devel/attachments/20141213/c0edd7de/attachment.html>
Add the necessary set of commands to support OpenGL
indirect draw calls on evergreen/cayman devices that
do not have VM.
Signed-off-by: Glenn Kennard
---
Changes since patch V1:
* Removed multi draw indirect, not used by current userspace which instead
decomposes multi into separate draw indire
Hi Mark,
Thanks for review.
Mark Brown wrote on 12.12.2014 17:36:
> On Wed, Dec 10, 2014 at 04:48:19PM +0100, Andrzej Hajda wrote:
>> track is a generic framework for safe tracking presence of any kernel objects
>> having an id. There are no special requirements about type of object or its
>> id.
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141213/dc78d686/attachment.html>
24 matches
Mail list logo
