[Mesa-dev] [PATCH v3] virgl: Add support for glGetMultisample

[Erik Faye-Lund]

On Thu, Jun 28, 2018 at 7:49 PM Gert Wollny <gert.wollny at collabora.com> wrote:
>
> Am Donnerstag, den 28.06.2018, 18:09 +0200 schrieb Erik Faye-Lund:
> > It still seems kinda strange (and fragile) to me to try to enumerate
> > all possible sample locations up-front instead of querying a given
> > texture for it's sample-locations.
> With virgl, querying a texture for host-side information is quite
> costly, so if we can get aways with one lookup when starting qemu, then
> IMHO this is the preferred way to go.
>
> > For instance, I don't think there's anything in the spec backing the
> > correctness of the picking the 13 first positions from the 16 sample
> > mode strategy. That just happens to work on these three drivers
> > you've checked right now. It might not for future hardware, nor other
> > drivers. And I wouldn't be too surprised if nasty details like
> > framebuffer transforms (y-flipping in stuff like backbuffer vs FBO,
> > renderbuffers, pbuffers, scanout rotations, the recently propsed
> > y-flip extensions, you name it) could in fact "secretly" modify what
> > the correct values are.
> I think from the performance point of view it is a reasonable approach
> to query these values once and re-use them.

Yes, I just don't think it is from a correctness point of view. And
IMO, correctness concerns should always trump performance.

Is really calling glGetMultisample a hot code-path in any use-case
that matters? I'm having a hard time accepting that without some
data...

> If this turns out to be a
> problem then we can still think of another solution, but preferable one
> where one doesn't have to go through all the stack for each coordinate
> pair.

I would rather start with a correct solution, and try to optimize that
than start with one with questionable correctness and try to match the
correctness with specific implementations as seems to be what's going
on here.

There's probably also other things that can be done to speed this up.
Perhaps the gallium interface should be changed to get all
sample-pairs in an array instead, and cache that? We could even go so
far as to introduce an array-getter version of this as an extension to
avoid having to call into the guest method many times when it comes
from a mesa-driver...