- Fedora 21 - working Xfvm4 compositing setup:

xorg-x11-server-Xorg 1.16.3-2.fc21
xorg-x11-drv-nouveau 1.0.11-1.fc21
mesa 10.4.7-1.20150323.fc21
libdrm 2.4.60-1.fc21
libXpresent 1.0.0-1.fc21
xfwm4 4.12.3-3.git20150518.fc21


- Fedora 22 - none working Xfvm4 compositing setup - garbled display:

xorg-x11-server-Xorg 1.17.1-12.fc22
xorg-x11-drv-nouveau 1.0.11-2.fc22
mesa 10.5.4-1.20150505.fc22
libdrm 2.4.61-3.fc22
libXpresent 1.0.0-1.fc22
xfwm4 4.12.3-3.git20150518.fc22

All component downgraded to versions such as working setup on Fedora 21,
but without positive effect.
Looks like libepoxy has become broken for unknown reasons.

(In reply to poma from comment #2)
> All component downgraded to versions such as working setup on Fedora 21,
> but without positive effect.
> Looks like libepoxy has become broken for unknown reasons.

You mean it's a regression between F21 and F22?

Then it isn't libepoxy (which is just a conveninent library to load GL extensions and such) nor the DDX but most likely Mesa or DRI/DRM instead.

What I actually wanted to write,
epoxy support is related to the usage, enablement of the OpenGL, right?
And here it is about compositing part.
If I understood this library simplifies writing code related to OpenGL.

About distro versions "regression",
I expected the Xorg/Mesa/libdrm from Fedora 21 to work also on Fedora 22,
but surprise, surprise, it didn't happen.

I tested also
[Mesa-announce] Mesa 10.5.7
http://lists.freedesktop.org/archives/mesa-announce/2015-June/000157.html
No effect positivo.

Also it is not possible to test whether the NV30 works with 'modesetting':

Driver "modesetting"
~~~~~~
Require OpenGL version 2.1 or later.
(EE) modeset(0): Failed to initialize glamor at ScreenInit() time.
(EE) 
Fatal server error:
(EE) AddScreen/ScreenInit failed for driver 0
(EE) 
(EE) Server terminated with error (1). Closing log file.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Driver "modesetting"
Option "AccelMethod" "none"
~~~~~~
(II) AIGLX: Screen 0 is not DRI2 capable
(EE) AIGLX: reverting to software rendering
(II) AIGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0
(EE) 
Fatal server error:
(EE) failed to create screen resources(EE) 
(EE) Server terminated with error (1). Closing log file.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Therefore for now I can not conclude what this is all about.
At least Xpresent rendering works, although "serrated" - not quite tear-free.

I recompiled Fedora 21 versions:

libdrm-2.4.60-1.fc22.i686
xorg-x11-server-common-1.16.3-2.fc22.i686
xorg-x11-server-Xorg-1.16.3-2.fc22.i686
xorg-x11-drv-modesetting-0.9.0-2.fc22.i686
xorg-x11-drv-nouveau-1.0.11-1.fc22.i686
mesa-dri-drivers-10.4.7-1.20150323.fc22.i686
mesa-filesystem-10.4.7-1.20150323.fc22.i686
mesa-libEGL-10.4.7-1.20150323.fc22.i686
mesa-libgbm-10.4.7-1.20150323.fc22.i686
mesa-libGL-10.4.7-1.20150323.fc22.i686
mesa-libglapi-10.4.7-1.20150323.fc22.i686
mesa-libGLES-10.4.7-1.20150323.fc22.i686

and tried once more,
but the result is the same - "analytical cubism" - with Xfwm4 GLX build
$ xfconf-query -c xfwm4 -p /general/use_compositing
true


Interestingly, in contrast to Xorg-1.17.1,
on Xorg-1.16.3 NV30 can work with 'modesetting':

[ 8.911] 
X.Org X Server 1.16.3
Release Date: 2014-12-20
[ 8.911] X Protocol Version 11, Revision 0
[ 8.911] Build Operating System: lnx 4.0.4-303.fc22.i686 
[ 8.914] Build Date: 09 June 2015  04:53:40PM
[ 8.914] Build ID: xorg-x11-server 1.16.3-2.fc22 
[ 8.914] Current version of pixman: 0.32.6
[ 8.914] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun  9 19:36:31 2015
[ 8.915] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 8.915] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 8.915] (==) No Layout section.  Using the first Screen section.

