| Summary: | [softpipe] piglit fbo-generatemipmap-cubemap S3TC_DXT1 regression | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Vinson Lee <vlee> |
| Component: | Drivers/Gallium/softpipe | Assignee: | mesa-dev |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | maraeo |
| Version: | git | Keywords: | bisected, regression |
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
There may be precision issues in cubemap texture addressing in softpipe. I haven't seen any failures with r600g and radeonsi. I don't think this qualifies as a blocker. Cubemaps aren't quite right on softpipe anyway due to doing face selection per quad (which I suspect is also what's causing this bug, probably pick the wrong face, since it considers the average of all 2x2 pixels to chose the face, no matter if those pixels are actually inside the primitive or not). The driver can do seamless filtering (probably useless here I guess) but the initial face selection is always per quad. If this is what's happening here, this is not easily fixable (don't even have the information which pixels are lit in the sampling code and doing per pixel face selection is anything but trivial though obviously can be done. Or could try to be clever and use per-pixel faces when the derivatives aren't needed). Some cpu based blitter instead of relying on u_blitter for softpipe would also be possible (and be at least an order of magnitude faster). As a side note, I suspect we need to allow some form of casting cube to 2d (array) resources at some point and vice versa, though possibly some drivers can't do it. (d3d10.1 no longer has cube map resources, it's all just 2d (arrays).) This would be less work for everyone (who can do it) and eliminate such issues for free. FWIW, ARB_texture_view allows changing to the texture target to a compatible texture target, e.g. cubemap <-> texture 2D array. Oh I forgot that ARB_texture_view also allows you to do that. All the more reason to allow it in gallium (and use for cube map mip generation). Removing from the blockers list due to Roland's comments. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/211. |
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.
mesa: 34f15903d6f5807b34a4c9be6d8daaedbbdd64bc (master 10.2.0-devel) $ ./bin/fbo-generatemipmap-cubemap S3TC_DXT1 -auto Probe color at (0,0) Expected: 0.250000 0.500000 0.500000 1.000000 Observed: 0.000000 0.490196 0.482353 1.000000 when testing face 2, level 5, cube 0 PIGLIT: {'result': 'fail' } 8ab7bb4707ae5fb6e5e841f0f2e369c14b5ffbea is the first bad commit commit 8ab7bb4707ae5fb6e5e841f0f2e369c14b5ffbea Author: Marek Olšák <marek.olsak@amd.com> Date: Sun Mar 16 03:40:54 2014 +0100 gallium/u_blitter: don't adjust cubemap coordinates by a small number It may cause issues with mipmap generation. I think it was used to make some piglit tests pass on r300g. :040000 040000 de431ecef78cd73917bdae4846194821bcfe9862 234da266ee4cbe859f5e9a9671fdb82026953304 M src bisect run success