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. 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. best, Gert _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
