On Thu, Jun 28, 2018 at 7:49 PM Gert Wollny <gert.wol...@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... _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
