What | Removed | Added |
---|---|---|
CC | maraeo@gmail.com, michel@daenzer.net |
Comment # 38
on bug 110897
from Dieter Nützel
(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?).
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel