[UNOFFICIAL] Bug Bounty: zfreeze

[slarlac249]

https://code.google.com/p/dolphin-emu/issues/detail?id=4113

plenty of ideas there, yet no one took up the challenge.

Quote:If you want a useful idea, implement zfreeze in the hw renderers, that'll pretty much fix the issue
We already have support for that in the software backend, so if you really wanted to mess with it you could take a look at how its done there. It'll be quite a bit involving for the hw renderers though, since we'll need to software transform all vertices (we already have code which does that) and compute the zslope from that.

pretty much goes over my head what they are talking about.

[slarlac249]

managed to find the last zfreeze release;

https://us.dolphin-emu.org/download/list/zfreeze/1/?cr=us

3.5-1729

[degasus]

(11-13-2014, 04:23 AM)Fiora Wrote: I think the most helpful thing would be an actual solid, fleshed-out idea for how to approach the problem -- right now it feels like it's languishing because nobody really knows quite how to do it. Even if it's just a write-up of how one might reliably and efficiently emulate zfreeze, a solid idea would probably do more to inspire people to try it than any amount of money.

I like this way to handle this issue, so let's talk about my proposel to implement this feature.

I strongly dislike the first proposel of transforming within the vertex loader because of some issues:
- cpu performance (ok, it's fine to laugh when you'll read my one...)
- software transformation dependency within videocommon (bbox support already patched out for ogl4 GPUs)
- the main issue: How shall this fix zfighting? We need a deterministic way to always get the exact same value for every pixel. Rasterization is only deterministic if all three positions are identical (order independet).

My suggestion is splitted into two parts. The interface is based on the linear z plane parameters vec3 my_depth_parameters.
Calculating the depth is deterministic possible by: gl_FragDepth = dot(vec3(gl_FragCoord.xy, 1.0), my_depth_parameters);
Generating this parameters can be easyly done in the geometry shader per primitive.
-> This require slow depth, so it will conflict with zcomploc.

This was the easier part. The harder part is to readback the *last* used z parameters. Here I'm still a bit indecisive how to do it. It is possible, but I have no clue about the fastest way
Possible ways would be to use:
- SSBO, but it will be hacky to only get the last one
- transform feedback (just record all primitives and read the last parameters again)

[Tino]

The fastest way I think, will be as long as the zfreeze is not active record the last flushed primitive and it corresponding transformation matrix ( using the global mtx index or the pervertex idx ). the when zfreeze is switched on, calculate plane coeficients and send them to the gpu.

[degasus]

Tino: But this coeficients must be the same as the gpu did use internally. Else we'll end in z fighting again :/

[Tino]

yes that the hard part, because that can change in diferent implementations, the best we can spect is to get a consistent value for all the primitives generated using our implemnetation of zfreeze, and eliminate z figting introducing a small offset to compensate. the best way will be to do a hardware test to determine the correct formula from the native hard, and then tweak our paremeters to compensate side effects from diferent hardware implementations.

[Fiora]

Do any games where zfreeze is very important also use zcomploc in an important/necessary way? i.e. does zcomploc breaking cause serious issues there?

[Tino]

I did not have any of the games that show glitches from zfreeze so i cannot tell

[neobrain]

I just wrote this overview to get some more focused efforts going: https://forums.dolphin-emu.org/Thread-implementing-zfreeze-the-program

If everyone agrees, I'd like to move discussion over there and close this thread.

[BlizzardToaBreeze]

Fine by me