Use _NEW_PROGRAM_CONSTANTS when changing constant/uniform buffer values.
Binding a new program/shader sets both _NEW_PROGRAM and _NEW_PROGRAM_CONSTANTS.
This can be almost impossible to avoid - hopefully we won't encounter
a situation where this is a true requirement. Would probably require
drivers to flush between hardware and software vertex processing.
The drm_intel_gem_bo_map_gtt() call that replaced dri_bo_map() is
producing errors like:
intel_bufmgr_gem.c:689: Error preparing buffer map 39 (vp_const_buffer): Invalid argument .
and returning NULL, causing a segfault in the memcpy().
Just reverting until we can get to the root issue...
In the VS constants can now be handled in two different ways:
1. If there's room in the GRF, put constants there. They're preloaded from
the CURBE prior to VS execution. This is the historical approach. The
problem is the GRF may not have room for all the shader's constants and
temps and misc registers. Hence...
2. Use a separate constant buffer which is read from using a READ message.
This allows a very large number of constants and frees up GRF regs for
shader temporaries. This is the new approach. May be a little slower
than 1.
1 vs. 2 is chosen according to how many constants and temps the shader needs.
The new, second cache will only be used for surface-related items.
Since we can create many surfaces the original, single cache could get
filled quickly. When we cleared it, we had to regenerate shaders, etc.
With two caches, we can avoid doing that.
i915 actually supports up to 4 (according to header file - not tested),
i965 up to 16 (code already handled this but slightly broken), so don't use 2
for all chips, even though angular dependency is very high.
When program constants change we create a new VS constant buffer
instead of re-using the old one. This allows us to have several
const buffers in flight with vertex rendering.
Make sure we detect constant buffer changes indicated by the new flag.
Should be able to remove _NEW_PROGRAM (and _NEW_MODELVIEW, _NEW_LIGHT, etc)
from several places (someday.
This is a follow-on to commit c1a3b85280.
Note that (at this time) wherever _NEW_PROGRAM_CONSTANTS is set we're still
setting _NEW_PROGRAM so this won't really make any difference (for now).
Need to do this to ensure vbo code unmaps its buffers before calling
the driver, which may be sitting on top of a memory manager which
objects to firing commands from a mapped buffer.
This state flag will be used to indicate that vertex/fragment program
constants have changed. _NEW_PROGRAM will be used to indicate changes
to the vertex/fragment shader itself, or misc related state.
_NEW_PROGRAM_CONSTANTS is also set whenever a program parameter that's
tracking GL state has changed. For example, if the projection matrix is
in the parameter list, calling glFrustum() will cause _NEW_PROGRAM_CONSTANTS
to be set. This will let to remove the need for dynamic state atoms in
some drivers.
For now, we still set _NEW_PROGRAM in all the places we used to. We'll no
longer set _NEW_PROGRAM in glUniform() after drivers/etc have been updated.
