https://bugs.freedesktop.org/show_bug.cgi?id=90871
--- Comment #38 from Hans de Goede <[email protected]> --- (In reply to Hans de Goede from comment #35) > The problem is the next messages. It seems that something (not fptest > directly) is calling glTexImage2D with a npot width / height, where as nv3x > is not npot capable. 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) -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.
_______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
