RFE: Investigate whether it is possible/usefull to support GLX in Xprt. I've played a little bit around in the last hour and it seems to work... but I am still not sure if all the stuff supported by GLX/OpenGL will work well with "paginated devices".
Created attachment 229 [details] [review] Patch to modify "glxgears" for print output
Created attachment 230 [details] [review] Patch for xc/programs/Xserver/ sources to enable GLX for Xprint
Created attachment 231 [details] PDF output of modified glxgears, 22 pages. DIN-A5, 300DPI
Comment on attachment 231 [details] PDF output of modified glxgears, 22 pages. DIN-A5, 300DPI OK, it seems that this sample PDF job is for the trashcan. SuSE 8.2's /usr/lib/libGL.so links to /usr/lib/GL/libGL.so.1.4.mesasoft by default which bypasses the GLX protocol completely and just renders via XPutImage(). Adjusting the link to /usr/lib/GL/libGL.so.1.2.xf86_glx results in a nice "Error: couldn't get an RGB, Double-buffered visual" from "glxgears". It seems that the Xserver-side patch still needs work... ;-(
It seems there is something special required to mark a visual as "GLX-enabled"... does anyone have a clue what needs to be done for that ?
Some additiona info: glxinfo output is interesting: -- snip -- % glxinfo -display :50 -t name of display: :50.0 Error: couldn't find RGB GLX visual Vis Vis Visual Trans buff lev render DB ste r g b a aux dep ste accum buffers MS MS ID Depth Type parent size el type reo sz sz sz sz buf th ncl r g b a num bufs ---------------------------------------------------------------------------------------------------- 0x21 24 TrueColor 1 0 0 ci 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0x22 8 PseudoColor 1 0 0 ci 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -- snip -- Note the "ci" (color-indexed visual) entry for the "TrueColor" line - that cannot be right. More digging in the glxinfo sources shows that all the data are simply "0", which means: Not initalised. Something in the Xserver-side GLX extension code is going wrong... ... then I added some debug code to xc/programs/Xserver/GL/glx/glxscreens.c - it seems that in |void __glXScreenInit(GLint numscreens)| |__glXActiveScreens[i].numUsableVisuals| is set to |0|, e.g. no "useable GL visuals". Fun... ;-( Maybe |__MESA_initVisuals| is broken somehow...
I've fixed this and will commit the patch once Egbert has finished with the trunk.
Alan Hourihane wrote: > I've fixed this and will commit the patch once Egbert has finished with the > > trunk. Two minor things: 1. Can you attach the patch here that I can take a look at it first, please ? 2. Please don't commit the glxgears.c patch... I have to clean it up and adjust it that it allows both "display" and "print" mode... the current patch (attachment 229 [details] [review]) only supports printer output...
Actually, all the problems are with Xprint itself and nothing to do with Mesa or GLX.
Created attachment 237 [details] [review] Fix bugs in X visual setup, and enable GLX extension This patch fixes bugs in Xprint's visuals setup code and also enables the GLX extension
Created attachment 238 [details] [review] reduce warnings during compilation patch When compiling Xprint, it outputs lots and lots of warnings. This patch clears up some of the more painful ones.
Alan Hourihane wrote: > Created an attachment (id=237) > Fix bugs in X visual setup, and enable GLX extension > This patch fixes bugs in Xprint's visuals setup code and also enables the GLX > extension The patch gets "glxinfo" working... but unfortunately the Xprint-enabled "glxgears" version (from attachment 229 [details] [review]) crashes Xprt. On the client ("glxgears") side the stack trace look like this (I added a XSyncronize() to ensure the requests are in sync): -- snip -- 0x402d5342 in select () from /lib/libc.so.6 (gdb) where #0 0x402d5342 in select () from /lib/libc.so.6 #1 0x40186fe8 in __JCR_LIST__ () from /usr/X11R6/lib/libX11.so.6 #2 0x400f1298 in _XRead () from /usr/X11R6/lib/libX11.so.6 #3 0x400f1dbf in _XReply () from /usr/X11R6/lib/libX11.so.6 #4 0x400ecce5 in XSync () from /usr/X11R6/lib/libX11.so.6 #5 0x400ecda5 in _XSyncFunction () from /usr/X11R6/lib/libX11.so.6 #6 0x40086f26 in __glXFlushRenderBuffer () from /usr/lib/libGL.so.1 #7 0x40059b98 in __indirect_glEndList () from /usr/lib/libGL.so.1 #8 0x0804b3ef in init () at glxgears.c:304 #9 0x0804bef2 in main (argc=5, argv=0xbffff684) at glxgears.c:626 #10 0x4020f8ae in __libc_start_main () from /lib/libc.so.6 -- snip -- ... e.g. it crashes in the |glEndList()| call in line 304: -- snip -- 299 /* make the gears */ 300 gear1 = glGenLists(1); 301 glNewList(gear1, GL_COMPILE); 302 glMaterialfv(GL_FRONT, GL_AMBIENT_AND_DIFFUSE, red); 303 gear(1.0, 4.0, 1.0, 20, 0.7); 304 glEndList(); 305 306 gear2 = glGenLists(1); -- snip -- On the Xserver side the stack trace look like this: -- snip -- (gdb) where #0 0x0839371e in NORMALF (x=0, y=0, z=1) at t_imm_api.c:603 #1 0x083937b5 in _tnl_Normal3fv (v=0x8ce0cd0) at t_imm_api.c:624 #2 0x0822e85b in glNormal3fv (v=0x8ce0cd0) at ../../../../../extras/Mesa/src/glapitemp.h:348 #3 0x081f83b5 in __glXDisp_Normal3fv (pc=0x8ce0cd0 "") at g_render.c:410 #4 0x0821a689 in __glXRender (cl=0x8a1a910, pc=0x8ce0ccc "\020") at glxcmds.c:1320 #5 0x081f6bcb in __glXDispatch (client=0x8b2f348) at glxext.c:434 #6 0x08074179 in Dispatch () at dispatch.c:454 #7 0x0805b1e9 in main (argc=6, argv=0xbffff6b4, envp=0xbffff6d0) at main.c:442 #8 0x400c48ae in __libc_start_main () from /lib/libc.so.6 -- snip -- I have turned NORMALF from a C macro into a C function - after that gdb gave me the hint that |IM| is |NULL|: -- snip -- Program received signal SIGSEGV, Segmentation fault. 0x0839371e in NORMALF (x=0, y=0, z=1) at t_imm_api.c:603 603 count = IM->Count; (gdb) print IM $1 = (struct immediate *) 0x0 -- snip --
Created attachment 243 [details] [review] Fix bugs in X visual setup, and enable GLX extension [checked-in] I'll check this patch in for now since it seems to be a good idea to get the visual setup fixed anyway.
Comment on attachment 243 [details] [review] Fix bugs in X visual setup, and enable GLX extension [checked-in] Attachment #243 [details] checked-in Checking in ChangeLog; /cvs/xorg/xc/ChangeLog,v <-- ChangeLog new revision: 1.9; previous revision: 1.8 done Checking in programs/Xserver/Xprint/Imakefile; /cvs/xorg/xc/programs/Xserver/Xprint/Imakefile,v <-- Imakefile new revision: 1.3; previous revision: 1.2 done Checking in programs/Xserver/Xprint/ps/Imakefile; /cvs/xorg/xc/programs/Xserver/Xprint/ps/Imakefile,v <-- Imakefile new revision: 1.3; previous revision: 1.2 done Checking in programs/Xserver/Xprint/ps/PsInit.c; /cvs/xorg/xc/programs/Xserver/Xprint/ps/PsInit.c,v <-- PsInit.c new revision: 1.3; previous revision: 1.2 done Checking in programs/Xserver/mi/miinitext.c; /cvs/xorg/xc/programs/Xserver/mi/miinitext.c,v <-- miinitext.c new revision: 1.3; previous revision: 1.2 done Mailing the commit message to xorg-commit@pdx.freedesktop.org...
Alan: Any idea what is going wrong in comment #12 ?
Mesa in the X.Org tree is still based on 5.0.2, and there was a fix in Mesa 6.0 which creates the buffers properly. I've copied that fix to the Mesa 5.0.2 file and glxgears (from attachment 229 [details] [review]) works here now. So I've committed it.
One thing to note in this Roland, is that Mesa has hardcoded maximum dimensions for width and height. In Mesa 5.0.2 that's only 2048x2048, and in Mesa 6.0 it's 4096x4096. This is a far cry from printer resolutions.
Alan Hourihane wrote: > Mesa in the X.Org tree is still based on 5.0.2, and there was a fix in Mesa > 6.0 which creates the buffers properly. > I've copied that fix to the Mesa 5.0.2 file and glxgears (from attachment 229 [details] [review]) > works here now. Nice! Thanks! > So I've committed it. Erm... there is a problem with the commit: -- snip -- Modified files: xc/extras/Mesa/src/X/: Tag: XORG-CURRENT xm_dd.c -- snip -- If I understand this right XORG-CURRENT content was moved to "trunk" and XORG-CURRENT is now frozen, obsolete and checkins forbidden... ;-(
Alan Hourihane wrote: > One thing to note in this Roland, is that Mesa has hardcoded maximum > dimensions for width and height. In Mesa 5.0.2 that's only 2048x2048, and in > Mesa 6.0 it's 4096x4096. > This is a far cry from printer resolutions. Can that limit be bumped to a higher value somehow ?
Alan: BTW: For the PostScript DDX it may be worth to check whether http://www.geuz.org/gl2ps/ can be integrated. The tricky part may be that this would mean that different screens use different OpenGL engines... and I am not sure whether this is possible...
In reply to comment #19 The values can be bumped, but Mesa creates buffers. For example if you bumped it to 8192x8192 you'll end up creating a couple of 256MB buffers at a depth 24 resolution. Also, at some point you'll run into rendering errors because of precision problems by increasing it too far. That's why we only bumped it to 4Kx4K in Mesa 6.0 as that's reasonable - any furthur and it could get sticky.
In reply to comment #18 I've committed the fix to the trunk now
In reply to comment #20 That program seems to have some severe limitations.
Alan Hourihane wrote: > In reply to comment #18 > > I've committed the fix to the trunk now Thank you very much! :)
Alan Hourihane wrote: > In reply to comment #19 > > The values can be bumped, but Mesa creates buffers. For example if you bumped > it to 8192x8192 you'll end up creating a couple of 256MB buffers at a depth 24 > resolution. Well, mmap() of temporary files could be used for those buffers... =:-) OKOK, _bad_ idea since the PS output will still be gigantic... I still hope there is a way to hook-up a OpenGL--->PS engine which translates the OpenGL rendering calls into PostScript code... the Mesa code would then only be used for the other DDX (PCL, Raster, etc.). > Also, at some point you'll run into rendering errors because of precision > problems by increasing it too far. That's why we only bumped it to 4Kx4K in > Mesa 6.0 as that's reasonable - any furthur and it could get sticky. I have tried 8192x8192 pixels with the current Mesa version in "trunk" and that seems to work perfectly... and is more than enougth for DIN-A4 at 600DPI. There is still the issue what will happen if the size is "too large" - will an error be generated and forwarded to the client side (e.g. something like "RequestTooLarge"), will the GLX drawable size silenty be truncated or what will happen ? BTW: Is there a way to peek the maximum dimensions supported by the rasterizer at the client side ?
Alan Hourihane wrote: > In reply to comment #20 > > That program seems to have some severe limitations. 1. Can you make a small summary what exactly is "missing" in "gl2ps", please ? 2. Do you know any "better" solution than using "gl2ps" ?
In reply to comment #25 Running 8192x8192 may not show anomalies with all applications, it really depends on what they're doing. As for interrogating the GL's maximum viewport do :- GLint max[2]; glGetIntegerv(GL_MAX_VIEWPORT_DIMS, max);
In reply to comment #26 I don't really have the time to go through that application, but the lack of texture support is major.
For the log: I filed two spin-off bugs to move the work on glxgears and the build warnings out of this bug: 1. Bug 558 - 'RFE: Add Xprint support to "glxgears"' 2. Bug 559 - 'RFE: Fix some build warnings in Xprint code'
Alan Hourihane wrote: > In reply to comment #26 > I don't really have the time to go through that application, but the lack of > texture support is major. OK... would it still be possible to add the gs2ps engine to Xprt ? If "yes"... is it possible to have two (or more) different OpenGL engines (like "Mesa" and "gl2ps") working on different screens at the same time in the same Xserver instance ?
You can't have two OpenGL engines operating at the same time - no.
I am not sure whether this is related: Tody I noticd a weired behaviour of Xprt: The Xprt process starts to consume nearly 100% CPU time doing nothing. Trying to get stack trace samples I am getting this: -- snip -- 0x40163041 in gettimeofday () from /lib/libc.so.6 (gdb) where #0 0x40163041 in gettimeofday () from /lib/libc.so.6 #1 0x0804c1c2 in GetTimeInMillis () #2 0x08079a6d in WaitForSomething () #3 0x0806cb49 in Dispatch () #4 0x0805a63b in main () #5 0x400de8ae in __libc_start_main () from /lib/libc.so.6 -- snip .. Alanh: Is it possible that this issue is related to te GLX changes or is this a different problem ?
Roland Mainz wrote: > The Xprt process starts to consume nearly 100% CPU time doing nothing. ... and running "xplsprinters" on that server gets rid of the problem - the server stops hogging the CPU. Weired.
I filed bug 567 ("Xorg Xprt starts to consume 100% CPU when being idle for some time") for the problem found in comment #32.
Alan Hourihane wrote: > You can't have two OpenGL engines operating at the same time - no. Is it possible that Mesa can handle different (Mesa) drivers on different screens ?
Yes, that's possible
Alan Hourihane wrote: > Yes, that's possible Is it possible to modify gl2ps to work as Mesa driver ?
Anything's possible
Closing WONTFIX because nobody cares about Xprint. Reopen if you plan to address this bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.