On Thu, Jun 28, 2018 at 5:54 PM Gert Wollny <gert.wol...@collabora.com> wrote: > > Am Donnerstag, den 28.06.2018, 17:40 +0200 schrieb Erik Faye-Lund: > > On Thu, Jun 28, 2018 at 5:31 PM Gert Wollny <gert.wol...@collabora.co > > m> wrote: > > > > > > There are two aspects: > > > > > > For each number of samples there is indeed a fixes set of sample > > > positions that only depends on the hardware. The set corresponding > > > to the requested number of samples is used when the surface is > > > created with GL_TRUE for the "fixedsamplelocations" parameter. > > > > What I'm trying to say is that the concept of a global, > > hardware-dependent set of sample-positions isn't a thing. > I'm not sure what you are getting at ...
See below... > > > > These are not the same, and querying the positions of the highest > > sample-count mode isn't going to apply to any other mode. There > > simply isn't a concept of "the hardware's sample locations". They > > depend on the MSAA mode (effectively sample-count). This is exactly > > why you need to create a dummy FBO to query this; you need to know > > the sample count of the mode to answer this. > And this is exactly what I'm doing on the host (see the patch against > virglrenderer I linked before) to get the values into > vs->caps.caps.v2.msaa_sample_positions: I go through the supported > sample counts 2, 4, 8, up to 16 (if supported), store the positions, > and pass them to the guest. I looked at the radeonsi, r600, and the > intel driver, and they all define sample position sets for these sample > numbers (only up to 8 for r600). If one requests a number that is not > amongst these, then the sample positions for the next higher sample > count are returned, (eg. for 13 sample one gets the first 13 positions > for 16 samples). Right, thanks for clarifying. I misread the code, and thought you discarded the old set of samples after finding a bigger set of samples, thus assuming any mode was a subset of the biggest mode. 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. 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. This is of course just my two cents. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
