If we failed to create textured pixmap from BO's handle, we
turn to create a new glamor pixmap by call glamor_create_pixmap
rather than fallback to in-memory pixmap. Have to introduce
a new wrapper function intel_glamor_create_pixmap.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
And propagate that failure back to the client.
Reported-by: Paul Neumann <paul104x@yahoo.de>
References: https://bugs.freedesktop.org/show_bug.cgi?id=43716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When we try to create a glamor pixmap and fail we need to create a real
pixmap along with its pixel allocation, instead of detaching ourselves
and returning the fake pixmap header.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The danger of the early return when UXA is not using glyphs is evident
in the eventual crash when glamor begins evicting and reusing its glyph
cache slots.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Don't attempt to dereference the NULL gpu_bo after having just freed it.
Here in lies the folly of trying to blindly silence the compiler.
Instead we should heed the error return as it means that we didn't
decouple the pixmap from the inactive list and so we choose to place it
back on the active list to purge again in the near future.
Reported-by: Paul Neumann <paul104x@yahoo.de
References: https://bugs.freedesktop.org/show_bug.cgi?id=43716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the event of failure, we choose to loose track of the damage and
choose rendering corruption over crashing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This commit hooks up all the remaining rendering routines to call into
glamor; the takeover is nearly complete! When tested with the latest
glamor master branch, it passes rendercheck.
One thing need to be pointed out is the picture's handling.
Pictures support many different color formats, but glamor's
texture only support a few color formats. And the most common
scenario is that we create a pixmap with a color depth and
then attach it to a picture which has a specific color format
with the same color depth. But there is no way to change a
texture's internal format after the texture was allocated.
If you do that, the OpenGL will allocate a new texture. And
then the glamor side and UXA side will be inconsitent. So
for all the picture related operations, we can't fallback to
UXA path directly, even it is rather a straight forward
operation. So for the get_image, Addtraps.., we have to add
wrappers function for them to jump into glamor firstly.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
[ickle: prefer access; ok = glamor(); finish; if (!ok) goto fallback; return; ]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
intel_glamor.c: In function 'intel_glamor_create_screen_image':
intel_glamor.c:192:12: warning: variable 'pixmap' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we now defer the allocation of pixel data until first use, it can
fail in the middle of a rendering routine. In order to prevent chasing
us passing a NULL pointer into the fallback routines, we need to propagate
the failure from the malloc and suppress the failure, discarding the
operation, which is less than ideal.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The cpu bo is only allocated on LLC systems, so do avoid the NULL deref on
debugging for others.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since we can not keep an unlimited number of vma cached due to the hard
per-process limits on the number of mappings and recreating mappings is
slow due to excruciatingly slow GTT pagefaults, we need to compromise
and keep a small MRU cache of inactive mmaps.
This uses the new API in libdrm-2.4.29 to specify the limit upon the VMA
cache maintained by libdrm.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
libdrm expires its bo 2s after entry into the cache, but we need to free
a buffer to trigger the reaper. So schedule a timer event to trigger 3s
after the last rendering is submitted to free any resident bo during
long periods of idleness.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A poor cousin to vmap is to instead allocate snooped bo and use a CPU
mapping for zero-copy uploads into GPU resident memory. For maximum
performance, we still need tiled GPU buffers so CPU bo are only useful
in situations where we are frequently migrating data.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the happy scenario where the pixmap only resides upon the GPU we can
forgo the CPU allocation entirely. The goal is to reduce the number of
needless mmaps performed by the system memory allocator and reduce
overall memory consumption.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In benchmarking firefox this performs whose - it would appear the
sources are indeed used more often than not.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For large render targets, we prefer to use tiled bo in order to avoid
severe performance degradation. However, if we don't have a GPU bo but
do have a CPU bo and the operation would be untiled, then simply use the
CPU bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In theory we should be able to disable dual-stream mode and so be
subject to much looser restrictions (such as the pitch need only be
dword aligned). However, achieving single-stream mode seems quite
difficult!
Reported-by: Paul Neumann <paul104x@yahoo.de>
References: https://bugs.freedesktop.org/show_bug.cgi?id=43706
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Our goal is to achieve "single-stream" rendering where the entire
RenderCache is allocated to the colour buffer (rather than split between
colour and depth). In theory all that is required is for the pipeline
not to reference the depth buffer at all, however it is not made clear
when that evaluation is made.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Zhigang Gong
Chris Wilson