Re: Recent CVS commit broke some apps (GLX)
On Thu, Oct 12, 2006 at 07:47:40AM -0600, Brian Paul wrote: Elie Morisse wrote: Hi, About a week ago you(?) seems to have broken some apps such as wine and ut2004 ( no problem with glxgears, blender, googleearth.. ). wine doesn't work at all, ut2004 doesn't restore resolution at exit, and both output something like this : X Error of failed request: GLXBadContextTag Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 25 Current serial number in output stream: 25 I have a Radeon 9250 and till-arched Xorg 7.1 from Gentoo, and LIBGL_ALWAYS_INDIRECT=1 makes them work. I'm not all sure, but i think the rest of my system is ok, so Mesa is likely guilty BTW current CVS cannot compile :../../../src/mesa/glapi/glapi.c: In function ‘get_static_proc_address’:../../../src/mesa/glapi/glapi.c:436: erreur: expected ‘:’ before ‘;’ token Are you sure you have the latest Mesa code? Line 436 of glapi.c is a #else line. The last-but-one wine release broke OpenGL / directx apps for me entirely on Debian unstable. Which wine release are you using? (0.9.20 didn't work at all for me, a set of home-built wine packages from the 0.9.22 sources work fine.) (Radeon 9200SE fwiw.) I haven't tried with the bleeding edge Mesa though, will give it a whirl if I have time. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt - 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: What can the FSF do to help?
On Tue, Sep 12, 2006 at 10:16:35AM +0200, Michel Dänzer wrote: On Tue, 2006-09-12 at 07:58 +0100, Philip Armstrong wrote: On Tue, Sep 12, 2006 at 03:55:40AM +0200, Hanno Böck wrote: Am Montag, 11. September 2006 22:09 schrieb John Sullivan: The Free Software Foundation had listed http://r300.sf.net/ as a High Priority Project. I think nouveau (nouveau.freedesktop.org) should gain the same priority. It's trying to do the things the r300-project successfuly did for many cards on the nvidia-side. Likewise for the newer ATI chips with no 2D engine. No such thing yet. X1xxx still have the same old 2D accelerator, 'just' the display engine is completely new. Ah: I was under the impression that they'd done away with the 2D engine altogether were using a single hardware interface to do both 2D and 3D and that this was the reason for their reticence in revealing the details of the acceleration interface (since it reveals details of the 3D interface which history demonstrates that they don't want to open up). Happy to be corrected! Am I right that at the moment these have no X11 support whatsoever? The only options at this time are ATI's proprietary driver or a generic one such as vesa. Time for an r500 project then I guess. cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt - 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: What can the FSF do to help?
On Tue, Sep 12, 2006 at 03:55:40AM +0200, Hanno Böck wrote: Am Montag, 11. September 2006 22:09 schrieb John Sullivan: The Free Software Foundation had listed http://r300.sf.net/ as a High Priority Project. I think nouveau (nouveau.freedesktop.org) should gain the same priority. It's trying to do the things the r300-project successfuly did for many cards on the nvidia-side. Likewise for the newer ATI chips with no 2D engine. Am I right that at the moment these have no X11 support whatsoever? Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt signature.asc Description: Digital 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: driver level sub-pixel rendering?
On Fri, Mar 31, 2006 at 01:51:03PM -0500, [EMAIL PROTECTED] wrote:
I think some of the cards use the GPUs for scaling video (and perhaps
other optimizations). Kind of like the nice upscaling done by some DVD
players.? Nvidia calls it PureVideo:
[1]http://www.nvidia.com/page/purevideo.html
And the high-precision subpixel processing enables videos to be scaled to
any size, so that even small videos look like they were recorded in
high-resolution.
I'm sure ATI has something similar? I would guess that this kind of thing
could also be used for other things sent to it?
On Mar 31, 2006, at 11:33 AM, Brian Paul wrote:
John Kheit wrote:
Sorry Brian, I should have been more specific.? I mean more as a final
output onto a screen.? Using an LCD/CRT's individual RGB subpixels to
antialiasing (or some form of screen output enhancement). It seems a
lot of the 3D stuff in the GPU is already employing sub-pixel
coordinates, so it would be nice if the actual output to the screen
would take advantage of that.
AFAIK, nobody's hardware does that.
When that kind of antialiasing is done for text, I think it's the job of
the font rendering code to do so.
Is the original author talking about Cleartype-style antialiasing? (ie
using the RGB subpixels to get more {usually horizontal} resolution in
text rendering).
Sounds like something you could do with a pixel shader perhaps.
Straight alpha-blending with the RENDER extension is already
accelerated on most hardware supported by DRI isn't it?
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Debian the dri-devel snapshots
The DRI snapshots can be used with the Xorg packages in Debian experimental. I've edited the wiki to reflect this. Hope that's OK! I've got the r200 snapshot working happily[1]. cheers, Phil [1] PageFlip seems broken however -- rendering errors with Quake4[2] at least, which go away when PageFlip is turned off. [2] No, Quake4 is not playable with an r200 :) -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 TEST RESULTS;
On Thu, Aug 25, 2005 at 01:36:41AM -0500, Alan Grimes wrote: PPRACER: Works but has nasty texture bug affecting the ground textures.. (Problem disappears when I run it on the other, unaccelerated monitor..) Is this just the usual R2x0 GL_SPHERE_MAP texture ordering problem? Does it go away if you turn off hardware TL with driconf? Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 TEST RESULTS;
On Thu, Aug 25, 2005 at 12:35:56PM +0100, Philip Armstrong wrote: On Thu, Aug 25, 2005 at 01:36:41AM -0500, Alan Grimes wrote: PPRACER: Works but has nasty texture bug affecting the ground textures.. (Problem disappears when I run it on the other, unaccelerated monitor..) Is this just the usual R2x0 GL_SPHERE_MAP texture ordering problem? Does it go away if you turn off hardware TL with driconf? Alan has confirmed (using my .drirc -- driconf doesn't work for him for some reason) that the ppracer bug is indeed caused by the GP_SPHERE_MAP TCL fallback. That didn't solve the other problem he was seeing however. cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fwd: radeon YCbCr output
On Sun, Aug 07, 2005 at 07:30:48PM +0100, Steven Newbury wrote: The picture quality is incomparable to s-video and the Windows driver only supports US HDTV standard output modes, while my TV also supports PAL type HDTV modes ie. 576p; hopefully this limitation will be gone if I can get this working with Xorg. Would that be 'incomparable' as in 'better' or 'worse'? :) Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fwd: radeon YCbCr output
On Sun, Aug 07, 2005 at 07:30:48PM +0100, Steven Newbury wrote: The picture quality is incomparable to s-video and the Windows driver only supports US HDTV standard output modes, while my TV also supports PAL type HDTV modes ie. 576p; hopefully this limitation will be gone if I can get this working with Xorg. Would that be 'incomparable' as in 'better' or 'worse'? :) Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] the_perfect_frag snapshot
On Mon, May 23, 2005 at 01:37:10PM +0200, Dario Laera wrote: I'm doing some test with this driver, and I read on the website that Radeon 9600 (including Radeon Mobility M10) - works well, no lockups... well, not for me :P Exactly, I can play almost every 3d game avaible for linux/PPC, but I get lockups when not in full screen mode. In window mode moving the mouse is a risk, from glxgears to neverball. I remember this problem was discussed some time ago on this list, but don't seems fixed for me. Thought I'd give this code a whirl on the Albook. (Radeon Mobility M10) After the initial install, I saw exactly the above -- immediate lockup a second or so after starting glxgears. However, after a reboot, it's been perfectly stable ever since, both in windowed and full screen mode, with every 3D app I've been able to try. Which isn't many unfortunately, since the unstable Ubuntu release I've got on there is in the middle of a C++ ABI transition none of the packages that depend on libglu1 will install at the moment. So far I've only managed to try glxgears, the rss-glx screensavers and neverball, but all seem to be entirely stable. Only slight problem is that the current Xorg CVS seems prone to crashing via double frees on VT switch, but that's unlikely not the dri code's fault I guess. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon m7 hang with gears...hopefully fixed..
Resurrecting an old thread: On Mon, Jan 24, 2005 at 06:56:22PM +, Alan Swanson wrote: Previously, Alan Swanson wrote: This might affect/cure R100's as well. I was recently trying to help someone with lockups on their Radeon 7200 when using Mesa CVS but without success. Testing with my old Radeon DDR also caused lockups. I'll give this a whirl tomorrow and report back. Aye, its fixed the lockups on original Radeons. Glad I don't play NWN on it though because the problematic swtcl for GL_SPHERE_MAP causes horrible character flickering and there is no patch as for R200. Is this the same problem that causes texture flickering in tuxracer? (With environment mapped ice on). Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS head: glxgears on r200 with tcl broken
On Thu, May 19, 2005 at 03:21:38PM +0200, khaqq wrote: On Thu, 19 May 2005 12:13:17 +0100 (IST) Dave Airlie [EMAIL PROTECTED] wrote: I've become skeptical that the r200 was ever truly stable... it may be less stable now .. I'm getting crsahes on my 9200 with multi-app also.. and I've gotten a lot of reports of them... I've installed a debian-testing (sarge) the other day and what they have seems stable, yet awfully old (xfree 4.3.0 + 2.4.x (don't remember)). 3D works for hours (original UT, Quake3) without lockups, whereas newer snapshots for xorg (gentoo / linux 2.6.8.11 / xorg 6.8.2) crash in less than a minute (and sometimes in seconds) on the same PC. Q3A seems to take longer to crash than UT, but that's a subjective feeling I have, no real data. Tested with a Radeon 9100/128MB (i815ep, Celeron 1300, 512MB SDRAM). fwiw, I've found the dri snapshot at nixnuts.net to be absolutely stable with my 9200SE (rv280 chipset). I don't think I've had any crashes at all. Mostly it gets used for a spot of Q3A or UT -- UT2003 is unbearably slow (for reasons outlined on this list sometime IIRC) and UT2004 has severe rendering errors, so it isn't all perfect. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS head: glxgears on r200 with tcl broken
On Thu, May 19, 2005 at 10:57:52PM +0100, Dave Airlie wrote: Phil wrote: fwiw, I've found the dri snapshot at nixnuts.net to be absolutely stable with my 9200SE (rv280 chipset). I don't think I've had any crashes at all. Mostly it gets used for a spot of Q3A or UT -- UT2003 is unbearably slow (for reasons outlined on this list sometime IIRC) and UT2004 has severe rendering errors, so it isn't all perfect. my 9200 with X.org/Mesa CVS from not so long ago, is stablish, i.e. I can play quake3 ut2003 for a good while, my problems only seem to start when I do something like glxgears/a couple of rss screensavers in windows and gtk-demo... single fullscreen apps to me seem sound... Hmm, well I haven't pushed the 'multiple GL apps running at once' side of things I must admit. Oh, and NWN doesn't get on with environment maps either. Otherwise it seems to run quite well... Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 face textures
On Thu, Feb 24, 2005 at 07:25:15PM +0100, Marcello Maggioni wrote: I was wondering what's up with the face textures in Doom3 with R200 hardware . These are as divided in two parts by a black shadow in the middle. There's a way to solve this? Apparently the ARB rendering path on windows is exactly the same. DoomIII can't use the R200 rendering path as dri doesn't have ATI_fragment_program (?) yet. I believe there's half an implementation in existence atm... Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- 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: [R300 and other radeons] MergedFB lockups
On Sun, Feb 20, 2005 at 12:00:10PM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote:
Well my rv250 lockups occour only during mouse movement in fullscreen
applications. But for month ago there were no lockups. The situation
was slowly getting worse since. With current DRM and Mesa driver I
get an immediate lockup in gl-117 when moving the mouse. If I use
current DRM with an older Mesa it locks up after about a minute of mouse
movement.
rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel
(well, actually, all of the above are about 5 days old, doesn't have
Vladimir latest fixes), I get very jerky display with g117 and broken
textures, ultimately it locks up after moving the mouse a little bit (at
the meny screen).
I can kill X tho, that works, so the chip/bus isn't totally dead (or it
recovers with an engine reset).
Fwiw, gl-117 locks up almost immediately (goes fullscreen, puts
Please wait {or something like that} up, then hangs) for me on my
rv280 (Radeon 9200SE).
This is with the nixnuts Debian dri packages, so dri CVS from
2005-02-08 or so.
cheers,
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
---
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: [R300 and other radeons] MergedFB lockups
On Sun, Feb 20, 2005 at 12:00:10PM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote:
Well my rv250 lockups occour only during mouse movement in fullscreen
applications. But for month ago there were no lockups. The situation
was slowly getting worse since. With current DRM and Mesa driver I
get an immediate lockup in gl-117 when moving the mouse. If I use
current DRM with an older Mesa it locks up after about a minute of mouse
movement.
rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel
(well, actually, all of the above are about 5 days old, doesn't have
Vladimir latest fixes), I get very jerky display with g117 and broken
textures, ultimately it locks up after moving the mouse a little bit (at
the meny screen).
I can kill X tho, that works, so the chip/bus isn't totally dead (or it
recovers with an engine reset).
Fwiw, gl-117 locks up almost immediately (goes fullscreen, puts
Please wait {or something like that} up, then hangs) for me on my
rv280 (Radeon 9200SE).
This is with the nixnuts Debian dri packages, so dri CVS from
2005-02-08 or so.
cheers,
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
---
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: [r200] Mesa CVS text and texture bug
On Mon, Feb 14, 2005 at 07:40:20PM +0100, Roland Scheidegger wrote: Dieter Nützel wrote: Back to Linux's 'normal' one solve it. This is interesting, though. The use of a different scheduler should probably not have such a huge impact on performance (if no other cpu or io-heavy processes are running). Are you using pageflip? If no the r200CopyBuffer calls sched_yield() which potentially could cause such a difference. But if you're using pageflip I'm not sure why there would be such a drastic difference. Isn't sched_yield() a really bad idea under 2.6 kernels if you actually wan't a lot of CPU time overall? It puts the process on the back of the expired queue, which means IIRC that it won't get another timeslice until every process in the active queue has expired. cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- 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: ARB_vertex_program and r200...
On Sat, Jan 29, 2005 at 01:47:22AM +, Dave Airlie wrote: I've noticed fglrx advertises this for the r200, and doom 3 wants it... So after I manage to beat fragment_shader into shape, going to have a look at how to get ARB_vp working.. r300 guys you have something going on this already? Well, last Friday, Vladimir said: * BIG TODO: write pixel and vertex shader generator code. This code would need to create vertex and pixel shaders based on the current state of GL context. There's headers for the pixel and vertex shaders in the r300_demo CVS, but they don't seem to be referenced by r300_demo. Vladimir? Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New Debian packages built from Xorg
On Wed, Jan 05, 2005 at 11:46:01PM +0100, Roland Scheidegger wrote: Philip Armstrong wrote: On Wed, Jan 05, 2005 at 10:04:50PM +0100, Roland Scheidegger wrote: Philip Armstrong wrote: (Well, apart from the fact that UT2003 is completely borked that is. But that's been the case for a while with the DRI builds. Foliage and enemies are rendered but the landscape simply isn't there. It looks like you can see the skybox in all directions actually, but it might be a different texture. It looks the same regardless of whether hardware TCL is turned on or not.) I'm not seeing this, but it sounds like it could be related to texgen changes some months ago. It's been like that for a while. Certainly since last Nov IIRC. That would coincide well with the texgen/tex coord submission changes. UT2004 also has a problem with the menus where they have a pure white background instead of the expected image. The game seems to run OK however (although not particularly speedily on my hardware). Don't have issues with the menus. I think I've heard of that problem some time ago though, iirc it was related to s3tc (not sure though). If so it might be fixed in a newer version. I'm using the latest version of both UT2003 and UT2004 demos. The demo binary may lag the commercial release of course. In enclosed spaces I can sometimes see correct rendering in UT2003, but usually I just get the skybox. Some kind of Z buffer problem? Oh, and DOOM III segfaults on startup. Sounds like the doom3 not loading libGL correctly to me. Fixed in newer versions, or try LD_PRELOAD=/usr/lib/libGL.so when starting doom3 (note though the old version also has some problem with detecting s3tc extension, so if you don't have the external library installed it might not work at all). Yup. I grabbed the latest version it now just segfaults on exit :) (Oh, and I get the 'everything is black' problem as reported previously on dri-devel. But I wasn't expecting it to actually work perfectly.) cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New Debian packages built from Xorg
On Wed, Jan 05, 2005 at 07:50:50AM -0600, John Lightsey wrote: I was feeling a bit frisky yesterday and built new DRI packages for Debian Unstable using the Xorg xc tree. Any feedback would be greatly appreciated. http://www.nixnuts.net/files/experimental/ Works for me! (Well, apart from the fact that UT2003 is completely borked that is. But that's been the case for a while with the DRI builds. Foliage and enemies are rendered but the landscape simply isn't there. It looks like you can see the skybox in all directions actually, but it might be a different texture. It looks the same regardless of whether hardware TCL is turned on or not.) Nice FPS boost (Radeon 9200SE) with HyperZ turned on in Quake3 -- makes it reasonably playable in 1280x1024. cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt signature.asc Description: Digital signature
Re: New Debian packages built from Xorg
On Wed, Jan 05, 2005 at 10:04:50PM +0100, Roland Scheidegger wrote: Philip Armstrong wrote: (Well, apart from the fact that UT2003 is completely borked that is. But that's been the case for a while with the DRI builds. Foliage and enemies are rendered but the landscape simply isn't there. It looks like you can see the skybox in all directions actually, but it might be a different texture. It looks the same regardless of whether hardware TCL is turned on or not.) I'm not seeing this, but it sounds like it could be related to texgen changes some months ago. It's been like that for a while. Certainly since last Nov IIRC. UT2004 also has a problem with the menus where they have a pure white background instead of the expected image. The game seems to run OK however (although not particularly speedily on my hardware). Oh, and DOOM III segfaults on startup. Nice FPS boost (Radeon 9200SE) with HyperZ turned on in Quake3 -- makes it reasonably playable in 1280x1024. Should get even better with color tiling soon enough :-). :) Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Accessing AGP
On Tue, Dec 28, 2004 at 09:10:12AM +0100, Thomas Hellström wrote: Vladimir Dergachev wrote: Can someone more knowledgable explain to me how to properly access AGP space from within Mesa driver ? This has just been implemented in the Unichrome driver, and I'm not sure wether it's the best or most appopriate way to do it but it works as follows: 1. The Mesa driver fills a malloced system memory buffer with vertex data. 2. The Mesa driver then calls the DRM through a via-specific IOCTL. (via_ioctl.c) 3. The via drm copies the buffer to another buffer in kernel system memory ( static storage ), (via_dma.c) 4. The via drm verifies the content of the buffer to reject buffers that contain commands that are considered harmful. (via_verifier.c) 5. The buffer is copied to AGP space, and the engine pointers are updated. (via_dma.c) The reason for 3. is that running the verifier directly on AGP memory is very slow. Is there some reason you can't run the verifier on the user-space buffers? Copying the data twice seems terribly wasteful. Enlightenment requested :) Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: HyperZ for IGP320M
On Thu, Nov 25, 2004 at 03:53:17PM +0100, Stephane Marchesin wrote: Btw, we're looking for people that could do some hacking on r200 now, since we don't have access to these cards. I can do r200 (well, rv280). How much hackery is involved? Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon M10 status?
On Mon, Sep 13, 2004 at 10:33:26PM +0200, Fionn Behrens wrote: What is the status on the M10 line of ATI GPUs (Mobility FireGL [T2]) so far? I am a happy new owner of a Notebook with this chip but the only way to enable DRI with this so far was the dreaded fglrx driver. Is trying CVS worth a shot for me or isnt anything here yet for this GPU? The Mobility M10 is an rv350 IIRC. Not supported at all by DRI as yet. Some development is ongoing -- see Vladimir's post a day or two ago. I'll be having a hack at Vladimir's stuff when I get a chance later this week have all the code bits in place. cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI DDX to xorg merge
On Thu, Aug 19, 2004 at 09:13:44AM -0400, Robert S. Kerr wrote: If that turns out to be right, my next adventure is to figure out how to debug a running driver. Pointing gdb at my rotyuv process doesn't let me look down into the XvShmPutImage method. Suggestions are welcome. Debian at least ships debug versions of the X libraries. Specifically, the libxv1-dbg package might be useful. Install the package, and set LD_LIBRARY_PATH=/usr/X11R6/lib/debug. Hopefully that will let you dig into XvShmPutImage(). Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: G400 on AMD64 does not work
On Tue, Jul 27, 2004 at 03:39:19PM +0200, Kenan Esau wrote: I am sorry if I am asking FAQs. But I just want to know if someone is working on this and if I can help debugging this problem. If you think there is no problem this would be also interesting for me. G400MAX works fine for me: 2.6.7 kernel (2.4.26 was fine as well IIRC) 1GHz Duron SiS745 motherboard. Both Xfree debs from Debian unstable, and Michel Daenzer's debs from http://people.debian.org/~daenzer/ (DRI source from Feb 2004 IIRC) work for me. It does crash on console switch occasionally, which is irritating. But OpenGL apps are fine. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Tester available for R300 driver
On Thu, May 13, 2004 at 06:16:42PM +1000, Daniel Kasak wrote: Yes I know there is currently nothing that works. When that changes, I will gladly test whatever anyone has. I bought myself a Radeon 9600 SE, thinking it had an R270 chip, but it in fact has an R350 chip. And yes I know I should have checked. It was dirt cheap. The ATI drivers are surprisingly slow. They only run UT2004 15% faster than the DRI drivers on my Radeon 7200! ( and I have an Athlon 2100XP ). ISTR that the SE cards have much less GPU-memory bandwidth than the normal cards. This is really going to compromise the performance of games with lots of big textures. The GPU is clocked at a slower rate as well. So bring on the R300 developers :) Vladimir, I salute you! :) Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texture flickering (r200 driver) ut2k3 demo
On Fri, Jun 13, 2003 at 02:46:29AM +0200, Roland Scheidegger wrote: I've just noticed there is some flickering going on with the ut2k3 demo. It's not always very visible, but for instance if I run the botmatch-anubis.sh benchmark it's very noticeable - the bots heavily blink in all colors. (This could be related to the same bug as the one seen in nwn, as decreasing the cmd_buf size fixes the problem for me just as well, though I still have no idea why). Using CVS DRI (yesterday), Radeon 9000pro, Athlon XP, KT133A. Someone else seen this? Disabling TCL also gets rid of the problem. Fwiw I see these symptoms too on a radeon mobile equipped laptop running UT200x -- but only if the original X desktop size is the full 1600x1200 (running UT at 800x600). If I start X at 800x600 and then start UT, I get no texture flickering at all -- the textures are entirely stable. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] texture flickering (r200 driver) ut2k3 demo
On Fri, Jun 13, 2003 at 10:12:14AM -0700, Linus Torvalds wrote: On Fri, 13 Jun 2003, Philip Armstrong wrote: Fwiw I see these symptoms too on a radeon mobile equipped laptop running UT200x -- but only if the original X desktop size is the full 1600x1200 (running UT at 800x600). If I start X at 800x600 and then start UT, I get no texture flickering at all -- the textures are entirely stable. I'm flogging dead horse, the 1600x1200 desktop will obviously allocate a lot more card memory, and leave less memory available for textures. And with less memory for textures, you need to swap them from main memory more often. [snip] Yes, you're entirely correct, I'd forgotten you'd mentioned exactly this problem only a few days ago. Consider me a duplicate bug report then :) Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC (again)
On Fri, Feb 21, 2003 at 03:27:21PM -0800, Ian Romanick wrote: Look at the ARB_texture_compression and EXT_texture_compression_s3tc specs again. You can specify uncompressed textures and have the driver compress the AND you can specify compressed textures and have the driver decompress them (to read them back into the application). For example, Quake3 can use the S3's vendor-specific extension (can't remember the name of it right now), but it does NOT have ANY textures pre-compressed. It expects the driver to do the work. If the hardware can't do S3TC, then the driver can simply not advertise the availability of the extension, and if the application expects the driver to compress the textures, then the driver can either refuse or just pass the textures on uncompressed. Clearly the driver can't implement the full API, but is there a legal barrier to implementing the part that says here, take these pre- compressed textures and give them to the hardware ? Can we add this to the FAQ, please? The FAQ is editable by anyone isn't it? Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] UT2003 crash with current trunk
On Thu, Feb 20, 2003 at 09:05:27PM -0500, Daniel Vogel wrote: There is no way in hell UT2k3 will run on MGA. It *REQUIRES* ARB_texture_env_combine, which is not supported by that hardware. Even if it didn't require that extension, good grief man, why torture yourself like that?!? :) FWIW, the Windows version of UT2003 even runs (badly) on Intel 810 and Voodoo Banshee cards :) A G400 actually performs better than a TNT2 due to the increased fillrate. (all D3D) I've got a G400 MAX as well -- it does pretty well all things considered when paired with a beefy enough processor to compensate for the lack of TL. Twas briefly the fastest GPU around ISTR, til Nvidia stole the crown with the GeForce... Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] S3TC (again)
OK, I don't exactly want to stir up this hornets nest *again*, but a couple of things aren't entirely clear to me and I'd appreciate any clarifications. As I understand it, the situation is as follows: The S3TC algorithm is patented and therefore no-one can distribute an implementation of the algorithm without a licence from the patent holders. S3TC decompression must be implemented in the hardware (otherwise what's the point), therefore hardware which uses S3TC can be assumed to have a valid licence to use the code, otherwise the patent owners would be down on the hardware manufacturers like the proverbial ton of bricks. As far as I'm aware, the main users of S3TC are modern games with their vast arrays of textures -- presumably such games come with the textures precompressed, or are able to compress them and cache the compressed textures themselves. Presumably again, the authors of the games have paid for a licence to use the S3TC algorithm from the patent holders. Now, if an OpenGL application has a pile of textures already compressed with the S3TC algorithm, then I don't understand why the dri drivers can't simply offer the S3TC interfaces to the hardware, pass the compressed textures to the hardware and let the hardware get on with its licensed decompression of the textures as required. Likewise, if the OpenGL application passes compressed textures to the S3TC API then how it gets hold of the compressed textures in the first place is it's own responsibility -- the OpenGL API just passes them on. This line of reasoning suggests that no software fallback can be provided for S3TC in the Xfree DRI, since such a fallback would require decompressing the textures which would require a patent licence which the DRI doesn't have. However, there should be no barriers to implementing the API in the case where the textures are simply passed from an application to the hardware. Is the reason that this hasn't been done because there a fault in my reasoning (obviously IANAL), or are the DRI developers are just leery of going anywhere near the whole tarball of pain (not being lawyers either) and are happier coding things which don't have patents looming around them? Presumably there's also the issue of hardware documentation to implement the API on top of the hardware -- I'm assuming that this is available obviously. cheers all, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] UT2003 crash with current trunk
This is pretty much a followup to Adam Kirchhoff's bug report. Adam reported that UT2003 patch level 2186 failed with the latest dri trunk on his Radeon 8500 and gave the traceback reported by UT2003. I've noticed that more information is contained within ~/.ut2003/System/UT2003.log Using the debs at http://people.debian.org/~daenzer/dri-trunk-sid/ on Debian unstable and the latest demo release of UT2003 (v2206 -- which is purported to not need S3TC extensions), I get the following traceback reported by UT2003: phil@trigger /scratch/phil/ut2k3/demo ./ut2003_demo Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. Backtrace: [ 1] ./Core.so [0x40a0478a] [ 2] /lib/libpthread.so.0 [0x40d8775a] [ 3] /lib/libc.so.6 [0x40bb39d8] [ 4] /usr/X11R6/lib/modules-dri-trunk/dri/mga_dri.so [0x43f55bb9] [ 5] /usr/X11R6/lib/modules-dri-trunk/dri/mga_dri.so [0x43f3e4f1] [ 6] /usr/X11R6/lib/modules-dri-trunk/dri/mga_dri.so [0x43f31fb7] [ 7] /scratch/phil/ut2k3/demo/System/OpenGLDrv.so(DrawPrimitive__22FOpenGLRenderInterface14EPrimitiveType+0x373) [0x430b0aeb] [ 8] ./Engine.so(DrawSection__FP11UStaticMeshiP9UMaterialP16FRenderInterface+0x6f) [0x403739d3] [ 9] ./Engine.so(RenderStaticMesh__FP13FDynamicActorP15FLevelSceneNodePt5TList1ZP13FDynamicLightPt5TList1ZP20FProjectorRenderInfoP16FRenderInterface+0x1ea2) [0x40375fd2] [10] ./Engine.so(Render__13FDynamicActorP15FLevelSceneNodePt5TList1ZP13FDynamicLightPt5TList1ZP20FProjectorRenderInfoP16FRenderInterface+0x3a9) [0x40340d4d] [11] ./Engine.so [0x40360c81] [12] ./Engine.so(RenderLevel__FP15FLevelSceneNodeP16FRenderInterface+0x22be) [0x40365f02] [13] ./Engine.so(Render__15FLevelSceneNodeP16FRenderInterface+0x7a2) [0x4034838a] [14] ./Engine.so(Render__16FPlayerSceneNodeP16FRenderInterface+0x330) [0x4034d4ec] [15] ./Engine.so(Draw__11UGameEngineP9UViewportiPUcPi+0x848) [0x402854d4] [16] /scratch/phil/ut2k3/demo/System/SDLDrv.so(Repaint__12USDLViewporti+0x33) [0x4307193b] [17] /scratch/phil/ut2k3/demo/System/SDLDrv.so(Tick__10USDLClient+0x85) [0x43070365] [18] ./Engine.so(Tick__11UGameEnginef+0x31bd) [0x4028c2e1] [19] ./ut2003-bin(SDL_SetVideoMode+0x969) [0x8051b1d] [20] ./ut2003-bin(main+0x328c) [0x8058b2c] [21] /lib/libc.so.6(__libc_start_main+0xdd) [0x40ba2a51] [22] ./ut2003-bin(GetFullName__C7UObjectPw+0x7d) [0x80512d1] Signal: SIGSEGV [segmentation fault] Aborting. In ~/.ut2003/System/UT2003.log is the following: [snip] Init: Input system initialized for SDLViewport Log: Enter SetRes: 800x600 Fullscreen 1 Log: OpenGL Init: GL_VENDOR : VA Linux Systems Inc. Init: GL_RENDERER : Mesa DRI G400 20021125 AGP 4x x86/MMX/3DNow!/SSE Init: GL_VERSION: 1.2 Mesa 5.0 Init: Device supports: GL Init: Device supports: GL_EXT_bgra Init: Device supports: GL_ARB_texture_compression Init: Device supports: GL_ARB_multitexture Init: C32 RGB888 Z24 S8 Init: WARNING: OpenGL renderer relies on DXTC/S3TC support for good performance. Init: WARNING: no support for combine3/4 extensions - not all blend modes supported Init: Game engine initialized Log: Startup time: 3.831979 seconds Log: Precaching: NvidiaLogo.LevelInfo0 Log: Allocating 32768 byte dynamic index buffer. Log: Allocating 65536 byte dynamic vertex buffer. Log: OpenGL Error: GL_INVALID_ENUM (UOpenGLRenderDevice::Unlock) Log: Finished precaching geometry in 0.105 seconds Exit: Exiting. Log: Waiting for file streaming thread to finish... Uninitialized: Name subsystem shut down Uninitialized: Allocation checking disabled Uninitialized: Log file closed, Thu Feb 20 20:31:18 2003 So it looks like the segfault is caused by the GL_INVALID_ENUM error. Could this be down to ut2003 being compiled against an earlier libGL? By comparison, the Return to Castle Wolfenstein demo works fine. I'll try twiddling some of the settings in the ut ini file to see if it makes any difference... Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] UT2003 crash with current trunk
On Thu, Feb 20, 2003 at 02:25:16PM -0800, Philip Brown wrote: On Thu, Feb 20, 2003 at 09:12:04PM +, Philip Armstrong wrote: Using the debs at http://people.debian.org/~daenzer/dri-trunk-sid/ on Debian unstable and the latest demo release of UT2003 (v2206 -- which is purported to not need S3TC extensions), I get the following traceback reported by UT2003: phil@trigger /scratch/phil/ut2k3/demo ./ut2003_demo Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. ??? This looks like you are using Xig libGL.so library. Deinstall Xig libs before doing tests like this. No, it's just UT2003 looking for that X server extension and not finding it. I don't have any Xig libraries whatsoever. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] UT2003 crash with current trunk
On Thu, Feb 20, 2003 at 05:53:25PM -0500, Leif Delgass wrote: On Thu, 20 Feb 2003, Leif Delgass wrote: On Thu, 20 Feb 2003, Philip Brown wrote: On Thu, Feb 20, 2003 at 09:12:04PM +, Philip Armstrong wrote: Using the debs at http://people.debian.org/~daenzer/dri-trunk-sid/ on Debian unstable and the latest demo release of UT2003 (v2206 -- which is purported to not need S3TC extensions), I get the following traceback reported by UT2003: phil@trigger /scratch/phil/ut2k3/demo ./ut2003_demo Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. This looks like you are using Xig libGL.so library. Deinstall Xig libs before doing tests like this. No, that's ut2k3 looking for S3TC support. Actually, I'm not sure it's S3TC. There may be some other functionality in that X extension that it looks for. In any case, that message just means it couldn't find that X server extension. I see that and I've never had XiG drivers installed. No, it's not the S3TC stuff -- note the warnings in the logfile in my original email warning that a lack of S3TC support will lead to reduced performance. Googling around reveals that UT2003 complains about missing XiG-SUNDRY-NONSTANDARD extensions for other people and it appears entirely benign. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] UT2003 crash with current trunk
On Thu, Feb 20, 2003 at 06:13:01PM -0500, Daniel Vogel wrote: [ 6] /usr/X11R6/lib/modules-dri-trunk/dri/mga_dri.so [0x43f31fb7] [ 7] /scratch/phil/ut2k3/demo/System/OpenGLDrv.so(DrawPrimitive__ 22FOpenGLRenderInterface14EPrimitiveType+0x373) Might be interesting to know why it crashes inside the driver :) fwiw, here's the output from ut2003 if I set MESA_DEBUG and LIBGL_DEBUG: cpu vendor: AuthenticAMD cpu name: AMD Duron(tm) Processor MMX cpu detected. 3DNow! cpu detected. Testing OS support for SSE... yes. Testing OS support for SSE unmasked exceptions... SIGFPE, yes. Tests of OS support for SSE passed. SSE cpu detected. Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(param=GL_COMBINE_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(param=GL_COMBINE_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_COMBINE_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_COMBINE_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_RGB_SCALE_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_ALPHA_SCALE) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE0_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE1_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE2_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE0_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE1_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE2_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND0_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND1_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND2_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND0_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND1_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND2_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_COMBINE_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_COMBINE_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_RGB_SCALE_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_ALPHA_SCALE) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE0_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE1_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE2_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE0_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE1_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE2_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND0_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND1_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND2_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND0_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND1_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_OPERAND2_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_COMBINE_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_COMBINE_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_RGB_SCALE_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE1_RGB_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_SOURCE1_ALPHA_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_RGB_SCALE_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glTexEnv(pname=GL_RGB_SCALE_EXT) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error: GL_INVALID_ENUM in glDisable(0x8513) Mesa: Mesa user error:
