intel / DRI2: When available, use DRI2GetBuffersWithFormat
This interface gives the driver two important features. First, it can
allocate the (fake) front-buffer only when needed. Second, it can
tell the buffer allocator the format of buffers being allocated. This
enables support for back-buffer and depth-buffer with different bits
per pixel.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
As of commit 23ad86cfb9 all messages go
through output_if_debug().
Add new parameter to output_if_debug() to indicate whether to emit a newline.
_mesa_warning() and _mesa_error() calls should not end their strings with \n.
_mesa_debug() calls should end their text with \n.
mesa: signal _NEW_PROGRAM_CONSTANTS instead of _NEW_PROGRAM
Use _NEW_PROGRAM_CONSTANTS when changing constant/uniform buffer values.
Binding a new program/shader sets both _NEW_PROGRAM and _NEW_PROGRAM_CONSTANTS.
pipebuffer: don't fail when validating mapped buffers
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.
i965: revert part of commit 4f4907d69f9020ce17aef21b6431d2dd65e01982
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.
i965: checkpoint commit: use two state caches instead of one
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.
i965: use _NEW_PROGRAM_CONSTANTS and always create new const buffers
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.
st: also check _NEW_PROGRAM flag for vertex shader constant buffers
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).
Ian Romanick