[Dri-devel] Incomplete scene with OpenGL + direct rendering + mga
[I'm not sure this is a problem with DRI itself, but DRI is definitely
involved and a guy in
comp.os.linux.x told me to ask this list - so I'm trying my luck here.]
I have tried to compile and run some simple OpenGL programs. But lots
of them don't display anything or only part of the scene if direct
rendering is enabled.
However, with LIBGL_ALWAYS_INDIRECT=y the scene looks like it should
do - but animation is extremely slow.
My system is a standard SuSE 8.2 installation with XFree86 4.3.0 and
the standard 2.4.20 kernel.
Graphics adapter: Matrox Millenium G550 (only first head configured)
I would have already tried to upgrade some packages if i had known
where the problem is.
A program demonstrating this is the following.
As this is extracted from example source code of the NeHe OpenGL tutorial
(nehe.gamedev.net) there shouldn't be any coding mistakes in.
--- test.c ---
#include GL/glut.h
#include GL/gl.h
#include GL/glu.h
void InitGL(int Width, int Height)
{
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
glClearDepth(1.0);
glDepthFunc(GL_LESS);
glEnable(GL_DEPTH_TEST);
glShadeModel(GL_SMOOTH);
glViewport(0, 0, Width, Height);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45.0f,(GLfloat)Width/(GLfloat)Height,0.1f,100.0f);
glMatrixMode(GL_MODELVIEW);
}
void DrawGLScene()
{
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
// Move Left 1.5 Units And Into The Screen 6.0
glTranslatef(-1.5f,0.0f,-6.0f);
// draw a triangle
glColor3f( 1.0f, 1.0f, 1.0f );
glBegin(GL_POLYGON);
glVertex3f( 0.0f, 1.0f, 0.0f);
glVertex3f( 1.0f,-1.0f, 0.0f);
glVertex3f(-1.0f,-1.0f, 0.0f);
glEnd();
// Move Right 3 Units
glTranslatef(3.0f,0.0f,0.0f);
// draw another triangle
glColor3f( 1.0f, 0.0f, 0.0f );
glBegin(GL_POLYGON);
glVertex3f( 0.0f, 1.0f, 0.0f);
glVertex3f( 1.0f,-1.0f, 0.0f);
glVertex3f(-1.0f,-1.0f, 0.0f);
glEnd();
glutSwapBuffers();
}
int main(int argc, char **argv)
{
glutInit(argc, argv);
glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
glutInitWindowSize(640, 480);
glutInitWindowPosition(0, 0);
glutCreateWindow(Window Title);
glutDisplayFunc(DrawGLScene);
glutFullScreen();
glutIdleFunc(DrawGLScene);
InitGL(640, 480);
glutMainLoop();
return 0;
}
-
I compile with
$ gcc -o test test.c -lglut -lGLU -lGL
If I run it with
$ ./test
I see one white triangle on the left side of the screen.
If I run with
$ LIBGL_ALWAYS_INDIRECT=y ./test
I see a white triangle on the left side and a red triangle on the
right side.
There aren't any error messages neither in XFree86.0.log nor on the
xterm when running the program - even with MESA_DEBUG=y.
Same result if the OpenGL window is created with GLX or SDL.
'Real', i.e. more complex OpenGL programs like bzflag run without
problems.
Another example demonstrating the problem is the cube example
program that comes with the glut library: With direct rendering
enabled it does only display a black window.
--- Output of glxinfo -
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: VA Linux Systems Inc.
OpenGL renderer string: Mesa DRI G400 20020221 AGP 1x x86/MMX/SSE
OpenGL version string: 1.2 Mesa 4.0.4
OpenGL extensions:
GL_ARB_multisample, GL_ARB_multitexture,
GL_ARB_texture_compression,
GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_abgr,
GL_EXT_bgra, GL_EXT_clip_volume_hint,
GL_EXT_compiled_vertex_array,
GL_EXT_packed_pixels, GL_EXT_polygon_offset,
GL_EXT_rescale_normal,
GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object,
GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos,
GL_NV_texgen_reflection, GL_SGIS_generate_mipmap
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
--
0x23 24 tc 1 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None
0x24 24 tc 1 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None
0x25 24 tc 1 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None
0x26 24 tc 1 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 None
0x27 24 tc 1 24 0 r y . 8 8 8 0 0 0 0 16
Re: [Dri-devel] Incomplete scene with OpenGL + direct rendering + mga
You should try the daily snapshots available from the DRI website... I did so yesterday. I also had to install the XFree86 binary from the 'extra' section and ln -s libexpat.so.0 libexpat.so.1 However, it didn't solve any problem. The examples of my first message still produce the same results as before. :-( Moreover, bzflag does now often freeze. This happens reproducably when enabling the option Smoothing. Freezing means: bzflag cpu usage goes up to 100%, keyboard input is ignored (even Ctrl-Alt-Backspace), but the mouse pointer still moves normally. The only way out is to log in remotely via ssh and kill bzflag. Any further advice? -- GMX Weihnachts-Special: Seychellen-Traumreise zu gewinnen! Rentier entlaufen. Finden Sie Rudolph! Als Belohnung winken tolle Preise. http://www.gmx.net/de/cgi/specialmail/ +++ GMX - die erste Adresse für Mail, Message, More! +++ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Incomplete scene with OpenGL + direct rendering + mga
Doing a glFlush() before glutSwapBuffers() makes the last triangle visible. That's right! At least, this is a temporary workaround so I can go on experimenting with OpenGL programming. But I really hate not being able to play bzflag during lunch time ;-( Nevertheless it's good that I do now know that it is probably the DRI module causing these problems. Any further advice? I'll see if I can solve these issues and get back to you... That would be great. I'd be happy if I could be of any assistance but probably there is nothing I can do on this topic at the moment. Jan -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Incomplete scene with OpenGL + direct rendering + mga
Both problems are now fixed. Wow, that was really quick! I've just tried several OpenGL examples and bzflag and you're absolutely right: It's all fixed. Thanks a lot. :-))) It's a good thing you reported this because your missing triangle was the same bug that caused the mouse cursor to disappear in ut2k3 and some other games :) A simple example with source was extremely helpful. Well, that's how free software works, isn't it? I have my bugfix in ultra-short time and you have the vital hint you need. I've uploaded a new mga_dri.so to my wesite so you don't have to wait for another daily snapshot. Thanks for that, too. :-) Jan -- HoHoHo! Seid Ihr auch alle schön brav gewesen? GMX Weihnachts-Special: Die 1. Adresse für Weihnachts- männer und -frauen! http://www.gmx.net/de/cgi/specialmail +++ GMX - die erste Adresse für Mail, Message, More! +++ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Lightweighted graphics for realtime application
Having my starting problems with OpenGL and DRI fixed (thanks again @Ville) I'm now going for the 'real' project. We are developping an application displaying graphics and animations in realtime for scientific purpose. For programming these graphics on a high level we don't want to use something like DGA (in fact we have an old implementation using XFree86 DGA) but rather OpenGL (with DRI in order to achieve reliably high framerates). But we aren't going to use X because integrating a whole Xserver into RealtimeLinux would be a pain in the ass. Therefore we are looking for a leightweighted hardware abstraction library instead. I found the DRI without X page in the Wiki suggesting MiniGLX, DirectFB and FBDRI. FBDRI does currently work only on Radeon cards and seems to be quite dead. MiniGLX and especially DirectFB look quite promising and I'm going to have a closer look at both. However, there are a few points regarding to which I'd appreciate to hear your opinion: 1. Active development: Future hardware should be supported as well as possible. [I suppose this point is met especially by MiniGLX as they claim to be able to integrate new XFree86 drivers quite easily. Is that true? What about DirectFB?] 2. Running on a dual-headed graphics adapter: I don't know if this is possible at least in principle but it would be optimal if we could run X on one head and have this lean real-time graphics on the second head at the same time. At the moment we have Matrox G550 cards. If this is not possible we would have to use two adapters in one system. 3. Vertical retrace signal: The program must be able to synchronize the graphics generation with the monitor frame rate as we need to know exactly the time each frame is displayed. [I saw there was a patch for DirectFB with mga?] 4. Lightweighted: We need a possibility to render graphics to the screen. This should be as easy as possible but need the mentioned requirements: reliably fast, timing control. We do not need anything else: No windowing, no user interaction (and therefore no keyboard/mouse support), no sound. Solely support for image loading and rendering could be useful, but this could be done by the application itself, too. Looking forward for any comments, ideas or hints Jan -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Lockups...
On Sat, 2005-03-12 at 21:10 -0500, Adam K Kirchhoff wrote: [snip] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner ec8fce80 f7669180 [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held -2147483648 owner ec8fce80 f7669180 irq 16: nobody cared! [c0135a1a] __report_bad_irq+0x2a/0xa0 [c0135380] handle_IRQ_event+0x30/0x70 [c0135b20] note_interrupt+0x70/0xb0 [c01354f3] __do_IRQ+0x133/0x140 [c0104d09] do_IRQ+0x19/0x30 [c010320e] common_interrupt+0x1a/0x20 [snip] FWIW, this irq 16: nobody cared! / Disabling IRQ #16 stuff occurred to me some months ago on a development system with DirectFBGL (mga) + XFree86 running in parallel on two different graphics cards. We managed to work around Disabling IRQ by putting 'noirqdebug' into the kernel command line. Maybe totally irrelevant, so feel free to ignore me, but I thought I'll let you know just in case... Regards, Jan --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FB model basic issues (WAS: radeon, apertures memory mapping)
On Tue, 2005-03-15 at 09:29 -0500, Jon Smirl wrote: Aonther approach would be to just say you have to choose to run one of X, DirectFB, FBUI, XGL and you can't switch between them. Other than developers I don't know if anyone really runs more than one of these at a time. FWIW, yes we do. We're developing a system for neuro-scientific experiments where we enjoy having a fast and lightweight graphics stack with access to VSYNC interrupt (DirectFBGL) for reliable frame timing of visual stimuli. OTOH the experimenter gets a QT control GUI running on a second graphics card with regular X. As this is not very common and quite a hassle to setup (e.g. X stomping on other card's IRQ and the like) I'm eagerly following all efforts to build a common standard graphics base with improved multi-head and GL support. That said, I realise that this is not a very widespread use-case. But nonetheless there are such applications. Thanks, Jan --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Unreliable timing of glXWaitVideoSyncSGI
Hi,
I'm trying to port an application that presents visual stimuli for
experiments in neuroscience from DirectFBGL to X/DRI. A main requirement
is reliable timing of the drawing code, i.e. on every VSYNC a new frame
must be ready in the back buffer so that the buffers can be swapped.
For this purpose I start a graphics thread with SCHED_FIFO scheduler
that does basically this:
while( !Stopped() )
{
glXGetVideoSyncSGI( count1 );
time1 = GetTime( CLOCK_REALTIME );
glXWaitVideoSyncSGI( 2, ( count1 + 1 ) % 2, count2 );
time2 = GetTime( CLOCK_REALTIME );
glXGetVideoSyncSGI( count3 );
if( count3 != prevCount + 1 )
Print( Lost %i frames., count3 - prevCount - 1 );
Print( Draw time: %f ms. Wait time: %f ms.,
time1 - prevTime, time2 - time1 );
prevCount = count3;
prevTime = time2;
glFlush();
glXSwapBuffers( dpy, win );
DrawFrame();
}
Now my problem is: While all the drawing and buffer swapping and
printing works quite deterministic [1] the glXWaitVideoSyncSGI call
seems to hang from time to time, i.e. there are some occurrences where
it takes between 20 and 50 ms to return instead of the normal say 15-16
ms (@60Hz).
The number of these hangs increases drastically from a few lost frames
in 1 frames when there's no load on the system to 1 lost in 5 frames
when there's load on the X server, e.g. by 'tail -f'ing the log file in
an xterm.
This does not happen with DirectFBGL where matroxfb's FBIO_WAITFORVSYNC
ioctl is used for synchronisation - although mga_driver_vblank_wait()
seems to do basically the same as matroxfb_wait_for_sync().
One interesting detail that strikes me: In the above code snippet count2
is always equal to (count1 + 1) so the DRM_WAIT_ON() in
mga_driver_vblank_wait() seems to be woken up always in time. That means
that there must be a later point in the program flow where the thread
sleeps or is being scheduled. However, I could not find such a point in
DRI or Mesa code.
I've been testing and reading code for almost a week now and have made
no progress; so now my last hope is that someone being familiar with the
code can give me some advice or hints.
FWIW, my test systems are:
(a) Debian testing box with a Matrox G550 [2].
(b) Debian unstable box with a Radeon r250 [3].
I haven't noticed any major difference between the two systems'
behaviour other than the mga being _way_ slower [4].
So please: If you have any suggestions where I could look or what I
could try to find the cause of these hangs - I'd be really grateful for
your ideas.
If there's any further information, config/log files or some example
code I could provide feel free to ask.
Thanks in advance,
Jan
PS: One more weird observation: When switching to [EMAIL PROTECTED] mode on my
mga box, glXGetMscRateOML() reports the frame rate to be correctly 75 Hz
but the glXWaitVideoSyncSGI() calls for consecutive frames return with a
rate of about 50 Hz ?!
[1] Example: The Draw time printed in the loop above varies around
1 ms but it is _never_ greater than 3 ms.
[2] CPU: AMD Duron 800 MHz
Graphics card: Matrox G550
Linux 2.6.16 with CONFIG_PREEMPT=y (Debian source)
X.org 7.0.22 (Debian packages)
Mesa: CVS checkout of the mesa_6_4_branch (few days old)
[3] CPU: Intel Pentium M 1.4 GHz
Graphics chipset: ATI Radeon r250 [Mobility FireGL 9000]
Linux 2.6.17 with CONFIG_PREEMPT_NONE=y (Debian image)
X.org 7.0.23 (Debian packages)
Mesa: CVS checkout of the mesa_6_4_branch (few days old)
[4] Time for drawing one glxgears frame at 800x600:
mga: 10.5 - 10.9 ms
r200: 0.24 - 0.35 ms
Btw: On DirectFBGL the mga took only 2.3 ms for a gears frame.
DirectFBGL uses some Mesa-embedded-2-branch derivate by Ville
Syrjälä from July 2004.
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unreliable timing of glXWaitVideoSyncSGI
Hi Ville,
On Sun, 2006-08-27 at 23:39 +0300, Ville Syrjälä wrote:
On Sun, Aug 27, 2006 at 07:36:31PM +0200, Jan Gukelberger wrote:
Hi,
I'm trying to port an application that presents visual stimuli for
experiments in neuroscience from DirectFBGL to X/DRI. A main requirement
is reliable timing of the drawing code, i.e. on every VSYNC a new frame
must be ready in the back buffer so that the buffers can be swapped.
For this purpose I start a graphics thread with SCHED_FIFO scheduler
that does basically this:
while( !Stopped() )
{
glXGetVideoSyncSGI( count1 );
time1 = GetTime( CLOCK_REALTIME );
glXWaitVideoSyncSGI( 2, ( count1 + 1 ) % 2, count2 );
time2 = GetTime( CLOCK_REALTIME );
glXGetVideoSyncSGI( count3 );
if( count3 != prevCount + 1 )
Print( Lost %i frames., count3 - prevCount - 1 );
Print( Draw time: %f ms. Wait time: %f ms.,
time1 - prevTime, time2 - time1 );
prevCount = count3;
prevTime = time2;
glFlush();
glXSwapBuffers( dpy, win );
DrawFrame();
}
Now my problem is: While all the drawing and buffer swapping and
printing works quite deterministic [1] the glXWaitVideoSyncSGI call
seems to hang from time to time, i.e. there are some occurrences where
it takes between 20 and 50 ms to return instead of the normal say 15-16
ms (@60Hz).
The number of these hangs increases drastically from a few lost frames
in 1 frames when there's no load on the system to 1 lost in 5 frames
when there's load on the X server, e.g. by 'tail -f'ing the log file in
an xterm.
I think I saw this same issue on my G400 some time ago. It seems to be
caused by the SOFTRAP interrupt misbehaving. For some reason the
interrupt only works when there's some accelerator activity. My plan was
to see enabling status data writeback (PRIMPTR) would fix it, but I got
sidetracked and forgot the whole issue.
Hmm, is there a way for me (not knowing what all this
SOFTRAP/PRIMPTR/fence stuff is all about) to test this? Is there some
place I can glean by what this interrupt is triggered and what it is
used for?
What would break if I patched mga_irq.c to not enable MGA_SOFTRAP?
Note that I'm observing the same behaviour on radeon, is it possible
that this driver has similar issues?
Thanks for your time,
Jan
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
