use glCompressedTexSubImage2DARB also with xoffset by splitting into 3 calls
in total. Dunno if the top/bottom reversal is intentional but leave as is.
The comment disagreed with the code, and nicely drew my eyes to what was
going wrong.
Bug #21774 (blender)
Bug #21788 (readpix)
(cherry picked from master, commit fd65418f60)
This fixes jerkiness in doom3 and other apps since the kernel change to
throttle less absurdly, which led to a thundering herd of frames.
Because this is a rather minimal fix, there is at least one downside: If
the whole scene completes in one batchbuffer, we'll end up stalling the GPU.
Thanks to Michel Dänzer for suggesting using glFlush to signal frame end
instead of going to all the effort of adding a new DRI2 extension.
(cherry picked from master, commit 0828579a65)
Funny thing is I annotated this dependency in
e5f63c403b, but didn't actually use it.
(cherry picked from master, commit 03187571b6)
Conflicts:
src/mesa/main/state.c
Instead of relying on the Makefile to always generate $(TOP)/$(LIB_DIR),
just have mklib handle creating the directory. This should fix any races
when using parallel make.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
(cherry picked from commit 23671e5358)
Compiling mesa on a system with no X headers installed in the default
include paths fails due to missing X11 includes. The header includes are
picked up by configure but not applied.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 5358e54d1a)
Instead of relying on the Makefile to always generate $(TOP)/$(LIB_DIR),
just have mklib handle creating the directory. This should fix any races
when using parallel make.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
This avoids sending a bad buffer address to the GPU due to programmer error,
and is permitted by the ARB_vbo spec. Note that we still have the opportunity
to dereference past the end of the GPU, because we aren't clipping to a
correct _MaxElement, but that appears to be harder than it should be. This
gets us the 90% solution.
Bug #19911.
It appears that sometimes Mesa (and I suppose a VS could as well) emits
a program which references no vertex data, and thus we end up with
nr_enabled == 0 even though some VBs are enabled. We'd end up emitting
VB/VE packet headers of 0xffffffff in that case, leading to GPU hangs.
Bug #22945 (wine with an uncompiled VS)
- Added specifications for the extensions GL_APPLE_flush_buffer_range and
GL_APPLE_texture_range
- EXT_framebuffer_object.xml strangely held specifications for both
the GL_EXT_framebuffer_object extension and the GL_EXT_texture_array
extension. Split out the GL_EXT_texture_array data into its own
file.
- fix not respecting required hardware stride with compressedTexImage -
this fixes#22615.
- make sure correct stride is used in various places
- fix stored miptree never matching with a TexImage call with compressed
texture
- don't always store data with compressedtexsubimage at offset 0,
and actually use the supplied pixel data... (untested)
- make sure rows for compressed texture handling are rounded up not down
Note that trying to access stored compressed textures in hardware miptrees
from core mesa (get_compressed_teximage, swrast fallbacks) can't work correctly,
since RowStride isn't really set to anything useful, plus some places (at least
get_compressed_teximage) assume this data has native stride and no padding.
This fixes jerkiness in doom3 and other apps since the kernel change to
throttle less absurdly, which led to a thundering herd of frames.
Because this is a rather minimal fix, there is at least one downside: If
the whole scene completes in one batchbuffer, we'll end up stalling the GPU.
Thanks to Michel Dänzer for suggesting using glFlush to signal frame end
instead of going to all the effort of adding a new DRI2 extension.
