[Mesa-dev] [PATCH] virgl: Allow RGB32* textures only as buffer objects

[Ilia Mirkin]

On Sun, Jul 22, 2018 at 2:54 AM, Gert Wollny <gert.wollny at collabora.com> wrote:
> Am Samstag, den 21.07.2018, 14:14 -0400 schrieb Ilia Mirkin:
>> On Sat, Jul 21, 2018 at 1:48 PM, Gert Wollny <gert.wollny at collabora.c
>> om> wrote:
>> > Am Samstag, den 21.07.2018, 11:33 -0400 schrieb Ilia Mirkin:
>> > >
>> > >
>> > > On Sat, Jul 21, 2018, 05:45 Gert Wollny <gert.wollny at collabora.co
>> > > m>
>> > > wrote:
>> > > > Am Freitag, den 20.07.2018, 12:31 -0400 schrieb Ilia Mirkin:
>> > > > >
>> > > > > > +   /* Allow 3-comp 32 bit texturs only for TBOs (needed
>> > > > > > for
>> > > > > > ARB_tbo_rgb32) */
>> > > > > > +   if ((format == PIPE_FORMAT_R32G32B32_FLOAT ||
>> > > > > > +       format == PIPE_FORMAT_R32G32B32_SINT ||
>> > > > > > +       format == PIPE_FORMAT_R32G32B32_UINT) &&
>> > > > > > +       target != PIPE_BUFFER)
>> > > > > > +      return FALSE;
>> > > > >
>> > > > > My personal recommendation would be to disallow *all* packed
>> > > > > RGB
>> > > > > formats unless target == PIPE_BUFFER. (And even then --
>> > > >
>> > > > questionable,
>> > > > > except for RGB32, which is required.)
>> > > > >
>> > > >
>> > > > RGB8 and RGB16 are disabled/replaced by RGBX* on the host side,
>> > > > and
>> > > > R11G11B10 doesn't seem to make problems.
>> > >
>> > > No other driver supports these. What happens on the host side is
>> > > hidden from virgl.
>> >
>> > Not exactly, of course the host tells virgl what formats are
>> > supported,
>> > and we test using dEQP and piglit quite heavily to get things
>> > right, so
>> > I'm quite confident that whatever problem comes up, we will catch
>> > it.
>>
>> The result is that you end up lying to mesa and the various helpers
>> --
>> the user creates a RGB8 texture, which your gallium driver claims to
>> support. In reality, it's a RGBX texture on the host, but this
>> information is hidden from virgl
> No, it is not, virgl_is_format_supported will not claim that the RGB
> format is supported, it will pick PIPE_FORMAT_RnGnBnXn_* also on the
> guest side, because PIPE_FORMAT_RnGnBn_* (n = 8,16) is not in the list
> of driver supported formats (not even for buffers), this information is
> in the caps sampler.bitmask and render.bitmask that are send from the
> host and that are also checked in this function. Only because we can
> not remove  PIPE_FORMAT_R32G32B32_* completely we need this additional
> check.

So to confirm, is_format_supported(PIPE_FORMAT_R8G8B8_UNORM) will
return false, irrespective of what the host driver might be. Correct?

  -ilia