[ 8.915] (==) No screen section available. Using defaults.
[ 8.915] (**) |-->Screen "Default Screen Section" (0)
[ 8.915] (**) |   |-->Monitor "<default monitor>"
[ 8.916] (==) No device specified for screen "Default Screen Section".
	Using the first device section listed.
[ 8.916] (**) |   |-->Device "NVIDIA NV34"
[ 8.916] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[ 8.916] (==) Automatically adding devices
[ 8.916] (==) Automatically enabling devices
[ 8.916] (==) Automatically adding GPU devices
[ 8.916] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 8.916] (II) Loader magic: 0x8282740
[ 8.916] (II) Module ABI versions:
[ 8.916] 	X.Org ANSI C Emulation: 0.4
[ 8.916] 	X.Org Video Driver: 18.0
[ 8.916] 	X.Org Server Extension : 8.0
[ 8.924] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 8.929] (II) LoadModule: "glx"
[ 8.929] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 8.948] (II) Module glx: vendor="X.Org Foundation"
[ 8.948] 	compiled for 1.16.3, module version = 1.0.0
[ 8.948] 	ABI class: X.Org Server Extension, version 8.0
[ 8.948] (==) AIGLX enabled
[ 8.948] (II) LoadModule: "modesetting"
[ 8.948] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 8.948] (II) Module modesetting: vendor="X.Org Foundation"
[ 8.948] 	compiled for 1.16.3, module version = 0.9.0
[ 8.948] 	Module class: X.Org Video Driver
[ 8.948] 	ABI class: X.Org Video Driver, version 18.0
[ 8.948] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 8.948] (++) using VT number 1

[ 8.949] (II) modesetting(0): using drv /dev/dri/card0
[ 8.949] (II) modesetting(0): Creating default Display subsection in Screen section
[ 9.039] (II) modesetting(0): Output DVI-0 has no monitor section
[ 9.186] (II) modesetting(0): EDID for output DVI-0
[ 9.215] (II) modesetting(0): Output DVI-0 connected
[ 9.217] (==) modesetting(0): Backing store enabled
[ 9.217] (II) modesetting(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[ 9.238] (==) modesetting(0): DPMS enabled
[ 9.260] (--) RandR disabled
[ 9.277] (II) AIGLX: Screen 0 is not DRI2 capable
[ 9.277] (EE) AIGLX: reverting to software rendering
[ 9.295] (II) AIGLX: Loaded and initialized swrast
[ 9.295] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 9.297] (II) modesetting(0): Damage tracking initialized
[ 9.297] (II) modesetting(0): Setting screen physical size to 370 x 277
...

Same with latest git:

mesa-dri-drivers-10.7.0-0.devel.1.563706c.fc22.i686
mesa-filesystem-10.7.0-0.devel.1.563706c.fc22.i686
mesa-libEGL-10.7.0-0.devel.1.563706c.fc22.i686
mesa-libgbm-10.7.0-0.devel.1.563706c.fc22.i686
mesa-libGL-10.7.0-0.devel.1.563706c.fc22.i686
mesa-libglapi-10.7.0-0.devel.1.563706c.fc22.i686
mesa-libGLES-10.7.0-0.devel.1.563706c.fc22.i686
mesa-libGLU-9.0.0-7.fc22.i686
mesa-libGLw-8.0.0-5.fc22.i686
mesa-libOpenCL-10.7.0-0.devel.1.563706c.fc22.i686
mesa-libOSMesa-10.7.0-0.devel.1.563706c.fc22.i686
mesa-libwayland-egl-10.7.0-0.devel.1.563706c.fc22.i686
mesa-libxatracker-10.7.0-0.devel.1.563706c.fc22.i686
mesa-omx-drivers-10.7.0-0.devel.1.563706c.fc22.i686
mesa-vdpau-drivers-10.7.0-0.devel.1.563706c.fc22.i686

Created attachment 116415 [details]
Xfwm4 GLX compositing NV34 Mesa 10.7.0 devel git 563706c

Created attachment 116416 [details]
glxinfo NV34 OpenGL 1.5 Mesa 10.7.0 devel git 563706c

