[Mesa-dev] nv3x xfce4 compositing issue, making good progress, need help / input

[Ilia Mirkin]

On Fri, Sep 25, 2015 at 10:34 AM, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
> On 11-09-15 18:48, Ilia Mirkin wrote:
>>
>> On Fri, Sep 11, 2015 at 10:46 AM, Hans de Goede <hdegoede at redhat.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I've been working on trying to fix this one:
>>>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=90871
>>>
>>> And today I've more or less root caused this, it seems
>>> that some code is making glTexImage2D calls with npot
>>> width / height, which fails on nv3x (where as it works
>>> on nv4x).
>>>
>>> The bug has a simple reproducer attached, but that is
>>> not directly calling glTexImage2D, so it seems that
>>> the npot values are coming from some helper library
>>> used (glXBindTexImageEXT  ?).
>>>
>>> 2 questions:
>>>
>>> 1) Does anyone know / suspect where the glTexImage2D call
>>> is originating from (see the test-program attachment
>>> in bugzilla.
>>>
>>> 2) Is this a bug in glXBindTexImageEXT (assuming that is
>>> the culprit), or should the test program take into account
>>> that the card does not support npot when calling this ?
>>
>>
>> Without directly answering your questions (as I don't know the
>> answers), without NPOT support (which nv3x doesn't have), you can only
>> use non-power-of-two textures with GL_TEXTURE_RECTANGLE, not
>> GL_TEXTURE_2D. The program that you have does appear to detect this
>> though, and uses the rect target if ARB_texture_rectangle is
>> available, which it should be. I guess it should just bail if both
>> ARB_texture_rectangle and ARB_texture_non_power_of_two aren't
>> available...
>
>
> I've been working on getting to the bottom of this one. The NPOT problem
> is only part of the story (and can be worked around I believe)
>
> The real problem seems to be that nv3x cards only support swizzled textures
> and not linear ones. This makes it sorta hard to do texture-from-pixmap.
> Specifically when trying to use glXBindTexImageEXT with a local client we
> end up in gallium/state_trackers/dri/dri_drawable.c: dri_set_tex_buffer2()
> which calls nv30_miptree_from_handle() on the first call on a certain pixmap
> and is a nop after that.
> dri_set_tex_buffer2() does call drawable->update_tex_buffer() every time but
> that currently is a nop
>
> There are 2 possible solutions here:
> 1) Make nv30_miptree_from_handle() create a new bo rather then calling
>    bo_from_handle() when called to create a texture (rather then a front /
>    back buffer), and override the default nop drawable->update_tex_buffer()
>    with a function calling nv30_transfer_rect to copy the linear pixmap
>    data into the swizzled texture we've newly allocated
> 2) Solution one involves a blit, so is not going to be very fast, so
>    alternatively we could simply stop claiming that
> GLX_EXT_texture_from_pixmap
>    is supported on nv3x (it does work on nv4x already as that has support
>    for linear textures)

Looking at the spec, it actually looks like you can drop
GLX_TEXTURE_2D_BIT to make 2D textures go away, and mark them all RECT
in bo_from_handle() [for nv3x only of course]. Now
src/gallium/state_trackers/glx/xlib/glx_api.c always includes this
bit, but it should be easy to remove this if you don't have NPOT
texture support, or based on some PIPE_CAP (should probably check with
the r300 folk for how the ati ddx handles this). Of course this
approach might just be asking for trouble from non-conformant
compositors which don't check if it's ending up as a 2D or RECT
texture.

3) Change the DDX to swizzle POT-sized pixmaps. From the spec:

    - If only GL_ARB_texture_rectangle is supported GL_TEXTURE_2D will
      be used for all power of two pixmap sizes and GL_TEXTURE_RECTANGLE_ARB
      will be used for all non power of two pixmap sizes.

This however might end up a bit problematic since you can't apriori
know whether you'll have to scan out a pixmap (but I'd like to see a
POT-sized monitor), and also all the fragment programs probably assume
RECT coordinates.

>
> So Ilia, with your mesa nouveau maintainer hat on, which solution shall we
> implement?

Since the "we" is really "you", it's really your call. It sounds like
the main users of GLX_EXT_texture_from_pixmap are compositors... AFAIK
most GL-based compositors require GL2 anyways, so this is probably not
that big of an issue. I'd just drop that bit, or the whole ext. But if
you want to try some of the other solutions, that's fine with me as
well :)

> Do you want me to try and do 1 (which will also fix the npot thingie since
> we
> can simply round up to pot when allocating the new bo), or should we simply
> throw in our hat and just not support GLX_EXT_texture_from_pixmap on
> these old cards?
>
> Regards,
>
> Hans
>