| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Added a conditional to spi_update per Dave's comment.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I can't see a performance difference with this code, which means all
the driver-specific code removed in this commit was unnecessary.
Now we use u_upload_mgr in a slightly different way than we did before it got
dropped. I am not restoring the original code "as is" due to latest
u_upload_mgr changes that r300g performance benefits from.
This also fixes:
- piglit/fp-kil
|
| |
|
| |
|
|
|
|
| |
Don't use height for 1D array textures or depth for 2D array textures.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also cleanup the whole thing.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This drops the memblock manager for ZMASK. Instead, only one zbuffer can be
compressed at a time. Note that this does not necessarily have to be slower.
When there is a large number of zbuffers, compression might be used more often
than it was before. It's also easier to debug.
How it works:
1) 'clear' turns the compression on.
2) If some other zbuffer is set or the currently-bound zbuffer is used
for texturing, the driver decompresses it and then turns the compression off.
Notes:
- The ZMASK clear has been refactored, so that only one packet3 is used to clear
ZMASK.
- The 8x8 compression mode is disabled. I couldn't make it work without issues.
- Also removed driver-specific stuff from u_blitter.
Driver status:
- RV530 and R580 appear to just work (finally).
- RV570 should work, but there may be an issue that we don't correctly
calculate the number of dwords to clear, resulting in a partially
uninitialized zbuffer.
- RS690 misrenders as if no ZMASK clear happened. No idea what's going on.
- RV350 may even hardlock. This issue was already present and this patch doesn't
fix it.
I think we are still missing some hardware info we need to make the zbuffer
compression work fully.
Note that there is also an issue with HiZ, resulting in a sort of blocky
zigzagged corruption around some objects.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
If we invert Y, need to subtract one from the surface height.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=26795
for softpipe.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
|
|
| |
Fixes nvc0 SCons build.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
FLT_TO_INT is a vector instruction, despite what the (current) documentation
says. FLT_TO_INT_FLOOR and FLT_TO_INT_RPI aren't explicitly mentioned in the
documentation, but those are vector instructions too.
|
| |
|
|
|
|
|
|
|
|
| |
I couldn't make it work.
GB_TILE_CONFIG.Z_EXTENDED, which enables per-pixel Z clamping, and
VAP_CLIP_CNTL.CLIP_DISABLE, which disables clipping, do help, but they
also add regressions like random graphics corruptions in some games.
|
| |
|
|
|
|
| |
This reverts commit 88550083b3857184445075e70fed8b2eed4952a1.
|
| |
|
| |
|
|
|
|
|
| |
r400 fragment shaders now support up to 64 temporary registers,
512 ALU instructions, and 512 TEX instructions.
|
|
|
|
|
|
|
|
|
|
|
| |
But we have to cheat and peek at the GENERIC semantic indices the
state tracker uses for TEXn.
Only outputs from 0x300 to 0x37c can be replaced, and so we have to
know on shader compilation which ones to put there in order to keep
doing separate shader objects properly.
At some point I'll probably create a patch that makes gallium not
force us to discard the information about what is a TexCoord.
|
|
|
|
|
|
| |
We are not required to do the linear->sRGB conversion if ARB_framebuffer_sRGB
is unsupported. However I think the conversion should work in hw except
for blending, which matches the D3D9 behavior.
|
|
|
|
|
| |
The hw can't do it and the code was useless anyway (it's lowered
in the GLSL compiler).
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes negative relative branch offsets.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we read/write image tiles we need to use the format specified
in the pipe_surface, not the pipe_transfer format (which comes from
the underlying texture/resource format).
This comes up when rendering to sRGB surfaces (via OpenGL render to
texture). Ignoring the new GL_ARB/EXT_framebuffer_sRGB extension
for now, when we render to a sRGB surface we need to treat it like
a regular, linear colorspace RGB surface. Before, when we read/wrote
tiles to sRGB surfaces we were inadvertantly doing the color space
conversion.
|
|
|
|
|
|
| |
The new function, pipe_get_tile_rgba_format(), no longer takes a
swizzle (we weren't actually using it anywhere). Rename it to
indicate that the format is passed explicitly.
|
| |
|
| |
|
|
|
|
|
| |
Even tho st/mesa use user buffers for constants align buffers
other state trackers doesn't use user buffers.
|
| |
|
|
|
|
| |
Also remove unused i915_transfer struct
|