| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
It doesn't work.
|
| |
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
still needs RADEON_HYPERZ=y env var.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
This fixes all S3TC piglit/texwrap tests.
NOTE: This is a candidate for the 7.9 branch.
|
|
|
|
| |
On my rv530 at least HiZ is causing rendering issues in gears.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements fast Z clear, Z compression, and HiZ support for r300->r500
GPUs.
It also allows cbzb clears when fast Z clears are being used for the ZB.
It requires a kernel with hyper-z support.
Thanks to Marek Olšák <[email protected]>, who started this off, and Alex Deucher at AMD for providing lots of hints.
v2:
squashed zmask ram size fix]
squashed r300g/blitter: fix Z readback when compressed]
v3:
rebase around texture changes in master - .1 fix more bits
v4:
migrated to using u_mm in r300_texture to manage hiz/zmask rams consistently
disabled HiZ when using OQ
flush z-cache before turning hyper-z off
update hyper-z state on dsa state change
store depthclearvalue across cbzb clears and replace it afterwards.
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
| |
|
|
|
|
|
|
| |
RV3xx is 2, RV560,RV570 is 8
Noticed by Tormod Volden.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
As per Radeon 9700 Opengl Programming and Optimization Guide [1], there are
16 texture units even on the first r300 chipsets. If you think I am wrong,
feel free to propose a patch.
[1] Here's PDF: http://people.freedesktop.org/~mareko/
|
|
|
|
| |
We really need to get these into bug reports.
|
|
|
|
| |
As suggested by agd5f.
|
|
|
|
| |
r4xx has some additional fragment shader registers compared to r3xx.
|
| |
|
| |
|
|
|
|
|
| |
This name is totally subject to change if ever I need to separate R3xx
for some other reason.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 6a40d1e9d96f8e8c57bc3bbd6f567cacd4471f59.
Turns out that we *do* need these for OQ after all. Go figure.
Conflicts:
src/gallium/winsys/drm/radeon/core/radeon_r300.h
|
|
|
|
| |
Per 74cb2aba on xf86-video-ati.
|
|
|
|
|
| |
See the previous commit for an explanation. This is just all the support code
for GB_TILE_CONFIG.
|
| |
|
|
|
|
| |
Wow, how long's that been there? Embarrassing.
|
|
|
|
| |
Just like R300_NO_TCL, when set, forces HW TCL off.
|
| |
|
|
|
|
|
| |
The debug functions depend on several util function for os abstractions, and
these depend on debug functions, so a seperate module is not possible.
|
|
|
|
| |
Signed-off-by: Corbin Simpson <[email protected]>
|
| |
|
| |
|
|
|
|
| |
It's not "pipes", it's floating-point vertex processors. Completely different.
|
|
|
|
| |
Ah, my code's so bad. It's amazing.
|
|
|
|
| |
Whoo, stuff is starting to look cleaner and cleaner.
|
| |
|
|
|
|
|
|
| |
Step two: Integration. Yay?
Time to stop messing around with this and actually go do things.
|
|
Part one: Capabilities from classic Mesa.
Damn, if only we didn't have so many fucking Radeons!
|