| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This drops the get_value query and adds a function query_info, which returns
all the values in one nice structure.
|
|
|
|
| |
Use the new PCI ID table, make it simpler.
|
| |
|
| |
|
|
|
|
| |
Running any older kernel is not recommended anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
.. instead of calling r500_index_bias_supported(..) every draw call.
|
|
|
|
|
|
| |
This fixes all S3TC piglit/texwrap tests.
NOTE: This is a candidate for the 7.9 branch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <maraeo@gmail.com>, 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 <airlied@redhat.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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/
|
|
|
|
| |
r4xx has some additional fragment shader registers compared to r3xx.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1: add rv530 support
- num z pipes cap
- add proper start/finish query options for rv530
2: convert to use linked list properly.
3: add flushing required check.
4: initial Z top disabling support.
TODO:
make it actually work on my rv530.
|
|
|
|
|
| |
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
|
|
|
|
|
| |
See the previous commit for an explanation. This is just all the support code
for GB_TILE_CONFIG.
|
| |
|
|
|
|
| |
It's not "pipes", it's floating-point vertex processors. Completely different.
|
|
|
|
| |
Deck chairs on the Titanic.
|
|
|
|
| |
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!
|