Bug 77161

Summary: [softpipe] piglit fbo-generatemipmap-cubemap S3TC_DXT1 regression
Product: Mesa Reporter: Vinson Lee <vlee>
Component: Drivers/Gallium/softpipeAssignee: mesa-dev
Status: NEW --- QA Contact:
Severity: normal    
Priority: medium CC: maraeo
Version: gitKeywords: bisected, regression
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
i915 platform: i915 features:

Description Vinson Lee 2014-04-08 00:48:58 UTC
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
Comment 1 Marek Olšák 2014-05-21 22:41:40 UTC
There may be precision issues in cubemap texture addressing in softpipe. I haven't seen any failures with r600g and radeonsi.
Comment 2 Roland Scheidegger 2014-05-21 23:38:58 UTC
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.
Comment 3 Marek Olšák 2014-05-22 01:29:40 UTC
FWIW, ARB_texture_view allows changing to the texture target to a compatible texture target, e.g. cubemap <-> texture 2D array.
Comment 4 Roland Scheidegger 2014-05-22 09:51:44 UTC
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).
Comment 5 Kenneth Graunke 2014-05-28 20:30:52 UTC
Removing from the blockers list due to Roland's comments.

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.