Same as in src/gallium/winsys/drm/intel/xorg/Makefile
Thanks MrCooper for explanations on IRC
[ Summary amended by Michel Dänzer to clarify that this is related to the xorg
state tracker ]
Besides from being necessary to use that extension, it also fixes a crash
when deleting the currently bound vertex array object.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
This reverts commit df058298e1. It didn't
explain why it was required, doesnt appear to be required, and is a
significant performance penalty for cairo-gl firefox.
Conflicts:
src/mesa/main/fbobject.c
Currently using max_slots > 1 will cause synchronous rendering
if the driver flushes its command buffers between one bitmap and the
next.
Need to improve buffer_write to allow NO_WAIT (as well as no_flush)
updates to buffers where we know there is no conflict with previous
data.
Always test for PIPE_TRANSFER_READ/WRITE using the bit-wise and operator, and
add a pipe_transfer_buffer_flags() helper for getting the buffer usage flags
corresponding to them.
Need to check if we'll take the software path so which requires mapping the
src texture image.
Fixes crash in piglit gen-compressed-teximage, bug 24219. However, the
test still does not pass (it may never have).
Interface is pipe_video_context::set_csc_matrix().
vl_csc.h defines some helpers to generate CSC matrices based on one of
the color standard and a user defined ProcAmp (brightness, contrast,
saturation, hue).
Other vendors have enabled ARB_fragment_shader as part of OpenGL 2.0
enablement even on hardware like the 915 with no dynamic branching or
dFdx/dFdy support. But for now we'll leave it disabled because we don't
do any flattening of ifs or loops, which is rather restrictive.
This support is not complete, and may be unstable depending on your shaders.
It passes 10/15 of the piglit glsl tests, but hangs on glean glsl1.
Since the TNL is all done in software anyway, it should be the same to
the user who's probably using ARB_vertex_program otherwise, but gives them
a nicer programming environment.
This fixes potential heap trashing if the program of choice exceeds limits,
and fixes the native instructions limit being lower than what can be
used by valid programs.
Previously, we were doing it in the midst of the pipeline run, which gave
an opportunity to enable/disable fallbacks, which is certainly the wrong
time to be doing so. This manifested itself in a NULL dereference for PutRow
after transitioning out of a fallback during a run_pipeline in glean glsl1.
This reverts commit e7044d552c. It
prevented the driver from ever recovering from a software fallback due
to a program error. The original bug it claimed to fix doesn't appear to
exist post-revert.
It's misleading to report things like the program having too many native
instructions as a Mesa implementation error, when the program may just be
too big for the hardware.
