| Age | Commit message (Collapse) | Author |
|---|
|
Routing <4 components may lead to lock up.
Thanks to Alex Deucher for suggestion.
|
|
|
|
|
|
add 1D texture case and setup default Q value to 1.0
|
|
ae_create_context is called by vbo_CreateContext
ae_invalidate_state is called by vbo_InvalidateState
|
|
According to r300_reg.h from radeon drm module 0x4f30 is ZB_ZMASK_OFFSET.
Also cleanup as trailing whitespaces.
|
|
r300SetEarlyZState is called during r300UpdateShaderStates which is called for every rendering operation.
|
|
Use a bitvector of used/free flags.
If we run out of temps, examine the live intervals of the temp regs in
the program and free those which are no longer alive.
Also, enable the new WM const buffer code.
|
|
|
|
snprintf not directly available on Windows.
|
|
|
|
|
|
|
|
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 23ad86cfb91c294ce85a3116d4b825aaa3988a6e 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.
|
|
dri_bo_subdata()
This wraps up the unfinished business from commit a9a363f8298e9d534e60e3d2869f8677138a1e7e
|
|
Use _NEW_PROGRAM_CONSTANTS when changing constant/uniform buffer values.
Binding a new program/shader sets both _NEW_PROGRAM and _NEW_PROGRAM_CONSTANTS.
|
|
|
|
need to clamp point size to user set min/max values, even for constant
point size. Fixes glean pointAtten test.
|
|
|
|
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...
|
|
forgot to commit the changes to actually support 4x aniso filtering...
|
|
Also fixes drawing to 3D texture depth levels.
|
|
This is a CPU win in general, but in particular reduces the pain of
Mesa's calculation of min/max indices in DrawElements (wtf?).
|
|
Call FLUSH_VERTICES() in _mesa_Histogram().
No need to signal _NEW_PIXEL in ResetHistogram(), ResetMinmax().
|
|
|
|
|
|
Calling _mesa_dump_textures() deleted the textures... oops!!!
|
|
|
|
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.
|
|
|
|
These types are only found in the new surface state cache now.
|
|
|
|
|
|
|
|
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.
|
|
No more dynamic atoms so we can simplify the state validation code a little.
|
|
|
|
|
|
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 c1a3b852807fb160f0cd246c1364b7336b4b947e.
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).
|
|
|
|
Lost in commit e50dd26ca6d0eb0d0f97c2780020ea16e3d4a687.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
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.
|
