Bug 542

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.