| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Looks like r400 based IGP chips require 64 byte alignment
|
|
Since GL_READ_BUFFER is historically part of the gl_pixel_attrib group
it made sense to signal changes with _NEW_PIXEL. But now with FBOs it's
also part of the framebuffer state.
Now _NEW_PIXEL strictly indicates pixels transfer state changes.
This change avoids framebuffer state validation when any random bit of
pixel-transfer state is set.
DRI drivers updated too: don't check _NEW_COLOR when updating framebuffer
state. I think that was just copied from the Xlib driver because we care
about dither enable/disable state there.
|
|
For non-stereo visuals, which is all we support, we treat
GL_FRONT_LEFT as GL_FRONT. However, they are technically different,
and they have different enum values. Test for either one to determine
if we're in front-buffer rendering mode.
This fix was suggested by Pierre Willenbrock.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Conflicts:
src/mesa/drivers/dri/i965/brw_curbe.c
src/mesa/drivers/dri/i965/brw_vs_emit.c
src/mesa/drivers/dri/i965/brw_wm_glsl.c
|
|
Fixes a use-after-free reported in
http://bugs.freedesktop.org/show_bug.cgi?id=20539, so this possibly fixes that
bug. It has been confirmed to fix
http://bugs.freedesktop.org/show_bug.cgi?id=17895 .
|
|
RV410 SE chips only have 1 quadpipe.
Also, handle other R300 chip with quadpipe override.
|
|
RV410 SE chips only have 1 quadpipe.
Also, handle other R300 chip with quadpipe override
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 20f3497e4b6756e330f7b3f54e8acaa1d6c92052
(cherry picked from master, commit dc9705d12d162ba6d087eb762e315de9f97bc456)
|
|
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 20f3497e4b6756e330f7b3f54e8acaa1d6c92052
|
|
This performance regression on non TCL hw was introduced by ed4c6cbe017b4e8bacb7e012d4baaf77a20a2c33.
This patch depends on "r300: always route 4 texcoord components to RS" and "r300: add point attenuation stage for TCL fallbacks".
|
|
|
|
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.
|
|
|
|
|
|
|
|
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>
|
|
|
|
dri_bo_subdata()
This wraps up the unfinished business from commit a9a363f8298e9d534e60e3d2869f8677138a1e7e
|
|
|
|
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?).
|
|
|
|
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.
|
