[Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa

[Dave Airlie]

On Mon, 8 Feb 2021 at 19:04, Andreas Fänger <a.faenger at e-sign.com> wrote:
>
>
> Am 08.02.2021 05:14, schrieb Dave Airlie:
> > On Wed, 3 Feb 2021 at 02:58, Michel Dänzer <michel at daenzer.net> wrote:
> >>
> >> On 2021-02-02 5:55 p.m., Michel Dänzer wrote:
> >> > On 2021-02-02 6:44 a.m., Dave Airlie wrote:
> >> >> On Mon, 1 Feb 2021 at 16:50, Dave Airlie <airlied at gmail.com> wrote:
> >> >>>
> >> >>> On Thu, 7 Jan 2021 at 21:11, Andreas Fänger <a.faenger at e-sign.com>
> >> >>> wrote:
> >> >>>>
> >> >>>>>> don’t know why the current softpipe/swrast implementation
> >> >>>>>> shouldn’t be conformant.
> >> >>>>
> >> >>>>> Interesting I hadn't known we had a correct impl in mesa, the
> >> >>>>> features.txt has said "softpipe and llvmpipe advertise 16x
> >> >>>>> anisotropy but simply ignore the setting"
> >> >>>>> so I never dug any deeper. I'll consider a port of this to llvmpipe
> >> >>>>> at some point, making it efficient might be tricky.
> >> >>>>
> >> >>>> It seems that features.txt hasn't been updated regarding this
> >> >>>> functionality; softpipe has "real" anisotropy since 2011.
> >> >>>>
> >> >>>>> I'll consider a port of this to llvmpipe at some point, making it
> >> >>>>> efficient might be tricky.
> >> >>>> That would be great. As anisotropic filtering is often an option
> >> >>>> which can be set by a user, I guess most people turn it off to get
> >> >>>> higher framerates. But in our use case, high quality renderings are
> >> >>>> required, so we accept the longer render times to get the best
> >> >>>> quality; hopefully a llvmpipe port would be faster than the old
> >> >>>> swrast implementation (we are only using the fixed rendering
> >> >>>> pipeline/no shaders in conjunction with the OpenMP patch for
> >> >>>> speeding up GL_POLYGON_SMOOTH_HINT)
> >> >>>>
> >> >>>> Andreas
> >> >>>
> >> >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804
> >> >>>
> >> >>> Is my first pass at writing the code for this I've no idea if this is
> >> >>> anyway correct, but I'm just letting everyone know I've started
> >> >>> working on it, and mipmap_tunnel doesn't look immediately wrong.
> >> >>
> >> >> Olay the code in the MR above seems to work in most cases now and
> >> >> seems to operate like softpipe.
> >> >>
> >> >> However I'm seeing a trace failure
> >> >> https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/
> >> >>
> >> >
> >> > The floor at the bottom left of the Actual image definitely looks odd,
> >> > there's a hard line between the rock patterns.
> >>
> >> Not to mention the wall tiles having different sizes, with a hard line
> >> as well.
> >>
> >> Definitely looks like a bug to me, which wouldn't be noticeable with
> >> special test textures made up of different solid colours per mip
> >> level.
> >
> > I've fixed all the issues in that area, and I believe llvmpipe and
> > softpipe mostly produce the same or very similiar results.
> >
> > I'm not overly impressed though by the texture quality at least the
> > furmark trace shows as very blurry.
> >
> > Also the Vulkan CTS expects linear aniso to operate differently to how
> > this has done it.
> >
> > Andreas, can you comment on this trace?
> > https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7150044/gputest/furmark.trace/
> >
> > I'm pretty sure softpipe looks the same locally for the same trace,
> > and it just seems overly blurry.
>
> 1) Is it blurry in all cases you have tried or are there test cases
> where it is better?

I've only noticed it with furmark, but I don't have a lot of test
cases, the GL CTS passes, the Vulkan CTS does look blurry and fails
but it's unlikely that is due to the blur.

> 2) Are the results better compared to linear?

I'm not sure, better is pretty subjective measure here,

> 3) Is the reference image produced with another anisotropy
> implementation or with linear?

The reference image is produced with whatever llvmpipe path was taken
before this, which I assume is linear.

>
> If 2) is not what you expect, then maybe the softpipe version is not
> correct (anymore).
>
> In general, I remember that results are a bit more blurry (compared to
> linear) in the non-anisotropy case, ie. when textures are displayed
> undistorted at 100%. But this doesn't seem to be the case in the trace
> image here.

I'd be interested in any test data you have or any output, afaics the
llvmpipe output pretty much matches the softpipe output and if the
softpipe output is currently acceptable then we should merge the MR to
equalise them, and then fix any subsequent things on top in parallel.

I'd like to solve the VK CTS issue which does a linear vs anisotropic
compare and expects only a moderate amount of difference and we seem
to exceed the difference threshold.

Dave.