https://bugs.freedesktop.org/show_bug.cgi?id=110897
Dieter Nützel Dieter@nuetzel-hh.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maraeo@gmail.com, | |michel@daenzer.net
--- Comment #38 from Dieter Nützel Dieter@nuetzel-hh.de --- (In reply to Richard Thier from comment #37)
(In reply to Dieter Nützel from comment #35)
Hello Richard,
very NICE progress!
Maybe you can run 'glmark2' with/without HyperZ.
Good idea.
Can you test if HyperZ works for you without any changes?
Sorry,
I'haven't any system for r300 (PCI/AGP) handy. Latest here HD 4650, RV730 AGP (1 GB !), r600 (see older bug reports...;-) But not booted for nearly 2 years... Maybe I have an older r300 one (yep, 9550), but I have to dig in the basement for it, if you need.
The progress I made basically only works on my machine but above cosiekvfj seems to have no issues despite having the same card.
You made GREAT progress!
We have to ping Michel Dänzer and Marek Olšák for your open questions. (see CC list)
Actually if the gb_pipes number is wrong then the error is not even in the HyperZ code, but in the code that returns the wrong value from drm - that HyperZ code is just using.
Oh and keep in mind that I have no HiZ RAM! So if I measure speed gains others might measure a higher gain if they have HiZ RAM too as I think this way I have no hierarchical Z-buffer at all - when bigger tiles store min or max z values of theirs and first they are compared not pixels - but I have this compressed Z-buffer or zmask_ram - latter which is a lossless compression of the zbuffer. I read that they use tricks like storing the one-two triangles directions basically for whole tiles to save some bandwith and/or indicate if a tile is compressed or not at all.
This latter seems to help memory bandwith in case the triangles are bigger than the tiles (typically: walls in a game maybe?).