i965: only upload constant buffer data when we actually need the const buffer
Make the use_const_buffer field per-program and only call the code which
updates the constant buffer's data if the flag is set.
This should undo the perf regression from 20f3497e4b
mesa/st: fix incorrect face, level in compress_with_blit
We were incorrectly applying the destination texture face and level
when requesting a transfer to the temporary texture, which has only
one face and level. This would obviously cause problems uploading to
compressed cube and mipmap textures.
Here is a couple of fixes for GNU/Hurd:
- dri_interface.h: no libdrm support either.
- configure.ac:
- GNU/Hurd is a GNU OS with _GNU_SOURCE and PTHREADS.
- GNU needs a couple of flags like other OSes
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
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.
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...
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.
José Fonseca