| Summary: | dFdx/dFdy when having a parameter modified with abs() is giving odd results (0.0) in the limit values (first column in x and first row in y) | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Andrés Gómez García <agomez> |
| Component: | Mesa core | Assignee: | Andrés Gómez García <agomez> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | agomez, idr, mattst88, mreddyh.it, vlee |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Patch to correct the GCC warnings and introduce the 2 latest use cases
Image showing some different pixels |
||
|
Description
Andrés Gómez García
2014-12-17 11:22:32 UTC
Created attachment 110961 [details]
Image showing some different pixels
Looking at that test... I'm surprised Matt gave a Reviewed-by on your original patch. :) This is a really old test, and, IMO, each of the subtests should be converted to individual shader_runner tests.
Also... none of the added shaders need 'uniform sampler2D tex2d;' That should be removed.
I'm not convinced that the results are correct. Look at the attached image. The bottom right of the 3rd box and the bottom left of the 4th box are... different. Is that intended?
(In reply to Ian Romanick from comment #1) > Created attachment 110961 [details] > Image showing some different pixels > > Looking at that test... I'm surprised Matt gave a Reviewed-by on your > original patch. :) This is a really old test, and, IMO, each of the subtests > should be converted to individual shader_runner tests. > > Also... none of the added shaders need 'uniform sampler2D tex2d;' That > should be removed. I realized about that but I didn't want to modify the original test that already had the "uniform sample2D tex2d;" coming from the vertex shader used by every fragment shader. Basically, I was just following the example of the existent test. In any case, I can work to convert every subtest to an individual one. What do you think? > I'm not convinced that the results are correct. Look at the attached image. > The bottom right of the 3rd box and the bottom left of the 4th box are... > different. Is that intended? Yes, I realized about that today while testing and, not, it is not intended. Hence, the description of this bug is not correct. The problem is not glReadPixels but, actually, the results when using dFdx(abs()) or dFdy(abs()) Another problem I've observed is that the bottom in the 3rd and 4th box change when resizing the window. (In reply to Andrés Gómez García from comment #2) > > Also... none of the added shaders need 'uniform sampler2D tex2d;' That > > should be removed. > > I realized about that but I didn't want to modify the original test that > already had the "uniform sample2D tex2d;" coming from the vertex shader used > by every fragment shader. Oooops!!! Forget about this. Yes, I should have removed it completely :/ (In reply to Andrés Gómez García from comment #2) > Another problem I've observed is that the bottom in the 3rd and 4th box > change when resizing the window. The bottom pixels line in the 3rd and 4th box is read when the window size is even and not when it is odd. You can see this just by changing the window size from 300 to 301. However, piglit_probe_pixel_rgb is saying that the bottom line in the 3rd and 4th boxes are still red. After some checking, I'm seeing that this depends on the piglit run -fbo option. With -fbo, the window size doesn't matter but, without -fbo, it does. Checked with swrast, nouveau, i965 and the NVIDIA proprietary driver and this test is failing consistently in all of them. I'm wondering whether my expectations are actually wrong. (In reply to Andrés Gómez García from comment #5) > Checked with swrast, nouveau, i965 and the NVIDIA proprietary driver and > this test is failing consistently in all of them. > > I'm wondering whether my expectations are actually wrong. I think I know what the problem is. The lower-left fragment gets (0,0). In order to get the correct derivatives for the dFdx(texCoords.x) case, the helper fragments outside the polygon get negative values. dFdx(abs(texCoords.x)) around that fragment will be zero. Biasing the texture coordinates passed from the vertex shader by some small amount should fix the problem. The box is 50 pixels wide by 100 pixels tall. Biasing by (1/50, 1/100) should be sufficient. That means you'll probably want a different vertex shader for the abs() cases. *** Bug 89329 has been marked as a duplicate of this bug. *** Proposed piglit patch at: http://lists.freedesktop.org/archives/piglit/2015-April/015879.html This has been resolved, so closing. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.