[Nouveau] [Bug 90871] NV30: Xfwm4 use_compositing - garbled display

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=90871

--- Comment #38 from Hans de Goede <jwrdegoede at fedoraproject.org> ---
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20150925/0a4aea46/attachment.html>