Re: [Dri-devel] mach64 binaries: do not work
> Well.. this can take a few days since I have to get some time to mess with > these scripts. Sorry. Take your time. Stabilizing things after 0-0-3 branching has definitely much higher priority. It is not a big problem to rebuild these objects. But - just to make it easier - could you please make i810_dma.c and i830_dma.c compilable (they give error messages about some "wait" identifiers - so I just have to comment out these lines). Is it a result of not complete merging or what? > Does the X log says "Direct Rendering Enabled" or "Direct Rendering > Disabled"? (II) ATI(0): [drm] installed DRM signal handler (II) ATI(0): [DRI] installation complete (II) ATI(0): [drm] Added 128 16384 byte DMA buffers (II) ATI(0): [drm] Mapped 128 DMA buffers at 0x40c18000 (II) ATI(0): Direct rendering enabled > If it does says it's enabled then the problem is related with libGL.so > somehow. If it doesn't then it's related to the kernel module / X. I am pretty confident it is libGL. But the version used by glxinfo is /usr/X11R6/lib/libGL.so.1.2 Any ideas? Regards, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do not work
On Die, 2002-03-12 at 10:49, Sergey V. Udaltsov wrote: > > Well.. this can take a few days since I have to get some time to mess with > > these scripts. Sorry. > Take your time. Stabilizing things after 0-0-3 branching has definitely > much higher priority. It is not a big problem to rebuild these objects. > But - just to make it easier - could you please make i810_dma.c and > i830_dma.c compilable (they give error messages about some "wait" > identifiers - so I just have to comment out these lines). Is it a result > of not complete merging or what? You don't have to build all modules; just make -f Makefile.linux mach64.o > > Does the X log says "Direct Rendering Enabled" or "Direct Rendering > > Disabled"? > (II) ATI(0): [drm] installed DRM signal handler > (II) ATI(0): [DRI] installation complete > (II) ATI(0): [drm] Added 128 16384 byte DMA buffers > (II) ATI(0): [drm] Mapped 128 DMA buffers at 0x40c18000 > (II) ATI(0): Direct rendering enabled > > > If it does says it's enabled then the problem is related with libGL.so > > somehow. If it doesn't then it's related to the kernel module / X. > I am pretty confident it is libGL. But the version used by glxinfo is > /usr/X11R6/lib/libGL.so.1.2 Setting LIBGL_DEBUG=verbose should give a hint. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do not work
> make -f Makefile.linux mach64.o Thanks. I did not know. I just did "make" I just noticed the error about dynamic loading: libGL cannot load /usr/X11R6-DRI/lib/modules/dri/mach64_dri.so. I think it is the error in your build scripts. They should use X11R6 directory instead, arent' they? After I created the link from X11R6 to X11R6-DRI - everything is fine (more or less, to the current state of the driver). Thanks for the help. Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do not work
On 2002.03.12 11:18 Sergey V. Udaltsov wrote: > > make -f Makefile.linux mach64.o > Thanks. I did not know. I just did "make" > There is a problem in the i8x0 modules source with the most recent kernels. I already had received a report of this problem which I forwarded to this list, since it's really outside of my competence to fix it. > I just noticed the error about dynamic loading: libGL cannot load > /usr/X11R6-DRI/lib/modules/dri/mach64_dri.so. I think it is the error in > your build scripts. They should use X11R6 directory instead, arent' > they? After I created the link from X11R6 to X11R6-DRI - everything is > fine (more or less, to the current state of the driver). > Yes, libGL should be using /usr/X11R6 indeed. I'm going to take libGL out of binary packages, as Jens did, so that this problem is no longer an issue. > Thanks for the help. > > Cheers, > > Sergey > José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon 7500 depth clears are working
You'll need to upgrade & rebuild the kernel module. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 7500 depth clears are working
Keith Whitwell wrote: > > You'll need to upgrade & rebuild the kernel module. > The lockups are still there, btw. Working on those now. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 7500 lockups
Well, it turns out I can kludge the lockup away simply by emitting lots of state between every primitive... This is actually similar then to a lockup I was seeing in the original radeon (which I did kludge out in this way). I'm wondering if the use of RADEON_3D_RNDR_GEN_INDX_PRIM is the problem: this is a r128-compatibility packet & may not be the most well-tested path in the hardware... Anyway, keeping on looking. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] FlightGear with Radeon
Today I saw some updates in the 'tcl-0-0-branch' and I decided to do a rebuild of that stuff. As far as I can tell the strange colours appear to be a little bit less strange. Unfortunately even if I set #define BuildXF86DRM YES in build/xc/config/cf/host.def no kernel module gets build. Is this an intended behaviour ? Also, unfortunately, I have to use the libGL and libGLU libraries from CVS to run the driver. I had the impression that programs should work using the libraries from my distribution, but this appears not to be the case by now, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Fwd: [Mesa3d-dev] viewperf]
Forwarding to dri-devel. Original Message Subject: [Mesa3d-dev] viewperf Date: Tue, 12 Mar 2002 13:51:52 +0100 (MET) From: Klaus Niederkrueger <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Hi, In the last week I have been playing with the spec-viewperf programs and (at least on my computer) I get very strange results with "DRV" (the oil-drilling-platform): With Mesa in software-mode (latest CVS) I do not see almost anything. It looks like the triangle-culling was killing the wrong side of the objects. If I use XFree-4.2 hw-rendering (Radeon VE), I see many more pipes though the ladders are not visible until the test uses only lines, instead of filled polygons. Also here there still seem to be some mistakes either with clipping (polygons at the border of the screen look strange) or culling (very small polygons seem to be missing) (or both). But then I went a step further and compiled the view-perf with the switches "-DMP" and "-lpthread", which seem to enable threads. While all other tests work (as far as I can tell), DRV crashes now. In Software-mode I get a segmentation fault and in hardware mode it says "RadeonSwapBuffers error: some number". Can anybody reproduce these problems? Klaus ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI tests (sort of)
The other day I upgraded to Quake 3 1.31. I was pretty irritated to realize that none of the old demos worked with the new version. I was even more irritated when I couldn't find any good demos (like crusher) to use for testing. So, I set out to create some. In the process I created some interesting config files (max textures, max geometry, fastest, etc.) and a shell script to run it all. Is there somewhere, on sourceforge perhaps, that I can put all of this? It sure would be useful if everyone could use the same "test" when they make changes. :) -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 7500 lockup kludge-around
I've committed a kludge that stops the 7500 from locking up in q3 demo001 and geartrain on my box. It's pretty ugly so I'm continuing to look at the problem (basically I emit some state between every primitive whether it's needed or not). In the meantime can I get some feedback as to whether this fixes the problems people have been seeing on their machines? Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture compression on mach64?!?
On Monday, 11. März 2002 20:21:06, Ian Romanick wrote: >Now, the new token could probably be skipped. If the requested internal > format is GL_COMPRESSED_RGB, just compress the texture and be done with it. > Given the likely hood of ANYONE having pre-compressed textures for this > format, this is probably both the easiest and best route to take. This is > amplified by the fact that I don't think that even the ATI drivers export > this functionality in OpenGL. Does anyone know any different? > > Perhaps we could discuss this more in the IRC chat today. > >http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt >http://oss.sgi.com/projects/ogl-sample/registry/3DFX/texture_compression_FXT1.txt >http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt Bill White had something partly working for the 3dfx VSA in the tdfx-2-1-branch or tdfx-SLI tree, can remember correctly. It is worth for ~10 fps speedup on the V5 5500 AGP (under Win). He told me that he can't commit it because of legal issues (S3). Regards, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Fwd: [Mesa3d-dev] viewperf]
> Forwarding to dri-devel. > > Original Message > Subject: [Mesa3d-dev] viewperf > Date: Tue, 12 Mar 2002 13:51:52 +0100 (MET) > From: Klaus Niederkrueger <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > Hi, > > In the last week I have been playing with the spec-viewperf programs and > (at least on my computer) I get very strange results with "DRV" (the > oil-drilling-platform): > > With Mesa in software-mode (latest CVS) I do not see almost anything. It > looks like the triangle-culling was killing the wrong side of the objects. Same as below, but slower ;-) > If I use XFree-4.2 hw-rendering (Radeon VE), I see many more pipes though > the ladders are not visible until the test uses only lines, instead of > filled polygons. Also here there still seem to be some mistakes either > with clipping (polygons at the border of the screen look strange) or > culling (very small polygons seem to be missing) (or both). I can second that with tdfx-trunk on V5 5500 AGP. > But then I went a step further and compiled the view-perf with the > switches "-DMP" and "-lpthread", which seem to enable threads. > While all other tests work (as far as I can tell), DRV crashes now. In > Software-mode I get a segmentation fault and in hardware mode it says > "RadeonSwapBuffers error: some number". > > Can anybody reproduce these problems? I will, but how have you solved the problem below? cc -o viewperf objs/Env.o objs/clock.o objs/texture.o objs/viewperf.o objs/eD.o objs/eI.o objs/eDM.o objs/eIM.o objs/eDA.o objs/eIA.o objs/eDMA.o objs/eIMA.o objs/eDW.o objs/eIW.o objs/eDMW.o objs/eIMW.o objs/eDAW.o objs/eIAW.o objs/eDMAW.o objs/eIMAW.o -L/usr/X11R6/lib -Lobjs -Lvpaux/libaux -Lvpaux/libtk -L/usr/lib -L/usr/lib -lvp -lm -lX11 -lXext -laux -lGL -lGLU -lz -lpng -lpthread objs/viewperf.o: In function `parse_args': objs/viewperf.o(.text+0x7af7): undefined reference to `GetNumProcessors' collect2: ld returned 1 exit status make: *** [viewperf] Error 1 `GetNumProcessors' is NOT defined in EnvLINUX.c. But in: Env.h:int GetNumProcessors(); EnvAIX.c: * GetNumProcessors - return number of processor on system EnvAIX.c:GetNumProcessors() EnvSGI.c: * GetNumProcessors - return number of processor on system EnvSGI.c:GetNumProcessors() EnvWin.c: * GetNumProcessors - return number of processor on system EnvWin.c:GetNumProcessors() EnvWin2.c: * GetNumProcessors - return number of processor on system EnvWin2.c:GetNumProcessors() grep: objs: Ist ein Verzeichnis grep: pngxor: Ist ein Verzeichnis grep: test: Ist ein Verzeichnis viewperf.c: eventblock.threads = GetNumProcessors (); grep: vpaux: Ist ein Verzeichnis -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture compression on mach64?!?
On Tue, Mar 12, 2002 at 10:43:43PM +0100, Dieter Nützel wrote: > Bill White had something partly working for the 3dfx VSA in the > tdfx-2-1-branch or tdfx-SLI tree, can remember correctly. > It is worth for ~10 fps speedup on the V5 5500 AGP (under Win). > > He told me that he can't commit it because of legal issues (S3). Is Bill still around? I've heard this before, but it doesn't make any sense to me. S3 owns S3TC, not FXT1 and not the VQ in the RagePro and not the VQ in the PowerVR SG. What IP that S3 owns is preventing this? -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 7500 lockup kludge-around
Around 21 o'clock on Mar 12, Keith Whitwell wrote: > In the meantime can I get some feedback as to whether this fixes the problems > people have been seeing on their machines? Yes, this seems to have fixed the lockups I've been seeing in tuxracer and bzflag. Tuxracer seems to work fine now. However bzflag has a set of "interesting" rendering problems. It uses textured GL_QUADS to draw glyphs and they get pretty scrambled. That problem appears on both the radeon and the tdfx card I've got, so it seems to be an issue with Mesa 4. On the radeon card, I'm also seeing problems with other texturing -- translucency isn't working (translucent objects appear opaque) and texture colors are getting scrambled (green becomes cyan). I could attempt to generate a smaller test case if that would be helpful. Eliminating the lockups is a huge feature though; I've been rather grateful to Ted Ts'o and Stephen Tweedie in the last couple of days. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture compression on mach64?!?
On Tue, Mar 12, 2002 at 23:41:23, Ian Romanick wrote: > On Tue, Mar 12, 2002 at 10:43:43PM +0100, Dieter Nützel wrote: > > > Bill White had something partly working for the 3dfx VSA in the > > tdfx-2-1-branch or tdfx-SLI tree, can remember correctly. > > It is worth for ~10 fps speedup on the V5 5500 AGP (under Win). > > > > He told me that he can't commit it because of legal issues (S3). > > Is Bill still around? Not that I know. Brian, Keith? > I've heard this before, but it doesn't make any sense to me. I told you. > S3 owns S3TC, not FXT1 and not the VQ in the RagePro and not the VQ > in the PowerVR SG. We have to convert from S3TC to FXT1 (UT for example). > What IP that S3 owns is preventing this? Don't know. Have a look at: http://marc.theaimsgroup.com/?l=dri-devel&m=97941445129309&w=2 Try a search for "s3tc" in the marc.theaimsgroup.com search engine. Maybe Daniel Vogel working at Epic know could shed some light on it. Regards, Dieter BTW Please CC me. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i830/Radeon Mobility
On Die, 2002-03-12 at 01:55, Lachlan Mulcahy wrote: > > I have a Radeon Mobility M6 LY running on a notebook using the i830 AGP > Chipset.. I was wondering is support for the i830 chipset rather flakey > at the moment, or is the radeon not well supported at this stage? You don't say what DRI code you use; I've made rather good experience with an M6 in a PowerBook running XFree86 4.2.0. > I have been able to get DRI/3D going but not consistently.. anytime I > run the X Server at a bit depth that would allow DRI (1024x768 @ 16bit > or less) on my card I get strange lock ups at inconsistent times.. > Sometimes during KDM start.. other's just in gnome.. sometimes i don't > even get kdm to load. As 2D is rock solid in my experience, I suspect you're having AGP problems. Try running lower AGP speeds if you aren't already running 1x. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i830/Radeon Mobility
On Wed, 2002-03-13 at 12:06, Michel Dänzer wrote: > On Die, 2002-03-12 at 01:55, Lachlan Mulcahy wrote: > > > > I have a Radeon Mobility M6 LY running on a notebook using the i830 AGP > > Chipset.. I was wondering is support for the i830 chipset rather flakey > > at the moment, or is the radeon not well supported at this stage? > > You don't say what DRI code you use; I've made rather good experience with > an M6 in a PowerBook running XFree86 4.2.0. Ahh Sorry.. running the code from linux-drm-4.2.0-kernelsource.tar.gz I grabbed it from a sourceforge link. glxinfo reports: Mesa DRI Radeon 20010402 AGP 1x x86/MMX/SSE (so yes.. i did drop try dropping down to agp 1x.. and that seems to be more solid) > > As 2D is rock solid in my experience, I suspect you're having AGP problems. > Try running lower AGP speeds if you aren't already running 1x. I'm now currently running @ AGP1x and 2d is pretty solid as well as 3d.. I'm no expert on AGP or anything but approximately what sort of speed increase should I expect when the agp drivers are solid at 4x? I would think that due to the relatively small amount of memory on the card (8mb DDR) the faster the agp the better.. as a side note.. I've also experienced some texture corruption in quake3. When there is a lot happening onscreen in wide open areas i often find that the text displaying the scores will become corrupt in flashes.. and after running timedemo's i'd occaisionally get visual corruption on the menus too. Don't know if this is driver related or due to heat or what.. just interesting to note.. also.. do you know of anywhere I can find some really detailed information on the Radeon Mobility M6 LY? cheers ldm/asqui ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 7500 lockup kludge-around
On Tue, 12 Mar 2002, Keith Whitwell wrote: > I've committed a kludge that stops the 7500 from locking up in q3 demo001 and > geartrain on my box. It's pretty ugly so I'm continuing to look at the > problem (basically I emit some state between every primitive whether it's > needed or not). > > In the meantime can I get some feedback as to whether this fixes the problems > people have been seeing on their machines? No luck with Q3 here. On the other hand, gltron works great :-) All the xscreensaver GL apps (except for pipes) work great (pipes "flashes" part of the pipes at me). Basically, all the rendering errors I previously reported seem to be gone. Rune, UT, heretic2 all work great as well. Q3A and tuxracer both lockup on me still. Adam ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 insight
I was making some research on the texture compression issue and decided to take a look on the stuff I had downloaded from ATI developer home. I came across this document http://www.ati.com/developer/ravesupt.html which describes the QuickDraw 3D RAVE API for MacOS, which seems to be a low-level HAL. The information about texture compression is rather vague, but this documents gives several insights to the Mach64 chip. I found especially interesting the "Texture From Context" which can be used for fill in the gaps of some blending modes! José Fonseca PS: Another valuable resource I found which I'll surely add to the faq is http://www.realtimerendering.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Fwd: [Mesa3d-dev] viewperf]
I can answer that. Add this to the bottom of EnvLinux:
int GetNumProcessors() {
return (1);
}
It's OK, they just return 2 for Irix ;-)
Exercise for the reader: what's the *correct* way to implement this
function?
Dieter Nützel wrote:
>>Forwarding to dri-devel.
>>
>> Original Message
>>Subject: [Mesa3d-dev] viewperf
>>Date: Tue, 12 Mar 2002 13:51:52 +0100 (MET)
>>From: Klaus Niederkrueger <[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED]
>>
>>Hi,
>>
>>In the last week I have been playing with the spec-viewperf programs and
>>(at least on my computer) I get very strange results with "DRV" (the
>>oil-drilling-platform):
>>
>>With Mesa in software-mode (latest CVS) I do not see almost anything. It
>>looks like the triangle-culling was killing the wrong side of the objects.
>>
>
> Same as below, but slower ;-)
>
>
>>If I use XFree-4.2 hw-rendering (Radeon VE), I see many more pipes though
>>the ladders are not visible until the test uses only lines, instead of
>>filled polygons. Also here there still seem to be some mistakes either
>>with clipping (polygons at the border of the screen look strange) or
>>culling (very small polygons seem to be missing) (or both).
>>
>
> I can second that with tdfx-trunk on V5 5500 AGP.
>
>
>>But then I went a step further and compiled the view-perf with the
>>switches "-DMP" and "-lpthread", which seem to enable threads.
>>While all other tests work (as far as I can tell), DRV crashes now. In
>>Software-mode I get a segmentation fault and in hardware mode it says
>>"RadeonSwapBuffers error: some number".
>>
>>Can anybody reproduce these problems?
>>
>
> I will, but how have you solved the problem below?
>
> cc -o viewperf objs/Env.o objs/clock.o objs/texture.o objs/viewperf.o
> objs/eD.o objs/eI.o objs/eDM.o objs/eIM.o objs/eDA.o objs/eIA.o objs/eDMA.o
> objs/eIMA.o objs/eDW.o objs/eIW.o objs/eDMW.o objs/eIMW.o objs/eDAW.o
> objs/eIAW.o objs/eDMAW.o objs/eIMAW.o -L/usr/X11R6/lib -Lobjs -Lvpaux/libaux
> -Lvpaux/libtk -L/usr/lib -L/usr/lib -lvp -lm -lX11 -lXext -laux -lGL -lGLU
> -lz -lpng -lpthread
> objs/viewperf.o: In function `parse_args':
> objs/viewperf.o(.text+0x7af7): undefined reference to `GetNumProcessors'
> collect2: ld returned 1 exit status
> make: *** [viewperf] Error 1
>
> `GetNumProcessors' is NOT defined in EnvLINUX.c.
> But in:
>
> Env.h:int GetNumProcessors();
> EnvAIX.c: * GetNumProcessors - return number of processor on system
> EnvAIX.c:GetNumProcessors()
> EnvSGI.c: * GetNumProcessors - return number of processor on system
> EnvSGI.c:GetNumProcessors()
> EnvWin.c: * GetNumProcessors - return number of processor on system
> EnvWin.c:GetNumProcessors()
> EnvWin2.c: * GetNumProcessors - return number of processor on system
> EnvWin2.c:GetNumProcessors()
> grep: objs: Ist ein Verzeichnis
> grep: pngxor: Ist ein Verzeichnis
> grep: test: Ist ein Verzeichnis
> viewperf.c: eventblock.threads = GetNumProcessors ();
> grep: vpaux: Ist ein Verzeichnis
>
> -Dieter
>
>
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 7500 lockup kludge-around
Around 16 o'clock on Mar 12, Keith Packard wrote: > Yes, this seems to have fixed the lockups I've been seeing in tuxracer and > bzflag. I've found one additional easily reproduced lockup. Starting bzflag with textures disabled causes the screen to clear and the display to lock up. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] FlightGear with Radeon
Martin Spott wrote: > > Today I saw some updates in the 'tcl-0-0-branch' and I decided to do a > rebuild of that stuff. As far as I can tell the strange colours appear to be > a little bit less strange. > > Unfortunately even if I set > > #define BuildXF86DRM YES > > in build/xc/config/cf/host.def no kernel module gets build. Is this an > intended behaviour ? Also, unfortunately, I have to use the libGL and libGLU > libraries from CVS to run the driver. I had the impression that programs > should work using the libraries from my distribution, but this appears not > to be the case by now, Martin, If you use the downloadable binaries from ftp://ftp.tungstengraphics.com/dri you should be able to use them with the libGL from your distribution. I just posted a new driver this evening built with Keith's latest round of changes. I have had to add a couple of patches for compatability. The libGL compatability patch will be making it into the CVS repository soon. The DDX driver compatability patch won't be going in--because it relies on a hack of the modules versioning that we don't want to change for new XFree86 distributions. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: mach64-0-0-3-branch)
"Jos? R. Fonseca" wrote: > > CVSROOT:/cvsroot/dri > Module name:xc > Repository: xc/xc/lib/GL/glx/ > Changes by: jrfonseca@usw-pr-cvs1. 02/03/12 11:13:35 > > Log message: > Applied Jens' patch to fix libGL incompatibility > > Modified files: > xc/xc/lib/GL/glx/:Tag: mach64-0-0-3-branch > glxclient.h > > Revision ChangesPath > 1.17.4.1 +6 -1 xc/xc/lib/GL/glx/glxclient.h Jose, I've been holding off from putting this into CVS until we can fix this right. See Brian's e-mail on removing the field completely and referencing the "currentDrawable" field instead. I was planning on doing this later this week--unless you want to do this sooner. If you do, send me your patch so we can apply it to the trunk and the tcl-0-0-branch. It might also be a good idea to apply this to the BSD branch. We really don't want any major releases going out with this incompatible field. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 7500 lockup kludge-around
On Tue, Mar 12, 2002 at 04:53:43PM -0800, Keith Packard wrote: > On the radeon card, I'm also seeing problems with > other texturing -- translucency isn't working (translucent objects appear > opaque) Thanks for the report. I'd seen that (in a different program) and forgotten about it. (A temp workaround is export RADEON_NO_VTXFMT=1) At least 3 things here a) _FPALPHA is never set, so it never sends alpha to the card. Trivial fix (I think) to check ctx->Color.AlphaEnabled in choose_vertex_format and set it appropriately? b) ~/glut/demos/contrib/steam which has a toggle for transparent reveals a subtler issue with CHOOSE_COLOR. A typical path will go neutral_Color -> choose_Color -> radeon_ At some stage _mesa_restore_exec_vtxfmt will replace the neutral_Color because we aren't saving the second clobber in Swapped. But CHOOSE_COLOR conditionally calls _mesa_install_exec_vtxfmt itself, which does the above restore, so whereas typically we clobber a TnlModule.Swapped function, it's possible for CHOOSE_COLOR to restore neutral_xx just prior to us clobbering it and we're stuck forever with SwapCount 0 and (in this case) radeon_Color4f_3f, even when the vertex_format changes and we want radeon_Color4f_4f. Could add a restore bool param to _mesa_install_exec_vtxfmt or a new norestore version of the function? c) There is some bug in the assembler too (when (a) is added), but I've not looked deeply here yet. -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI tests (sort of)
Ian Romanick wrote: > The other day I upgraded to Quake 3 1.31. I was pretty irritated to realize > that none of the old demos worked with the new version. I was even more > irritated when I couldn't find any good demos (like crusher) to use for > testing. So, I set out to create some. In the process I created some > interesting config files (max textures, max geometry, fastest, etc.) and a > shell script to run it all. > > Is there somewhere, on sourceforge perhaps, that I can put all of this? It > sure would be useful if everyone could use the same "test" when they make > changes. :) > > the old 1.30 demo "four" will run ok if you "unzip pak6.pk3 demos/four.dm_66" and then rename it to four.dm_67 - it won't run from the menu for me, seems to be some sort of case issue (looks for FOUR.dm_67 or something), but you can run "demo four" from the console cheers Brendan ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] GET FREE PORN ACCESS NOW!! gtl.egoBnkfus0gqp...gtl.egzgoBojtvw0vqxsdgjquih/ogx...
GET FREE PORN ACCESS NOW!! CLICK ON THE LINK BELOW AND GET OFF NOW!! http://www.netvisionsenterprises.com/jok55 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
