Re: [r300] TCL fallback with Quake3
Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: Hi, Quake3 causes fallback because r300_translate_vertex_shader() returns early and doesn't translate the shader. The culprit: if (!mesa_vp-Base.String) return; To me it looks suspect because checking a pointer to the shader string to verify that the parsed shader is valid doesn't make sense to me. And this check i omitted for fragment translation which uses the same structure. Anything obvious I missed? That check is there to check if a shader string was even specified in the first place (see the thread about Radeon 9200 GetProgramiv(GL_VERTEX_PROGRAM_ARB,... at the mesa3d-dev list). Maybe there is some trouble with that, in the case of quake3 and r300 I'd suspect it's because no string exists for the shader at all, because quake3 obviously doesn't use vertex shaders and it's internally generated by fixed function to shader conversion code. That is what I suspected. The way I see it Base.String is always set along side the Base.Instructions pointer. Since the the code actual depends on Base.Instructions it makes more sense to check it. The only problem is I am unable to test if it failes as intended. If you remove the test for mesa_vp-Base.String does Quake3 work? -Brian - 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: [r300] TCL fallback with Quake3
Brian Paul wrote: Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: Hi, Quake3 causes fallback because r300_translate_vertex_shader() returns early and doesn't translate the shader. The culprit: if (!mesa_vp-Base.String) return; To me it looks suspect because checking a pointer to the shader string to verify that the parsed shader is valid doesn't make sense to me. And this check i omitted for fragment translation which uses the same structure. Anything obvious I missed? That check is there to check if a shader string was even specified in the first place (see the thread about Radeon 9200 GetProgramiv(GL_VERTEX_PROGRAM_ARB,... at the mesa3d-dev list). Maybe there is some trouble with that, in the case of quake3 and r300 I'd suspect it's because no string exists for the shader at all, because quake3 obviously doesn't use vertex shaders and it's internally generated by fixed function to shader conversion code. That is what I suspected. The way I see it Base.String is always set along side the Base.Instructions pointer. Since the the code actual depends on Base.Instructions it makes more sense to check it. The only problem is I am unable to test if it failes as intended. If you remove the test for mesa_vp-Base.String does Quake3 work? It does. The Mesa generated shaders doesn't set Base.String making Base.String a bad choice for checking the validity of the Base struct. I am just trying to find a check that is valid in all cases and can be used by r300 r200. Rune Petersen - 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: [r300] TCL fallback with Quake3
Rune Petersen wrote: Brian Paul wrote: Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: Hi, Quake3 causes fallback because r300_translate_vertex_shader() returns early and doesn't translate the shader. The culprit: if (!mesa_vp-Base.String) return; To me it looks suspect because checking a pointer to the shader string to verify that the parsed shader is valid doesn't make sense to me. And this check i omitted for fragment translation which uses the same structure. Anything obvious I missed? That check is there to check if a shader string was even specified in the first place (see the thread about Radeon 9200 GetProgramiv(GL_VERTEX_PROGRAM_ARB,... at the mesa3d-dev list). Maybe there is some trouble with that, in the case of quake3 and r300 I'd suspect it's because no string exists for the shader at all, because quake3 obviously doesn't use vertex shaders and it's internally generated by fixed function to shader conversion code. That is what I suspected. The way I see it Base.String is always set along side the Base.Instructions pointer. Since the the code actual depends on Base.Instructions it makes more sense to check it. The only problem is I am unable to test if it failes as intended. If you remove the test for mesa_vp-Base.String does Quake3 work? It does. The Mesa generated shaders doesn't set Base.String making Base.String a bad choice for checking the validity of the Base struct. I am just trying to find a check that is valid in all cases and can be used by r300 r200. Does replacing the above test with this work? if (mesa_vp-Base.NumInstructions == 0) return GL_FALSE; -Brian - 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
[Bug 8042] The force_s3tc_enable value is ignored by the i915 driver.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8042 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 09:43 --- That's all, thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 8042] The force_s3tc_enable value is ignored by the i915 driver.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8042 [EMAIL PROTECTED] changed: What|Removed |Added Severity|major |normal --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 10:20 --- At a quick glance, it looks to me like the vblank_mode and allow_large_textures option (in both i830 and i915 contexts) would be broken just as well? The i965 driver also looks suspicious, though this one doesn't seem to initialize the context option cache in the first place. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
results of Radeon 9800 Pro test
Hi,I removed fglrx from my system yesterday.I was using it to initialize my Radeon 9800 Pro before (old DRI driver crashed without that).Then I installed new drivers, and I tested following applications: Blender - at least one problem - selection rendering (BKEY), this happens with many drivers (like mga), but it was working correctly last time on r300, step backward?Celestia - OKcube - fallbacks to software rendering Emilia Pinball - OKEnemy Teritorry - OK foobillard - OK (but fallbacks to software if I turn on reflections)galaxymage - OKglest - refuses to start (Exception: Your system supports OpenGL version 1.2 (1.3 Mesa 6.5.1) Glest needs at least version 1.3 to work)globulation2 - OK (it crashed system on old drivers)lincity-ng - OKmplayer - OK (with xv, gl, gl2) Neverball - OK ppracer - OKQuake2 - OK (but dlopen bug requires LD_PRELOAD)sauerbraten - fallbacks to software renderingScorched3D - OK (max details)S.C.O.U.R.G.E. - OKsturmbahnfahrer - OKvamos - works, but many textures are missing (maybe that's an application problem) warzone - OK xmoto - OKI was unable to crash the system at all, however, I haven't tried to run more than two OpenGL contexts yet(because I need to change Xorg.conf for that).I think that it is safe to say that Radeon 9800 Pro works stable and r300 driver is the best OpenGL implementation I ever seen in Linux (much more stable than radeon, r200 or voodoo3, much more correct than mga or i810 and of course much more free than propertiary drivers).I hope that PCI-E cards are working great, too. I will check it within next few weeks. Test System: ATI Radeon 9800PRO NH (AGP) AMD Athlon(tm) XP 1800+768MB RAM Arch Linux xorg-server 1.1.1, xf86-video-ati 6.6.2, libdrm 2.0.2, mesa 6.5.1rc1, kernel26 2.6.17.8PS. Is there any open source application which uses true 3D bump-mapping? Is it working on r300? - 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jan Gukelberger wrote:
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();
}
This is not the right way to do this. You want to use either
GLX_MESA_swap_control, GLX_SGI_swap_control, or GLX_OML_sync_control.
Each of these provides a way for the application to tell the driver the
maximum buffer swap frequency.
GLX_MESA_swap_control is the flavor supported by most of the open source
drivers. To achieve the result you want, you'd call glXSwapIntervalMESA
with a value of 1. For that extension, the default value is 0, which
means the driver should swap as fast as it can.
If you want to get some statistics about the swapping, you can use
GLX_MESA_swap_frame_usage. That will tell you how fast your swaps are
actually happening.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFE8z7QX1gOwKyEAw8RAoy8AJ9y4Rmp/9mzKrMHmJj2IMlKZmRpgQCghCrV
VHzq/ajSHLK/il2DmIok+Aw=
=nqhc
-END PGP SIGNATURE-
-
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: results of Radeon 9800 Pro test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Poplawski wrote: glest - refuses to start (Exception: Your system supports OpenGL version 1.2 (1.3 Mesa 6.5.1) Glest needs at least version 1.3 to work) This implies that glest is getting an indirect rendering context. Could you debug that a bit more? It seems like it should get a direct rendering context. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFE8z9gX1gOwKyEAw8RAlCQAJ9TQlPCfRZL0s50g6PFwr1zpL3V1QCfUdWG xcTCfz4QK1CnVJY067aWRe8= =qCkC -END PGP SIGNATURE- - 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: results of Radeon 9800 Pro test
On 8/28/06, Ian Romanick [EMAIL PROTECTED] wrote: glest - refuses to start (Exception: Your system supports OpenGL version 1.2 (1.3 Mesa 6.5.1) Glest needs at least version 1.3 to work)This implies that glest is getting an indirect rendering context. Yes, sorry, I tried to run it from root :-(It starts when I run it from user.Landscape renders correctly when I am in menu, but when I start game I see just gray screen and few white rectangles (missing textures again?). I think that this application is just not mature enough - there is an error about 3D textures even if I disable it in menu:[EMAIL PROTECTED] glest]$ ./glestMesa: CPU vendor: AuthenticAMDMesa: CPU name: AMD Athlon(tm) XP 1800+ Mesa: MMX cpu detected.Mesa: 3DNow! cpu detected.Mesa: SSE cpu detected.Mesa: Not testing OS support for SSE, leaving enabled.Try R300_SPAN_DISABLE_LOCKING env var if this hangs.*WARN_ONCE* File r300_vertexprog.c function t_dst_index line 184Unknown output 3***Couldn't process event: Error creating texture 3D*WARN_ONCE* File r300_render.c function r300Fallback line 388Software fallback:ctx-RenderMode != GL_RENDER*** - 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: results of Radeon 9800 Pro test
Jacek Poplawski wrote: Hi, I removed fglrx from my system yesterday. I was using it to initialize my Radeon 9800 Pro before (old DRI driver crashed without that). Then I installed new drivers, and I tested following applications: snip I think that it is safe to say that Radeon 9800 Pro works stable and r300 driver is the best OpenGL implementation I ever seen in Linux (much more stable than radeon, r200 or voodoo3, much more correct than mga or i810 and of course much more free than propertiary drivers). I hope that PCI-E cards are working great, too. I will check it within next few weeks. While the r300 driver has, indeed, come a long way, I'm hesitant to call it the best OpenGL implementation I've ever seen. As of July, the r200 driver still out performed the r300 driver at nearly every OpenGL application and game on my system. I do agree with your assessment that the r300 driver is much more stable than most of the other open source drivers, however. Adam - 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: [r300] TCL fallback with Quake3
Rune Petersen wrote: Brian Paul wrote: Rune Petersen wrote: Brian Paul wrote: Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: Hi, Quake3 causes fallback because r300_translate_vertex_shader() returns early and doesn't translate the shader. The culprit: if (!mesa_vp-Base.String) return; To me it looks suspect because checking a pointer to the shader string to verify that the parsed shader is valid doesn't make sense to me. And this check i omitted for fragment translation which uses the same structure. Anything obvious I missed? That check is there to check if a shader string was even specified in the first place (see the thread about Radeon 9200 GetProgramiv(GL_VERTEX_PROGRAM_ARB,... at the mesa3d-dev list). Maybe there is some trouble with that, in the case of quake3 and r300 I'd suspect it's because no string exists for the shader at all, because quake3 obviously doesn't use vertex shaders and it's internally generated by fixed function to shader conversion code. That is what I suspected. The way I see it Base.String is always set along side the Base.Instructions pointer. Since the the code actual depends on Base.Instructions it makes more sense to check it. The only problem is I am unable to test if it failes as intended. If you remove the test for mesa_vp-Base.String does Quake3 work? It does. The Mesa generated shaders doesn't set Base.String making Base.String a bad choice for checking the validity of the Base struct. I am just trying to find a check that is valid in all cases and can be used by r300 r200. Does replacing the above test with this work? if (mesa_vp-Base.NumInstructions == 0) return GL_FALSE; yes (remove GL_FALSE, void function) OK, I checked in this change. The r200 version needs the return value. -Brian - 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: results of Radeon 9800 Pro test
While the r300 driver has, indeed, come a long way, I'm hesitant to callit the best OpenGL implementation I've ever seen.As of July, the r200 driver still out performed the r300 driver at nearly every OpenGLapplication and game on my system.But the problem is that r200 is not stable (at least on my system) which makes it unusable. It's very annoying when you want to play Enemy Territory for few hours or create something in complex Blender, and then see a crashed system. I've noticed that performance drops when software changes OpenGL states too often. I am not sure how it works on other drivers/implementations. - 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: results of Radeon 9800 Pro test
Jacek Poplawski wrote: While the r300 driver has, indeed, come a long way, I'm hesitant to call it the best OpenGL implementation I've ever seen. As of July, the r200 driver still out performed the r300 driver at nearly every OpenGL application and game on my system. But the problem is that r200 is not stable (at least on my system) which makes it unusable. It's very annoying when you want to play Enemy Territory for few hours or create something in complex Blender, and then see a crashed system. I've noticed that performance drops when software changes OpenGL states too often. I am not sure how it works on other drivers/implementations. The only real stability problems I've had with the r200 driver recently is when I have multiple GL contexts running, and one of them goes beyond the 2048x2048 hardware limit (in terms of location, not size). So, for example, when running a mergedfb setup at 2560x2048 and having GL screensavers running on both heads. I have no problems playing doom3 or quake4 for hours on end with the r200 driver and it is significantly faster than with the r300 driver. Having said that, there's such progress being made on the r300 driver that I rarely switch back to my9000Pro unless I really need to for some reason. Adam - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 14:16 --- More testing: I have discovered that running celestia 1.4.1 with XOrg 7.1 (FC6 release-candidate packages), exiting celestia and then running other OpenGL games can cause my computer's GPU to lock up immediately. The other OpenGL game in question is World of Warcraft, running under Wine 0.9.20/CVS in full-screen mode. Running Warcraft in Direct3D mode seems to be OK, as far as the login screen anyway. (I don't have a Warcraft account yet, so can't test any further.) However, Wine implement Direct3D support in terms of libGL and libGLU, so there's obviously something specific in OpenGL support which is killing my machine. I have also discovered that celestia will *not* cause any trouble, provided only the following rendering options are selected: - antialiasing - smooth lines - stars - galaxies - automag Rendering planets(!) *does* cause OpenGL problems later. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 14:31 --- (In reply to comment #15) I have also discovered that celestia will *not* cause any trouble, provided only the following rendering options are selected: - antialiasing - smooth lines - stars - galaxies - automag do problems also happen if you only select the multitexture render path? It could be some weird initialization problem when the last app had vertex programs enabled when exiting. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 15:03 --- (In reply to comment #17) How would I test that? I don't remember any multi-texture render path option in celestia. Do you mean stopping celestia using GL_ARB_vertex_program? ? Options-OpenGL render path (or similar, it's in german here) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 15:06 --- (In reply to comment #18) (In reply to comment #17) How would I test that? I don't remember any multi-texture render path option in celestia. Do you mean stopping celestia using GL_ARB_vertex_program? ? Options-OpenGL render path (or similar, it's in german here) Ah wait or do you have some weird glut version or something? I've no idea about how you'd configure that. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 15:20 --- (In reply to comment #11) Created an attachment (id=6710) -- (https://bugs.freedesktop.org/attachment.cgi?id=6710action=view) [edit] Screenshot from the given URL. cel://Follow/Saturn/2006-08-26T22:42:15.02225?x=ChtazHUPKI1WDAy=gZrSQ8RMk14Cz=ZCyfD/SMJ4ua/wow=0.147406ox=0.882195oy=-0.302936oz=-0.328988select=Saturnfov=20.361984ts=1.00ltd=0rf=317335lm=0 This (and the other URL) works for me just fine. Hmm... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 15:51 --- a) If I disable GL_ARB_vertex_program in the configuration file, then celestia is forced to use GL_NV_vertex_program instead. This means that the multi-texture render path is the best rendering option that I can get. I can then enable planets, ring shadows and eclipse shadows et al, and everything is happy. (I see eclipse shadows, but not ring shadows. My machine doesn't crash later.) b) If I enable GL_ARB_vertex_program then celestia jumps to using the Open GL render path before I can tell it to use the multi-texture one instead, after which the damage is done. c) I am using FC RPM package freeglut-2.4.0-4, which provides libglut.so.3.8.0. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 16:13 --- (In reply to comment #21) a) If I disable GL_ARB_vertex_program in the configuration file, then celestia is forced to use GL_NV_vertex_program instead. This is impossible. This option is gone for good, if it is still there an old r200_dri.so is picked up somewhere. (In fact it would explain at least some of the misrendering, as it indeed partly looks like z-fighting which can be caused by tcl fallbacks, which is exactly what would happen with an old driver (or somewhat newer driver but old drm) and this option). This means that the multi-texture render path is the best rendering option that I can get. I can then enable planets, ring shadows and eclipse shadows et al, and everything is happy. (I see eclipse shadows, but not ring shadows. My machine doesn't crash later.) b) If I enable GL_ARB_vertex_program then celestia jumps to using the Open GL render path before I can tell it to use the multi-texture one instead, after which the damage is done. c) I am using FC RPM package freeglut-2.4.0-4, which provides libglut.so.3.8.0. No, I meant celestia version. Apparently you can compile it for glut only, gtk or kde. And the kde version has the option to select other render paths, I don't know about the other versions. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 16:26 --- I configured celestia 1.4.1 with gnome and cairo support, because I don't have a KDE desktop. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 16:45 --- Hmm, GL_NV_vertex_program is an option in driconf, under Features that are not hardware accelerated. GL_ARB_vertex_program used to be here too, until it was implemented in hardware in XOrg 7.1. I used to enable both... Should I turn GL_NV_vertex_program off and let celestia use GL_ARB_vertex_program, then? I don't know where GL_NV_vertex_program is coming from, but *someone* is putting it in my glxinfo. (See comment #3). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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: drm addmap broken on 32bit archs
Stephane Marchesin wrote: Hello, The drm addmap code got broken with the recent switch to the hash table implementation. Specifically, when two maps have the same adress on 32 bits, they end up with the same key and nothing is done to resolve the collision, which results in a failind addmap. This is annoying. nm, Dave and Michel both told me that this was fixed already. Stephane - 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: results of Radeon 9800 Pro test
On Mon, 2006-08-28 at 21:01 +0200, Jacek Poplawski wrote: Quake2 - OK (but dlopen bug requires LD_PRELOAD) I should have fixed this two weeks ago, isn't that working for you? Maybe you're hitting 'new driver needs new libGL' due to Ian's dispatch changes? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 16:59 --- OK, good news and bad news: The good news is that disabling GL_NV_vertex_program and enabling GL_ARB_vertex_program fixes the rendering artifacts in celestia. I now see correct ring shadows and eclipse shadows. The bad news is that afterwards, my OpenGL Warcraft session still crashes. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 8009] OpenGL VertexProgramARB producing incorrect results with celestia 1.4.1
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8009 --- Additional Comments From [EMAIL PROTECTED] 2006-08-28 18:06 --- (In reply to comment #25) OK, good news and bad news: The good news is that disabling GL_NV_vertex_program and enabling GL_ARB_vertex_program fixes the rendering artifacts in celestia. I now see correct ring shadows and eclipse shadows. Ok, so the bad rendering was somehow caused by the software vertex shader (maybe because of the fallback itself). I'm not sure why celestia would prefer NV_vp if ARB_vp is available, seems kinda backwards to me. I don't think you actually ever want to enable (software) NV_vp. The bad news is that afterwards, my OpenGL Warcraft session still crashes. Unfortunately I don't have WoW, but I'll try to reproduce it with other apps. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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: results of Radeon 9800 Pro test
On Mon, 28 Aug 2006 21:21:59 +0200 Jacek Poplawski [EMAIL PROTECTED] wrote: On 8/28/06, Ian Romanick [EMAIL PROTECTED] wrote: glest - refuses to start (Exception: Your system supports OpenGL version 1.2 (1.3 Mesa 6.5.1) Glest needs at least version 1.3 to work) This implies that glest is getting an indirect rendering context. Yes, sorry, I tried to run it from root :-( It starts when I run it from user. Landscape renders correctly when I am in menu, but when I start game I see just gray screen and few white rectangles (missing textures again?). I think that this application is just not mature enough - there is an error about 3D textures even if I disable it in menu: [EMAIL PROTECTED] glest]$ ./glest Mesa: CPU vendor: AuthenticAMD Mesa: CPU name: AMD Athlon(tm) XP 1800+ Mesa: MMX cpu detected. Mesa: 3DNow! cpu detected. Mesa: SSE cpu detected. Mesa: Not testing OS support for SSE, leaving enabled. Try R300_SPAN_DISABLE_LOCKING env var if this hangs. *WARN_ONCE* File r300_vertexprog.c function t_dst_index line 184 Unknown output 3 *** Couldn't process event: Error creating texture 3D *WARN_ONCE* File r300_render.c function r300Fallback line 388 Software fallback:ctx-RenderMode != GL_RENDER *** This doesn't even work with full raster fallbacks in r300. With my Ati Radeon 7000 (Freedesktop-DRI-Drivers) I just saw a grey area ingame, until I deactivated shadows and 3D-textures in the options. -- http://www.glest.org/board2/viewtopic.php?t=1162sid=9d6b42d8f9429e5e6b259b63e13f9816 -- Aapo Tahkola - 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