(In reply to poma from comment #5)
...
> Interestingly, in contrast to Xorg-1.17.1,
> on Xorg-1.16.3 NV30 can work with 'modesetting':
> 

FTR
Xorg-1.17.1 'modesetting' ist kaputt also with NV50.

(In reply to poma from comment #9)
> (In reply to poma from comment #5)
> ...
> > Interestingly, in contrast to Xorg-1.17.1,
> > on Xorg-1.16.3 NV30 can work with 'modesetting':
> > 
> 
> FTR
> Xorg-1.17.1 'modesetting' ist kaputt also with NV50.

Precisely - with 32 bit
https://bugs.freedesktop.org/show_bug.cgi?id=90978

Created attachment 116536 [details]
test program


Can you try with this test program and see if you can reproduce:

1. Save attachment as tfp-test.c

2. Build with 

  $ gcc -g tfp-test.c -o tfp-test $(pkg-config --cflags --libs epoxy xrender xfixes xcomposite x11)

3. Run with 

  $ ./tfp-test

4. Use the mouse button to chaneg the Pixmap/texture or press a key to exit.

If you can reproduce then we may have a simple reproducer, that could be helpful with the investigation.

BTW, irrespective of any shortcomings in the modesetting driver, there's 0 chance that GLAMOR will work on nv3x. And like 0.00000000000000001% chance it'll work on nv4x. The driver logic is just not there to handle those giant shaders. It should, however, work fine on nv50+, which has a real compiler backing it.

With xf86-video-nouveau you should be getting dedicated EXA acceleration logic. I did notice a small bug in some of the pre-nv50 logic while trying to fix something else:

http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=278ad73475bd137eac8a49ec7a22406bfc2867e7

Unlikely to fix anything for you, but thought I'd mention it.

Created attachment 116544 [details]
xfwm4-debug-1328.log


xfwm4-4.12.3-11.3.glx.debug.full.git20150615.fc22.i686
xfwm4-debuginfo-4.12.3-11.3.glx.debug.full.git20150615.fc22.i686

Déjà vu, en mouvement:
http://goo.gl/Gm4ffO
Screencast/discothèque.webm

-_-

(In reply to poma from comment #13)

I am not sure xfwm4 logs will help much here.

What about the test program I posted in comment 11, it does the same as xfwm4 but in a much shorter/simpler code so if you can reproduce with that, this may help investigating more than just the xfwm4 logs.

(In reply to Olivier Fourdan from comment #14)
> (In reply to poma from comment #13)
> 
> I am not sure xfwm4 logs will help much here.
> 
> What about the test program I posted in comment 11, it does the same as
> xfwm4 but in a much shorter/simpler code so if you can reproduce with that,
> this may help investigating more than just the xfwm4 logs.


Déjà vu, déjà vu.

It's already done - this is a visual record:
http://goo.gl/Gm4ffO
Screencast/discothèque.webm

xfwm4-debug-1328.log is a record of the entire session, 
-including- 'tfp-test' run.

Created attachment 117490 [details]
lovelock.png OK - no comps

Created attachment 117491 [details]
lovelock.png KO/garbled - comps GLX

Olivier, can you tell, just by looking at garbled pattern, what the actual problem is, the same as Hans de and Ilia do in
http://lists.freedesktop.org/archives/nouveau/2015-August/021767.html
"Look at the white pattern of the moon".

Harder to tell, but I think one of two things is happening:

(a) You have the inverse problem. You're getting a linear texture that's being interpreted as if it were swizzled.
(b) Uninitialized video ram which happened to be some (set of) textures in a former life.

I'm tending a bit more towards (b) but not 100% sure. I don't know how you could end up with linear texture data but think it's swizzled, but I'm also not extremely well-versed in nv30 driver specifics.

Thanks for the explanation.

Test GLX compositing & tfp-test:
http://goo.gl/Gm4ffO
vids/discothèque.webm

I've tried reproducing this on my oldest card which is a nv43 card, but I'm afraid that this does not reproduce there ...

Hans, do you test exclusively GNOME environment?

Hi,

(In reply to poma from comment #23)
> Hans, do you test exclusively GNOME environment?

No to reproduce I did "dnf groupinstall "XFCE Desktop", then startxfce4, and ensured it was in composting mode, all of this on a fully up2date F-22. I did not see the problem you are seeing while doing this on a nv43 card.

Regards,

Hans

(In reply to Hans de Goede from comment #24)
> Hi,
> 
> (In reply to poma from comment #23)
> > Hans, do you test exclusively GNOME environment?
> 
> No to reproduce I did "dnf groupinstall "XFCE Desktop", then startxfce4, and
> ensured it was in composting mode, all of this on a fully up2date F-22. I
> did not see the problem you are seeing while doing this on a nv43 card.
> 
> Regards,
> 
> Hans


Here you can find the source rpm of the Xfce's window manager with GLX support:
http://goo.gl/Gm4ffO
source/xfwm4-4.12.3-11.2.glx.git20150615.fc22.src.rpm

Besides it is an integral part of the test compilation:
http://goo.gl/Gm4ffO
iso/Twenty-Two-Xfce-Live-*.iso


Ref.
compositor: Add support for GLX
http://git.xfce.org/xfce/xfwm4/commit/?id=fee08ea

(In reply to poma from comment #25)
> Here you can find the source rpm of the Xfce's window manager with GLX
> support:
> http://goo.gl/Gm4ffO
> source/xfwm4-4.12.3-11.2.glx.git20150615.fc22.src.rpm
> 
> Besides it is an integral part of the test compilation:
> http://goo.gl/Gm4ffO
> iso/Twenty-Two-Xfce-Live-*.iso
> 
> 
> Ref.
> compositor: Add support for GLX
> http://git.xfce.org/xfce/xfwm4/commit/?id=fee08ea

Interesting so what you are saying is that the default F-22 xfwm builds do not have this patch, and thus cannot be used to reproduce the problem ?

(In reply to Hans de Goede from comment #26)
> (In reply to poma from comment #25)
> > Here you can find the source rpm of the Xfce's window manager with GLX
> > support:
> > http://goo.gl/Gm4ffO
> > source/xfwm4-4.12.3-11.2.glx.git20150615.fc22.src.rpm
> > 
> > Besides it is an integral part of the test compilation:
> > http://goo.gl/Gm4ffO
> > iso/Twenty-Two-Xfce-Live-*.iso
> > 
> > 
> > Ref.
> > compositor: Add support for GLX
> > http://git.xfce.org/xfce/xfwm4/commit/?id=fee08ea
> 
> Interesting so what you are saying is that the default F-22 xfwm builds do
> not have this patch, and thus cannot be used to reproduce the problem ?


4.12.3 is a bug fix release - 2015-05-16:
https://mail.xfce.org/pipermail/xfce-announce/2015-May/000416.html

Although the "compositor: Add support for GLX" commit is the earlier date - 2015-04-24,
it still has not entered the release.

I guess, Olivier left us time to test.


$ grep -R -i glx xfwm4-4.12.3-2.fc23.src/xfwm4-4.12.3/ | wc -l
0
$ grep -R -i glx xfwm4-4.12.3-11.2.glx.git20150615.fc24.src/xfwm4-8a67212/ | wc -l
175

Hi,
(In reply to poma from comment #27)
> (In reply to Hans de Goede from comment #26)
> > (In reply to poma from comment #25)
> > > Here you can find the source rpm of the Xfce's window manager with GLX
> > > support:
> > > http://goo.gl/Gm4ffO
> > > source/xfwm4-4.12.3-11.2.glx.git20150615.fc22.src.rpm
> > > 
> > > Besides it is an integral part of the test compilation:
> > > http://goo.gl/Gm4ffO
> > > iso/Twenty-Two-Xfce-Live-*.iso
> > > 
> > > 
> > > Ref.
> > > compositor: Add support for GLX
> > > http://git.xfce.org/xfce/xfwm4/commit/?id=fee08ea
> > 
> > Interesting so what you are saying is that the default F-22 xfwm builds do
> > not have this patch, and thus cannot be used to reproduce the problem ?
> 
> 
> 4.12.3 is a bug fix release - 2015-05-16:
> https://mail.xfce.org/pipermail/xfce-announce/2015-May/000416.html
> 
> Although the "compositor: Add support for GLX" commit is the earlier date -
> 2015-04-24,
> it still has not entered the release.

Ok, so I've build the src.rpm you linked to, and tried to reproduce the problem that way, but I still cannot reproduce it:

[hans@plank ~]$ rpm -q xfwm4
xfwm4-4.12.3-11.2.glx.git20150615.fc22.x86_64

So it looks like this only happens on nv3x and not on nv4x.

Thanks for testing, man.

You'd need xfwm4 from git master (with opengl support) to reproduce or simply use the simple reproducer I attached to this bug some time ago (attachment 116536 [details])

Repetitio est mater sapientiae.

Hi,

(In reply to Olivier Fourdan from comment #30)
> You'd need xfwm4 from git master (with opengl support) to reproduce or
> simply use the simple reproducer I attached to this bug some time ago
> (attachment 116536 [details])

Ok, I just tried with that reproducer, but that also does not reproduce.

I've ordered a quadro nvs280, which is about the only nv3x card with a pci-e interface available. When that arrives I'll try again.

Regards,

Hans

(In reply to Hans de Goede from comment #32)
> Hi,
> 
> (In reply to Olivier Fourdan from comment #30)
> > You'd need xfwm4 from git master (with opengl support) to reproduce or
> > simply use the simple reproducer I attached to this bug some time ago
> > (attachment 116536 [details])
> 
> Ok, I just tried with that reproducer, but that also does not reproduce.
> 
> I've ordered a quadro nvs280, which is about the only nv3x card with a pci-e
> interface available. When that arrives I'll try again.
> 
> Regards,
> 
> Hans


This is a memorabilia category.

http://www.nvidia.com/object/IO_10854.html - AD 2004.
The nouveau project did not exist at that time.

2 of 3 received AGP version,
http://goo.gl/nfim5z

Hi,

(In reply to Hans de Goede from comment #32)
> Hi,
> 
> (In reply to Olivier Fourdan from comment #30)
> > You'd need xfwm4 from git master (with opengl support) to reproduce or
> > simply use the simple reproducer I attached to this bug some time ago
> > (attachment 116536 [details])
> 
> Ok, I just tried with that reproducer, but that also does not reproduce.
> 
> I've ordered a quadro nvs280, which is about the only nv3x card with a pci-e
> interface available. When that arrives I'll try again.

Ok' I've received this card now, and I can reproduce the problem. I'll investigate and try to fix this next week.

Regards,

Hans

Hi,

(In reply to Hans de Goede from comment #34)
> Ok' I've received this card now, and I can reproduce the problem. I'll
> investigate and try to fix this next week.

Ok, so as promised I've been investigating this one the last couple a days.

The fptest.c reproducer works to reproduce it, thanks.

At first I've tried different pitches / to swizzle / tile or not to tile on various involved buffers on both the ddx and mesa side all to no good.

Today I had the bright idea (should have done that earlier) to run fptest through apitrace and then glretrace, this resulted in the following messages:

27 @0 glXCreateWindow(dpy = 0x120b0f0, config = 0x125c9c0, win = 6291457, attri
27: warning: unsupported glXCreateWindow call
49: message: major api error 1: GL_INVALID_VALUE in glTexImage2D(invalid width
49 @0 glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGBA,
49: warning: glGetError(glTexImage2D) = GL_INVALID_VALUE
88: message: major api error 1: GL_INVALID_VALUE in glTexImage2D(invalid width
88 @0 glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGBA,
88: warning: glGetError(glTexImage2D) = GL_INVALID_VALUE
Rendered 2 frames in 0.0754768 secs, average of 26.4982 fps

The 27* messages are there when doing a glretrace on nv4x too, and the retrace works fine on nv4x, so I believe that this warning can be ignored.

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'm a bit lost as to where this call is coming from, and as to whether or not this is a fptest issue, or an issue with the code which is actually making the glTexImage2D call. I'll ask Ben / Ilia for help.

Regards,

Hans

ACPI power states test:
- Suspend to RAM aka S3
- Suspend to Disk aka S4

Xfwm4 flavours:
- "vulgaris" - built w/ --disable-epoxy --disable-xpresent
- "xpresent" - built w/ --disable-epoxy
- "glx"


          ACPI:  S3    S4
Xfwm:
vulgaris          +     -
xpresent          +     -
glx               +     +



Conclusion:
- S3 RESUME, no problemos
- S4 RESUME(THAW), for "vulgaris" and "xpresent",
  HW reset or Magic SysRq key sequence required.
  Not only display is garbled, but literally nothing you can do with it.
  BTW it does not matter whether compositing is on or off.

dmesg - S4 RESUME(THAW) - Xfwm4 "xpresent" - when compositing turned on:

nouveau E[  PGRAPH][0000:01:00.0]  (unknown bits 0x00000080) nsource: nstatus:
nouveau E[  PGRAPH][0000:01:00.0] ch 1 [Xorg[493]] subc 0 class 0x0039 mthd 0x0100 data 0x00000000

(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)

Has there been any progress, any preliminary patch to test?

Hi All,

(In reply to Olivier Fourdan from comment #11)
> Created attachment 116536 [details]
> test program

So after some time away from this bug, I'm back onto it. The problem is that the test program ends up using
GL_TEXTURE_2D type textures / GLX_TEXTURE_2D_EXT target, where it should be using GL_TEXTURE_RECTANGLE_ARB.

The root cause for this seems to be that epoxy_has_glx_extension (dpy, screen, "GL_ARB_texture_rectangle") always returns false, even though the extension is there, as confirmed with both glxinfo and glxgears-info.

Now the extension in question is not a glx-extension, but a gl-extension, so I've also tried calling:
epoxy_has_gl_extension ("GL_ARB_texture_rectangle") but that always returns false too.

Simply forcing has_texture_rectangle = true to work around this (epoxy?) bug actually results in the test program not working anywhere at all (tried both on newer nvidia cards with nouveau and on intel gfx), not sure why. Can you provide a version of the test program where setting has_texture_rectangle = true actually works, or does this work for you ?

As for the fallback to GL_TEXTURE_2D / GLX_TEXTURE_2D_EXT not working on nv3x, this is something which could likely be made to work, but that is quite a bit of work and will be slow. I believe it would be better to first try to get GL_TEXTURE_RECTANGLE_ARB to work, and then see if we still need to get GL_TEXTURE_2D to work at all.

Also in the GL_TEXTURE_2D fallback path you should probably check for npot support for 2d textures (rect textures always support npot) and if that is not available refuse to do compositing at all.

Regards,

Hans

(In reply to Hans de Goede from comment #40)
> Hi All,
> 
> (In reply to Olivier Fourdan from comment #11)
> > Created attachment 116536 [details]
> > test program
> 
> So after some time away from this bug, I'm back onto it. The problem is that
> the test program ends up using
> GL_TEXTURE_2D type textures / GLX_TEXTURE_2D_EXT target, where it should be
> using GL_TEXTURE_RECTANGLE_ARB.
> 
> The root cause for this seems to be that epoxy_has_glx_extension (dpy,
> screen, "GL_ARB_texture_rectangle") always returns false, even though the
> extension is there, as confirmed with both glxinfo and glxgears-info.

Er yeah, it's not a GLX ext, no reason it'd be coming up in the GLX ext list. While similarly-named, they're entirely separate namespaces.

> 
> Now the extension in question is not a glx-extension, but a gl-extension, so
> I've also tried calling:
> epoxy_has_gl_extension ("GL_ARB_texture_rectangle") but that always returns
> false too.

That's surprising.

src/mesa/main/extensions.c:   { "GL_ARB_texture_rectangle",                   o(NV_texture_rectangle),                    GL,             2004 },
src/mesa/state_tracker/st_extensions.c:   extensions->NV_texture_rectangle = GL_TRUE;

So it should actually always be exposed for any st/mesa-backed dri driver (including nv30).

(In reply to Ilia Mirkin from comment #41)
> (In reply to Hans de Goede from comment #40)
> > Hi All,
> > 
> > (In reply to Olivier Fourdan from comment #11)
> > > Created attachment 116536 [details]
> > > test program
> > 
> > So after some time away from this bug, I'm back onto it. The problem is that
> > the test program ends up using
> > GL_TEXTURE_2D type textures / GLX_TEXTURE_2D_EXT target, where it should be
> > using GL_TEXTURE_RECTANGLE_ARB.
> > 
> > The root cause for this seems to be that epoxy_has_glx_extension (dpy,
> > screen, "GL_ARB_texture_rectangle") always returns false, even though the
> > extension is there, as confirmed with both glxinfo and glxgears-info.
> 
> Er yeah, it's not a GLX ext, no reason it'd be coming up in the GLX ext
> list. While similarly-named, they're entirely separate namespaces.
> 
> > 
> > Now the extension in question is not a glx-extension, but a gl-extension, so
> > I've also tried calling:
> > epoxy_has_gl_extension ("GL_ARB_texture_rectangle") but that always returns
> > false too.
> 
> That's surprising.
> 
> src/mesa/main/extensions.c:   { "GL_ARB_texture_rectangle",                 
> o(NV_texture_rectangle),                    GL,             2004 },
> src/mesa/state_tracker/st_extensions.c:   extensions->NV_texture_rectangle =
> GL_TRUE;
> 
> So it should actually always be exposed for any st/mesa-backed dri driver
> (including nv30).

Right, so the issue is that this is done before a GL context is made current. Fixing the code is annoying so I also just hard-coded it to be always-true. And I also just get a gray screen now. The issue is that Redraw() doesn't account for the fact that rect textures are non-normalized. I'm going to hack on this for a bit.

Created attachment 118995 [details]
updated test program

With this I get the same results whether I set has_texture_rectangle = 1 or 0. Attached the full updated source file, or use the patch below.

--- attachment.cgi?id=116536    2015-10-19 17:50:43.552881224 -0400
+++ bug-90871.c 2015-10-19 17:51:09.383618103 -0400
@@ -103,7 +103,11 @@
 
     glPushMatrix ();
 
-    glScaled (1.0, 1.0, 1.0);
+    glMatrixMode(GL_TEXTURE);
+    if (texture_type == GL_TEXTURE_RECTANGLE_ARB)
+        glScaled (pixmap_width, pixmap_height, 1.0);
+    else
+        glScaled (1.0, 1.0, 1.0);
     glTranslated (0.0, 0.0, 0.0);
 
     glBegin (GL_QUADS);
@@ -147,8 +151,8 @@
     int fb_match;
     VisualID xvisual_id;
 
-    has_texture_rectangle =
-        epoxy_has_glx_extension (dpy, screen, "GL_ARB_texture_rectangle");
+    has_texture_rectangle = 1; /*
+        epoxy_has_gl_extension ("GL_ARB_texture_rectangle");*/
     if (has_texture_rectangle)
     {
         printf ("Using texture type GL_TEXTURE_RECTANGLE_ARB\n");

Hi Ilia,

(In reply to Ilia Mirkin from comment #43)
> Created attachment 118995 [details]
> updated test program
> 
> With this I get the same results whether I set has_texture_rectangle = 1 or
> 0. Attached the full updated source file, or use the patch below.

Thanks for the updated test program, this seems to fix things on nv3x. There still is an issue with then test program though (also reproduced on intel gfx) the program is supposed to change the color of the "box" when you click a mouse button (pressing a key exits the program), but currently when using rectangle textures it draws a red box on startup and then on a mouse click everything goes gray, where as the box should turn blue. As said this happens on intel gfx too, so I think there still is an issue with the test program when using rectangle textures.

As for epoxy not seeing the extension, I believe that that is an epoxy issue, as said the extension is clearly listed in both glxinfo and glxgears -info output.

Regards,

Hans

Check out with latest and greatest - epoxy:
http://goo.gl/Gm4ffO
glx/

libepoxy 1.3.1 git b3b8bd9 - 20150929
https://github.com/yaronct/libepoxy

(In reply to Hans de Goede from comment #44)
> Hi Ilia,
> 
> (In reply to Ilia Mirkin from comment #43)
> > Created attachment 118995 [details]
> > updated test program
> > 
> > With this I get the same results whether I set has_texture_rectangle = 1 or
> > 0. Attached the full updated source file, or use the patch below.
> 
> Thanks for the updated test program, this seems to fix things on nv3x. There
> still is an issue with then test program though (also reproduced on intel
> gfx) the program is supposed to change the color of the "box" when you click
> a mouse button (pressing a key exits the program), but currently when using
> rectangle textures it draws a red box on startup and then on a mouse click
> everything goes gray, where as the box should turn blue. As said this
> happens on intel gfx too, so I think there still is an issue with the test
> program when using rectangle textures.

Just my incompetence -- glMatrixMode has to go *before* glPushMatrix, not after. Oops. Moving it up makes the program behave as expected, at least on intel/hsw.

> 
> As for epoxy not seeing the extension, I believe that that is an epoxy
> issue, as said the extension is clearly listed in both glxinfo and glxgears
> -info output.

Pretty sure it's what I said -- the test program doesn't do a glXMakeCurrent before calling gl functions, which means their output is invalid. Not an epoxy issue. Rearranging the test program's code to fix this is annoying though.

I wonder if this is a real issue in xfwm code as well.

(In reply to Ilia Mirkin from comment #46)
> Just my incompetence

Mine, rather.

> glMatrixMode has to go *before* glPushMatrix, not
> after. Oops. Moving it up makes the program behave as expected, at least on
> intel/hsw.
> 
> Pretty sure it's what I said -- the test program doesn't do a glXMakeCurrent
> before calling gl functions, which means their output is invalid. Not an
> epoxy issue. Rearranging the test program's code to fix this is annoying
> though.

No it's not, if the test program is invalid, it ought to be fixed.

> I wonder if this is a real issue in xfwm code as well.

Yes, most likely. This code is still early beta in xfwm4. I'll try to fix it and Poma will be able to test I guess.

(In reply to Olivier Fourdan from comment #47)
> (In reply to Ilia Mirkin from comment #46)
> > Pretty sure it's what I said -- the test program doesn't do a glXMakeCurrent
> > before calling gl functions, which means their output is invalid. Not an
> > epoxy issue. Rearranging the test program's code to fix this is annoying
> > though.
> 
> No it's not, if the test program is invalid, it ought to be fixed.
> 
> > I wonder if this is a real issue in xfwm code as well.
> 
> Yes, most likely. This code is still early beta in xfwm4. I'll try to fix it
> and Poma will be able to test I guess.

The main reason why it's annoying to fix in the test program is that you use that knowledge for selecting fbconfigs... which you need to do before making a context current. Now you could either (a) do a 2-step process whereby you first see if the ext is there, and then go and select another config or (b) make the assumption that rect support is an all-or-nothing thing -- either no configs have it or they all do, so no need to check it when evaluating fbconfig validity.

I'm moderately sure that'd be a valid assumption.

(In reply to Olivier Fourdan from comment #47)
> Yes, most likely. This code is still early beta in xfwm4. I'll try to fix it
> and Poma will be able to test I guess.

Looking at http://git.xfce.org/xfce/xfwm4/tree/src/compositor.c, you have at least the following issues:

    screen_info->has_texture_rectangle =
        epoxy_has_glx_extension (myScreenGetXDisplay (screen_info),
                                 screen_info->screen,
                                 "GL_ARB_texture_rectangle");

    screen_info->has_texture_non_power_of_two =
        epoxy_has_glx_extension (myScreenGetXDisplay (screen_info),
                                 screen_info->screen,
                                 "GL_ARB_texture_non_power_of_two");

These are not GLX exts, they are GL exts, so you have to use epoxy_has_gl_extension. However you have to make sure that a GL context is active (i.e. glXMakeCurrent) before trying to do epoxy_has_gl_extension.

redraw_glx_texture -- this needs to add a width/height scale to the GL_TEXTURE matrix for rect textures, since they use non-normalized coordinates. This probably never came up before since the checks above didn't succeed.

If you don't have has_texture_rectangle *and* you don't have has_texture_non_power_of_two that means that you can only use POT sized pixmaps with GL_TEXTURE_2D. Probably not worth supporting that. AFAIK ~every driver supports ARB_texture_rectangle... except seemingly nv04 (but nv10+ has it).

Marking this as NOTOURBUG for now, if issues persist, feel free to open a new issue.

Many thanks.

Hi,

(In reply to Ilia Mirkin from comment #48)
> or (b) make the assumption that rect support is an all-or-nothing thing -- either
> no configs have it or they all do, so no need to check it when evaluating
> fbconfig validity.

To be clear what Ilia is suggesting here (I believe) is to drop the entire check for GL_ARB_texture_rectangle and instead only check the GLX_TEXTURE_RECTANGLE_BIT_EXT bit in the value returned for GLX_BIND_TO_TEXTURE_TARGETS_EXT, and if that is not set then check for GLX_TEXTURE_2D_BIT_EXT

I agree with Ilia that this should work fine and should fix the detection problem. Actually I was discussing this bug with Ben Skeggs a couple of day ago and he suggested to do exactly this.

I can also confirm that with the glPushMatrix call in the right place, and the rectangle support detection fixed things work fine on a nv34 card.

Regards,

Hans

Can it be tested before it is closed. What's the rush.

(In reply to poma from comment #52)
> Can it be tested before it is closed. What's the rush.

Hans confirmed. It's an application bug, which means this one is just cluttering up bug lists. Nothing to be done wrt nouveau here.

Thank you for your time dudes.

https://bugzilla.xfce.org/show_bug.cgi?id=11962#c27

(In reply to poma from comment #55)
> https://bugzilla.xfce.org/show_bug.cgi?id=11962#c27

Please open new bugs when you have new issues. This is an issue introduced in 4.3. See https://bugzilla.kernel.org/show_bug.cgi?id=106431 for the discussion and patch links.