| Age | Commit message (Collapse) | Author |
|---|
|
The support for XRGB8888 appeared in the 855 and 865, and this format
is reserved on 830/845. This should fix a regression from
b4a6169412819cc3a027c6a118f0537911145a30 that caused hangs in etracer
on 845s.
Bug #26557.
|
|
Otherwise, we'd run into minlod > maxlod, and the sampler would give
us the undefined we asked for.
Bug #24846. Fixes OGLC texlod.c.
|
|
Fixes piglit fxt1-teximage since
7554b83a21bd62b20df5a7327b69f08108ac9ab6, and also OGLC tests that hit
FXT1 with a million other things.
Bug #28184.
|
|
|
|
|
|
|
|
The pixel transfer rules state that we must set alpha to 1.0 in this case
which we can't easily do with the blitter. We can do to passes: one that
sets the alpha to 0xff and one that copies the RGB bits or we can just
use the 3D engine. Neither approach seems worth it for this case.
|
|
This adds TFP support to the swrast driver, with this I can run gnome-shell inside Xephyr slowly. I've no idea why I did it, and g-s has other rendering issues under swrast, but it might be useful to hook up llvmpipe later. I've no idea if I even want to commit it at this point.
An enhanced version might just pass the pointer in the indirect rendering case
and avoid the memcpy.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This fixes an uninitialised value use in the dri2 st when doing TFP.
It uses the driContextPriv which isn't initialised at alloc time.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Fixes the assert (and buffer overrun):
glknots: intel_batchbuffer.c:164: _intel_batchbuffer_flush: Assertion
'used >= batch->buf->size' failed.
Reported in bug:
Bug 28274 - xscreensaver's glknots hangs GPU (945GME/Pineview)
https://bugs.freedesktop.org/show_bug.cgi?id=28274
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Yes I am fixing r300c ... who knew?
|
|
This will help in bufmgr debugging and aub dumping.
|
|
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Use _mesa_meta_GenerateMipmap. It is Fast Enough(tm).
Signed-off-by: Maciej Cencora <m.cencora@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
When generating or uploading a new (higher) mipmap level for an image,
we can need to allocate a miptree for a level greater than
texObj->MaxLevel.
Signed-off-by: Maciej Cencora <m.cencora@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
This can happen when checking if a software fallback for a higher level
operation (such as GenerateMipmap) is needed.
Signed-off-by: Maciej Cencora <m.cencora@gmail.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
We could potentially do this on G45 as well, though the units are
different. On 965, the timestamp is tied to hclk, which would make
supporting it harder.
|
|
|
|
|
|
This is a workaround for Ironlake errata. The emit_mi_flush is used
for a few purposes:
1) Flushing write caches for RTT (including blit to texture)
2) Pipe fencing for sync objects
3) Spamming cache flushes to track down cache flush bugs
Spamming cache flushes seems less important than following the docs,
and we should probably do that with a different mechanism than the one
for render cache flushes.
|
|
|
|
Reported-by: Gianluca Anzolin <gianluca@sottospazio.it>
|
|
|
|
Needed for vertex shaders too.
|
|
|
|
We should be able to do 16, but are limited by Mesa's static buffer
allocations.
|
|
If you used all 4 color targets we currently support, we would see 0
and end up just writing the first output. Give enough bits that we
can do the maximum of 16.
Fixes piglit fbo-drawbuffers-maxtargets.
|
|
The idea would be that you could have multiple send messages going on
if nothing depended on the previous message's results and you used a
different send message. The problem is that the later send requires
the VUE handle returned by the first send's allocate anyway.
|
|
Before we would throttle in the flush callback prior to round-tripping
to the server to do copyregion or swapbuffer. Now, instead just note
that we need to throttle and do it in intel_prepare_render(), which
will be called after receiving the response from the server but before
we start rendering the next frame. Even if the server also throttles
us in swapbuffer, this just makes the throttling a no-op when we hit
intel_prepare_render(). With that we can drop the
using_dri2_swapbuffers hack and just always throttle.
|
|
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
Signed-off-by: Marek Olšák <maraeo@gmail.com>
|
|
|
|
|
|
|
|
This basically restores the previous state, where a vertex result slot
is set up for the texcoord to be replaced with point coord. Fixes
piglit point-sprite test.
Bug #27625
|
|
|
|
The initial call to intel_draw_buffers() happens when
intel->ctx.DrawBuffer is still NULL. Call it again after
calling _mesa_make_current().
https://bugs.freedesktop.org/show_bug.cgi?id=28112
|
|
This is trying to follow the spirit of the invariance rules, though
they're not specific on this point. Fixes quad-invariance piglit test
while retaining the 22s -> 18s win on glean blendFunc.
This was a regression in c67d9d84f501f145f841c0b981caff6f4dfd936f.
|
|
GL doesn't actually let you begin an OQ while one is active, so the
extra work was pointless.
|
|
|
|
Tested-by: Marek Olšák <maraeo@gmail.com>
|
|
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
|
|
Bug #24470: glean clipFlat test.
|
|
|
|
|
|
The RGBX version isn't supported as a vertex input type, but since we
force the last channel's value anyway, this should be fine. The only
potential risk I see is in the limiter on VBO reads past the end of
the buffer forcing the whole vertex to 0 when the A channel lands past
the end.
Fixes piglit draw-vertices-half-float.
|
|
|
|
|
|
Note that we don't support arbitrary block size for compressed quite
yet -- block height of 4 is hard-coded all over the place.
Bug #27098 (srgb dxt1 producing a bytes per pixel of 0).
|
