09:05q4a: adavy: I fixed fog patch, but still not sure: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22249/diffs?commit_id=e177e1f2ee885e48ddf1e684280334a70e0f3ddd... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/dDMXeroKHPzcpglAlRrnMpAZ>)
09:07q4a: David Heidelberg: did you run nine or wine tests in Windows?
09:09q4a: I have idea: build test on Windows and add all variants of D3DFOG_* to test_table_fog_zw
09:25DavidHeidelberg[m]: I don't have wib machine around, but wine people runs it
09:25DavidHeidelberg[m]: *win
11:03adavy: q4a: hum well that is weird
11:03adavy: but could be that
11:04adavy: in that case I think it's not just EXP, but EXP2 too
11:04adavy: basically not linear
11:05q4a: Ok. I'll test that too
11:06adavy: how did you test it
11:07adavy: how do you explain the formula is different for programmable ps. Is there a mistake there ?
11:12q4a: I just run nine-tests, game with trees bug and make sure, that nine-tests has no regression and game looks fine.
11:12q4a: I know, that it's bad, but I didn't check programmable ps. So it's still draft and I need more tests.
11:21adavy: if you look at the failing test, they have w equal to zero
11:21adavy: well for at least a portion of the failing tests
11:32adavy: q4a: looking at how wined3d and dxvk handle it, well they handle it both differently
11:32adavy: dxvk does always take z/w
11:32adavy: even for wfog
11:33adavy: but when it has rhw/position_t input (for example in your newly failing tests) it does modify the w passed by the vs
11:33q4a: I'm not sure, that dxvk passes nine tests as well as Gallium Nine.
11:34adavy: they do rhw = 1 if w == 0 else 1/w, position.xyz *= rhw. position.w = rhw
11:34q4a: So, I want to run nine tests on Windows, then on Linux with DXVK.
11:35adavy: that's what the hw is doing anyway I think, at least for xyz, but possibly that changes the w passed, and the the z/w formula
11:36adavy: for wfog I don't see any specific handling in dxvk so they might have missed it
11:36adavy: wined3d doesn't seem to take the same input at all
11:42adavy: (here is the explanation about wfog https://learn.microsoft.com/en-us/windows/win32/direct3d9/pixel-fog It's possible our interpretation is wrong, but well...)
11:46adavy: actually we do a similar transform to dxvk when the passthrough feature is not supported.
11:53adavy: ok so basically, when we output x y z w, the pipeline does x/w, y/w, z/w, 1/w : https://learn.microsoft.com/en-us/windows/win32/dxtecharts/the-direct3d-transformation-pipeline
11:54adavy: when you pass xyzrhw points like in the tests with failing results, the values are already x/w, y/w, z/w, 1/w
11:56adavy: in the shader, position was linearly interpolated
11:56adavy: when we read depth for fog
11:58adavy: actually the comment in nine_shader.c about depth being perspective interpolated doesn't make sense relative to the calculation, because the perspective interpolation related to the weights of the interpolation, not to the result
11:59adavy: anyway either we need original z, or z/w
12:00adavy: by inverting 1/w and multiplying z/w, that means we get original z
12:11adavy: Ok, I think I have more or less an idea of what is going on
12:11adavy: I think - and that is what wined3d is doing - that depth is not retrieved in the ps shader, but in the vs shader and exported in a fog output
12:12adavy: in the vs shader it has access to the original z
12:12adavy: and when it has xyzrhw, it must be accessing the z/w passed, rather than doing the inversion
12:16q4a: I have more or less an idea of what is going on -that's good) I just finished running nine tests on Windows and got stable 16 fails (tested 5 times): https://pastebin.ubuntu.com/p/gptZNv7XX5/
12:17q4a: Nothing related to fog. So, I can add more fog tests and check if they will pass.
12:21q4a: Here is changes: https://github.com/q4a/nine-tests/commit/ec84f887584769aa9d496c55f7a55ba33baeecdc
12:54adavy: q4a: actually I have my doubts about the proposed solution
12:55adavy: could you try wfog ?
12:56adavy: in nine_ff.c, in the key.fog_source = .... remove the !context-> programmable_vs
12:56adavy: The game sets a projection matrix that is not orthogonal
12:57adavy: so without that test , fog_source would select wfog
12:57q4a: I'm in Windows now. So I need some time to reboot in Linux. Also, should I remove my changes?
12:57adavy: shouldn't matter I think
12:58adavy: take your time to finish what you were doing
13:10q4a: Wow.. that worked too. I removed my changes and remove the !context-> programmable_vs.
13:10q4a: Nine tests has same results and trees in my game works fine)
13:16adavy: according to the r500 documentation, fog can come from 1/(1/W) or z
13:17adavy: also there is a field to determine whether depth comes from 'scan converter as plane equation' or 'shader as four discrete values'
13:17adavy: r500 is the last true dx9 card from ATI
13:17adavy: and it has fog implemented in fixed pipeline
13:19q4a: should I test this change on Intel HD graphics?
13:20adavy: 'in the case of TCL_BYPASS [...] the PSC destination vector locations shall map directly to the semantically defined locations[...]'
13:20adavy: TCL_BYPASS is XYZRHW
13:21adavy: in other words, it doesn't seem to me that the hw does take z after it was divided by w
13:21adavy: but my interpretation might be wrong
13:21adavy: so it takes z before it was divided by w
13:22adavy: and in the case of XYZRHW, it takes z as is, and this happens to be z already divided by w
13:25adavy: what makes me wonder is "https://learn.microsoft.com/en-us/windows/win32/direct3d9/pixel-fog" : Direct3D uses the currently set projection matrix in its w-based depth calculations. As a result, an application must set a compliant projection matrix to receive the desired w-based features, even if it does not use the Direct3D transformation pipeline.
13:26adavy: the "not use the Direct3D transformation pipeline" could refer to XYZRHW or programmable shader. It's not clear
13:28adavy: q4a: the fact that wfog works for you could either be that indeed the correct output is wfog, or that the correct output is z before the division by w
13:29adavy: because z before the division by w is likely very close to w in terms of range
13:29adavy: One would have to compare pixel per pixel value against windows to be sure
13:29adavy: basically compare windows with nine with wfog and nine with z/(1/w)
13:32q4a: ok, I should run qapitrace, got same image in call 203368 (example with trees).
13:32q4a: But is there good way to compare image pixel per pixel?
13:33adavy: In the past I used to write on paper pixel values at selected coordinates to compare
13:33adavy: but that's not ideal
13:33adavy: you need to pick pixels for trees that look far, and trees that look close
13:39adavy: what is suspicious is wine's test fog_special_test
13:39adavy: which says the test require the projection matrix to be set explicitly to identity
13:40adavy: it could be related to the driver activating wfog/zfog
13:59q4a: adavy: this diff is good for `nine with z/(1/w)` check? https://gitlab.freedesktop.org/q4a/mesa/-/commit/e177e1f2ee885e48ddf1e684280334a70e0f3ddd
14:00q4a: I used https://pypi.org/project/pixelmatch/ and here is result between win and nine+wfog:
14:00q4a: https://user-images.githubusercontent.com/1950719/229357649-a477fb8b-1d73-45e2-8eef-b1b27b7faf5a.png
14:02DavidHeidelberg[m]: wow, that looks pretty good
14:03q4a: That was with only small change: https://gitlab.freedesktop.org/q4a/mesa/-/commit/3971672386aba796c5acd642e8c2e2101c0b70e7
14:16adavy: well probably fine
14:17adavy: so you compare win and nine+wfog
14:17adavy: about about win and nine with z/(1/w) ?
14:23q4a: I got same result: https://user-images.githubusercontent.com/1950719/229358294-3a3a6daa-a877-42ba-8f09-d0215ccf7c37.png
14:23q4a: when compare win vs nine+this change: https://gitlab.freedesktop.org/q4a/mesa/-/commit/e177e1f2ee885e48ddf1e684280334a70e0f3ddd
14:24adavy: well that doesn't make sense
14:25adavy: there should be a difference with nine+wfog and nine+z/1/w
14:29q4a: Can I add some debug prints to check fog values?
14:29q4a: s/Can/Should/
14:30adavy: you can force the wfog path to be taken
14:30adavy: by commenting the zfog path
14:37adavy: Trying to figure out what r500 does from the doc I guess the following intrepretation: the fog module is at the end of the pipeline. GB_SELECT indicates whether we take as source z or 1/1/w, or if we pass a precomputed fog factor and if so in which register.
14:37adavy: What is not clear though is whether this z -if we take it- is divided or not by w
14:39adavy: There's also FG_DEPTH_SRC which description is unclear to me and it could either be that it controls whether depth is or not divided by w, or that it controls vertex based vs pixel based fog
14:46adavy: ooh reading r300's mesa code this indicates whether the pixel shader overwrites depth
14:46adavy: I forgot pixel shader could do that
14:48q4a: by commenting the zfog path - like this one? https://gitlab.freedesktop.org/q4a/mesa/-/commit/b36da04d53f2659ec27923fb7a659414aaec14c4
14:49adavy: yes
14:50q4a: still same result: https://user-images.githubusercontent.com/1950719/229360516-4a760d3e-b296-4920-a4df-dabf1c4f2963.png
14:51q4a: I tested and reverting all changes gives me very green trees
14:53adavy: i guess it could happen to be identical if z = 1
14:56q4a: Here is how it looks, when I reverted all changes: https://user-images.githubusercontent.com/1950719/229360784-49e338f9-05e0-47c4-8e1a-608c292e2888.png
15:01adavy: I see
15:02adavy: Is fog supposed to be applied to other things than the trees ?
15:02adavy: could bad fog being applied to the others explain the difference in the output ?
15:08adavy: The r500 doc really makes me wonder if no one among wined3d, dxvk and nine got fog correct
15:09adavy: specially since it seems writing depth in the pixel shader should affect fog, and no one does that
15:12q4a: May be better to write test and run it on Windows?
15:12adavy: yes I think tests would definitely help
15:13adavy: would you be able to test that ?
15:14q4a: I can run test, but I'm not sure what exactly it should do
15:14q4a: or check
15:17q4a: My morning idea was to add more than `D3DFOG_LINEAR` to `test_table_fog_zw` test. Get correct colors on Windows and then run same test in Linux.
15:17q4a: https://github.com/iXit/nine-tests/blob/20a508852677f026859102f063756e8b1f4da4f1/NineTests/visual.h#L19468
15:17adavy: basically the problem with wine tests is that most test with w = 0 and projection matrix set to identity
15:17adavy: if you set the projection matrix to identity according to the doc it enforces z based fog
15:17adavy: so wine tests never test wfog
15:18adavy: wfog tests are missing basically
15:18adavy: wfog is when the projection matrix is set to a projection matrix (last column is 0 0 1 0)
15:19adavy: according to tests done by a contributor, we figured out that there was zfog did specifically check only the last two elements of the last column, and that if it was 0 1 then it was zfog, else wfog
15:21adavy: So basically you should write a test that uses such a projection matrix and show that w is used for programmable vertex shaders for example
15:21adavy: rather than z/w
15:21adavy: *z
15:22adavy: you could also duplicate the test with fog and xyzrhw and show that when using such a matrix, the w component is used, not z
15:23adavy: there is also a test that would be needed with depth being written in the pixel shader, and show that this depth is used for fog. And see if that behaviour is different for zfog and wfog
15:23adavy: that's a lot, but well even simple stuff will help
15:25q4a: Ok, I'll take some rest, eat some food and will try to write tests
16:08adavy: q4a: https://pastebin.com/yWsqCb3J
16:10adavy: Well my C is rusty
16:11adavy: I don't remember whether the result of a test is 0/1 or 0/0xff
16:13adavy: oh no found a bug
16:23adavy: (not in the proposed patch, and not a bug too problematic. Basically the pixel shader key gives 1 bit to FOGTABLEMODE which is 3 bits, this it will overwrite the bit after which activates centroid interpolation for color. That will just impact perf very slightly to do so)
17:01q4a: adavy: https://pastebin.com/yWsqCb3J - trees looks good. Nine tests has same result - no regression.
17:12adavy: yes now we will have to test on more things
17:13adavy: and the additionnal wine tests would help clear that out for good
17:39adavy: q4a: for the tests, what I would advise is to duplicate parts of wine fog tests, but set a projection matrix for the projection matrix, rather than the identity. Then run on windows, find the real expected values, change them, and done
17:39adavy: you probably will need then to check for the wfog flag to run the test conditionnally and and the wine_todo to the wine failing tests and then submit to wine dev
18:10adavy: q4a: here is an idea of test: Draw a square using a different z for each vertice. Similarly a different w for each vertice. You could use for example 0.1, 0.2, 0.3, 0.4 for z and 0.6, 0.7, 0.8, 0.9 for w. Use linear fog (tablemode) with start/end being 0/1. The vertices color could be red and fog color use only the green channel, so they don't interact.
18:10adavy: Basically you would check the green channel at the center of the square
18:11adavy: with simple vs, simple ff vs (identity matrices everywhere, except projection which would either be identity, or switch z/w and thus be a projection matrix)
18:11adavy: similarly simple ps or simple ff ps
18:12adavy: you could also test ff vs with xyzrhw, and doing so just changing x/y and keepong z/w
18:13adavy: the advantage og checking the center of the square would be that it also tests the interpolation mode (linear vs perspective corrected linear)
18:13adavy: I think this test would solve all the questions
18:19DavidHeidelberg[m]: btw. wine has now also gitlab, so it's easy to contribute with the test (and re-import to nine-tests)
18:23adavy: well we need also test with pixel shader writing to the depth output, to see how this is sued
18:23adavy: *used
18:24DavidHeidelberg[m]: :D hope not (without asterisk)
21:01adavy: Found this document: https://developer.download.nvidia.com/assets/gamedev/docs/Fog2.pdf
21:01adavy: it seems to be for dx7, but still interesting
21:53q4a: I definitely need to read more about fog. I tried to set start/end fog being 0/1 in current test_table_fog_zw test. And got only green (fog) color: https://pastebin.ubuntu.com/p/tcxBFWSgs9/
21:56q4a: Same happened when I started to change square + use project matrix. With identity matrix i got same (green) result. https://github.com/q4a/sdl_triangle/blob/main/d3d9_square/src/d3d9_square.cpp#L179
22:02q4a: ok.. there was working example) https://learn.microsoft.com/en-us/windows/win32/direct3d9/pixel-fog
22:21q4a: https://github.com/q4a/sdl_triangle/blob/main/d3d9_square/src/d3d9_square.cpp#L172 - fix start/end for fog, but still has 6 out of 8 squares are green