| Age | Commit message (Collapse) | Author |
|---|
|
Bug #29855
|
|
Signed-off-by: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
|
|
The spec specifically sets the minimum MAX_SAMPLES at 1 to allow exposing
the extension on all implementations, so do so.
|
|
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
If we hit the linear blit path, we'd come up with a pitch of 0, then
divide by zero.
Fixes vbo-subdata-zero, made for bug #28931 (warsow).
|
|
Now that we have glsl2 with if flattening in place, most shaders will
just work. Remaining failing shaders will mostly be due to loop
unrolling (in progress), some possible if flattening failures in
inlining functions (planning on fixing), and the register/instruction
count limits.
While the GLSL and GLSL-ES specs say that shaders shouldn't fail to
compile/link due to register/instruction limits, in practice we're not
the first vendor to expose GLSL on hardware with these limitations.
The benefit to application developers of providing a better language
for GPU programming is greater than the pain of having to handle
instruction limits (which they had to for ARB_fp on this hardware
anyway)
|
|
|
|
|
|
This can only happen along a malloc failure path, but check anyway.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
Fixes "implicit declaration of function
_mesa_get_incomplete_framebuffer" warning.
|
|
Add context.h for NEED_SECONDARY_COLOR symbol.
|
|
|
|
|
|
|
|
This came from commit cf255e382d147fe3ca450f0dcec3525190e7dcbc
|
|
1. Move all GL entrypoint functions and files into src/mesa/main/
This includes the ARB vp/vp, NV vp/fp, ATI fragshader and GLSL bits
that were in src/mesa/shader/
2. Move src/mesa/shader/slang/ to src/mesa/slang/ to reduce the tree depth
3. Rename src/mesa/shader/ to src/mesa/program/ since all the
remaining files are concerned with GPU programs.
4. Misc code refactoring. In particular, I got rid of most of the
GLSL-related ctx->Driver hook functions. None of the drivers used
them.
Conflicts:
src/mesa/drivers/dri/i965/brw_context.c
|
|
Fixes segfault in mipmap_view.c demo. Bug #27212.
|
|
|
|
BOs are stored in the bufmgr, which is freed as part of the screen
structure.
|
|
It turns out that computing a 56 byte key to look up a 20-byte object
out of a hash table was some sort of a bad idea. Whoops.
before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] gl firefox-talos-gfx 37.799 38.203 0.39% 6/6
after:
[ 0] gl firefox-talos-gfx 34.761 34.784 0.17% 5/6
|
|
|
|
|
|
|
|
|
|
This avoids many pipeline stalls in cairo-gl.
[ # ] backend test min(s) median(s) stddev. count
Before:
[ 0] gl firefox-talos-gfx 36.799 36.851 2.34% 3/3
[ 0] gl firefox-talos-svg 33.429 35.360 3.46% 3/3
After:
[ 0] gl firefox-talos-gfx 35.895 36.250 0.48% 3/3
[ 0] gl firefox-talos-svg 26.669 29.888 5.34% 3/3
This doesn't avoid all the pipeline stalls because the kernel reports
!busy for buffers on the flushing list. That should be fixed in .36.
|
|
There were entries to this function (most imporantly, prepare_render
-> update_renderbuffers) that wouldn't have had NEW_BUFFERS set, but
brw_wm_surface_state (the i965 state tracking the drawing regions)
expected this to change.
|
|
The new API makes so much more sense, I'd like to forget how the old
one worked.
|
|
The slightly less mechanical change of converting the emit_reloc calls
will follow.
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
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>
|
|
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
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.
|
|
We should be able to do 16, but are limited by Mesa's static buffer
allocations.
|
|
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.
|
|
|
|
|
|
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
|
|
|
|
|
