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

[Hans de Goede]

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)

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

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