[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Comment # 37 on bug 110897 from
(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? The progress I made
basically only works on my machine but above cosiekvfj seems to have no issues
despite having the same card.

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:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux