Hi,
On 11-09-15 18:48, Ilia Mirkin wrote:
On Fri, Sep 11, 2015 at 10:46 AM, Hans de Goede <hdego...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
