Re: [Dri-devel] mesa-4-1-branch testing...
On Mit, 2002-11-20 at 16:56, Adam K Kirchhoff wrote: On 20 Nov 2002, Michel [ISO-8859-1] Dänzer wrote: On Mit, 2002-11-20 at 00:38, Adam K Kirchhoff wrote: heretic2 has some problems, but they also show up in the trunk :-) Basically, any sort of flashing (like if my character throws a fireball), causes a huge drop in the framerate. It uses the Quake 2 engine, right? As has been discussed here before, it has an inefficient implementation of dynamic lighting with multitexturing. Try set gl_ext_multitexture 0 or set gl_dynamic 0 set gl_ext_multitexture 0 didn't work. I forgot to try gl_dynamic before I left for work. I'll hopefully be able to give it a whirl tonight. You've let me know in private that it does the trick. set gl_ext_multitexture 0 might have required a restart, of the renderer at least. I've also given it a shot under FreeBSD. The results with GL applications (both native and linux through the binary compatability layer) are the same. *However* the X server itself seems rather unstable. At first, I couldn't figure it out; everytime I went to start X, the server would start up for a split second and then die. After some experimenting, I discovered that the problem was gkrellm, which was in my .xinitrc. More specifically, it seems to be any gtk-2.0 application. In addition, when I switched to kde3 as my window manager, the same thing happened. So, I can run enlightenment without any problem. However, if I start any gtk-2.0 apps, or kde3 apps (maybe it's qt?), the X server will die :-) There have been reports of crashes in the TrueType font renderers, could it be that? Hmmm... I guess that's a possibility. I tried another experiment this morning and the results kind of surprised me. If I start X with xinit /usr/X11R6/bin/xterm and then launch metacity from the xterm, the server will crash. If, however, I start X with xinit /usr/X11R6/bin/metacity, the server starts up and runs fine. Weird. I'm including the last 60 lines of /var/log/XFree86.0.log. You'll notice that there's an unresolved symbol in libGLcore.a Yes, and you'll also notice the disclaimer before the crash. :) AFAICS there are no OpenGL apps involved so I doubt the unresolved symbol is relevant. A backtrace (with more information than all '??' :) would be interesting. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
On Mit, 2002-11-20 at 22:04, Martin Spott wrote: Brian wrote: Adam K Kirchhoff wrote: So I decided to give the mesa-4-1-branch a whirl and do some testing... I grabbed it from CVS: $ cvs -z3 co -r mesa-4-1-branch xc Do a CVS update again in case you didn't get my latest check-ins. I just ran FlightGear with this branch (instead of employing binary snapshots) on my Radeon7500. Everything is quite fast, the colours look perfect, the previously known feature of everything appearing too dark has gone ! Great, unfortunately lighting is still broken with pulsar -light, so that doesn't seem to be the same problem. The airplane's control panel looks a bit strange - but this might be a different subject. Unfortunately the X server crashes before I get an opportunity to create a screenshot ;-) It seemed to run longer if not indefinitely with some debugging output enabled... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)
On Wed, 20 Nov 2002, Ian Romanick wrote: On Tue, Nov 19, 2002 at 11:06:16PM -0800, Linus Torvalds wrote: On Wed, 20 Nov 2002, Dieter Nützel wrote: Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton: Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do some testing. No go so far. Modules are somewhat broken in 2.5.48. One approach is to not use modules, just compile the thing in. Works for me (damn, I'd like to see how the commercial tuxracer looks with bump mapping. But apparently DRI doesn't support the right extension or something ;) The problem is that it uses EXT_texture_env_dot3 (which the driver does advertise), but the driver doesn't actually implement only implements EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly. I noted this in an earlier thread about glaxium, but I haven't posted a fix yet. I have attached a patch to the DRI CVS trunk that should fix the problem. I don't have access to an 8500, so I haven't actually tested it. I would really appreciate it if people with 8500 (or 9000) cards could try this patch and tell me if it works. If I get a few positive results and no negatives, I'll commit the patch. I've applied the patch to two machines, one running Linux and one running FreeBSD. I compiled on both machines and installed. Unfortunately, I won't be able to test the Linux box till I get home, but I'm going to assume that the results are going to be the same :-) http://memory.visualtech.com/glaxium.png Unfortunately, it doesn't look like the patch worked :-( Adam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch testing...
Hi! I've done some more testing on the mesa-4-1-branch (checked out and compiled yesterday) All in all everything runs quite nicely and stable. I successfully tested: -quake (quakeforge-0.5.2): works, but quite sluggish, especially when there are lots of light effects -quake2 (quakeIIforge 0.1): works stable and fast, but only with dynamic lighting disabled, as suggested earlier with dynamic lighting and multitexturing it's hardly playable -quake3 (1.32): nice, fast and stable ;-) -return to castle wolfenstein (1.3): now works stable for me, as far as I can tell, but performance is a bit weird: it's fast most of the time, but sometime framerates drop to almost 0 for a little while, mostly when opening doors, entering new rooms etc. (but that could also be related to low system ram, i only got 256 MB, and I'm playing at max. details) -tuxracer -tuxkart -gltron -glxgears ;-) -half-life (using winex): seemed stable, but not very fast. switching on your flashlight for example hugely affects performance (goes down to ~5fps or s.th.) Apps that I had problems with: -flightgear: after some left- and right-clicking in the fgfs-window my keyboard wasn't responsive anymore. This happened once only, but i didn't really test fgfs, as i don't have a clue about how to play it :) General prolems/issues: Changing resolution in wolfenstein, q3a, q2 etc. does not work. It will not crash the box, but give garbage pictures on the screen. Software-TCL produces flickering/missing textures in wolfenstein (q3a is fine) I did the testing with a r200 (8500 QL), amd athlon XP, via kt266a-mainboard, using debian-unstable and linux-2.4.20-rc1. It seems that now AGP4x is also fairly stable for me, but I have to do some longer testing do definitely confirm this, most of the testing was done at AGP1x. Fastwrites are disabled, pageflipping is enabled Thanks for the nice work, Stefan --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)
Adam K Kirchhoff wrote: On Wed, 20 Nov 2002, Ian Romanick wrote: On Tue, Nov 19, 2002 at 11:06:16PM -0800, Linus Torvalds wrote: On Wed, 20 Nov 2002, Dieter N?tzel wrote: Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton: Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do some testing. No go so far. Modules are somewhat broken in 2.5.48. One approach is to not use modules, just compile the thing in. Works for me (damn, I'd like to see how the commercial tuxracer looks with bump mapping. But apparently DRI doesn't support the right extension or something ;) The problem is that it uses EXT_texture_env_dot3 (which the driver does advertise), but the driver doesn't actually implement only implements EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly. I noted this in an earlier thread about glaxium, but I haven't posted a fix yet. I have attached a patch to the DRI CVS trunk that should fix the problem. I don't have access to an 8500, so I haven't actually tested it. I would really appreciate it if people with 8500 (or 9000) cards could try this patch and tell me if it works. If I get a few positive results and no negatives, I'll commit the patch. I've applied the patch to two machines, one running Linux and one running FreeBSD. I compiled on both machines and installed. Unfortunately, I won't be able to test the Linux box till I get home, but I'm going to assume that the results are going to be the same :-) http://memory.visualtech.com/glaxium.png Unfortunately, it doesn't look like the patch worked :-( I'm not sure what it's supposed to look like. Can you try software rendering, just to get a screen-shot.? -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Triple Buffering
On Sun, Oct 27, 2002 at 04:44:34PM +0100, Felix Kühling wrote: But this way you waste lots of CPU cycles on frames which are never displayed. Wouldn't be waiting (IRQ) for the pageflip to occur before you render the 3rd frame in the above example a better approach? What's the point of trying to display 120 Hz if you monitor can only do 85 Hz? On SGIs, which sync to vblank per default, there's a query which sort of tells you how much time you have before the next swap happens. In that way you can decide if you want to wait for it or miss it. If you let it fly by, you can use the extra time to keep doing stuff in your simulation. The way I understood triple buffering the intention is to avoid hanging there for long times waiting for the vblank. You get the benefits from sync-to-vblank (no tearing) while paying a somewhat smaller price. -- Marcelo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] New ATI FireGL drivers announced
Title: New ATI FireGL drivers announced
Hello,
i know that DRI is targeting open source development,
but i know myselves that for a developer there can
always be a need for a 2nd source driver reference.
There are several other reasons why an alternate
Linux driver might be of interest for the audience.
So please excuse me for posting this information to your lists.
So this passed the news wires today:
ATI drives graphics performance for Linux users with new unified driver
http://mirror.ati.com/companyinfo/press/2002/4574.html
The drivers can now be downloaded for free at www.ati.com
(see e.g. Linux FireGL 8800).
The drivers should run on Linux/x86 with glibc 2.2,
some common kernel modules do come precompiled and
a build environment for gcc2.96 and gcc3.2 is included,
thus making that drivers compatible with
e.g. RedHat(R) Linux(R)/x86 8.0 or 7.3 versions.
Supported cards should be (list might not be complete):
- ATI Radeon 8500 {/DV/LE}, 9000 {/PRO}, 9500 {/PRO}, 9700 {/PRO} - Built by ATI
- ATI FireGL 8700, 8800, E1, X1, Z1/X1-128MB (just announced for retail), Mobility
I installed that drivers and tested them a tiny little bit.
Simple applications like glxgears do perform very well and
they are working quite nice for ut2003_demo (S3TC!), Maya and Houdini.
My impression is that things like Quake, Chromium or Blender should work.
I just had a few minutes of a one-man tournament session this noon.
I tried XVideo support and it showed that the CPU usage of TOP
was higher than that of the video player application. Features
that you will on FireGL boards are Overlays and PBuffer rendering
support.
Please excuse me again, i furthert want to give a few of the end
users an alternative to the dri drivers, which are often only
really useable if you do have downloaded som 60 MB of CVS sources
and built whole XF86 with a not totally trivial process.
Let me express that i do _not_ object to any of the DRI-Devel works.
DRI did great job and it resolves for situations where ATI
cant provide solutions as of today and possibly long term.
Just saying embedded Radeon chipsets, ATI chipsets on BSD,
old ATI chipsets prior to the R200 and further any sort of
experimental and custom extensions to the DRI open source
drivers.
Let's hope, no one does mind this mailing.
-Alex.
PS: not speaking for my employer, just documenting things that
are already publicly availabel.
Re: [Dri-devel] Triple Buffering
On Thu, 21 Nov 2002 12:14:20 +0100 Marcelo E. Magallon [EMAIL PROTECTED] wrote: What's the point of trying to display 120 Hz if you monitor can only do 85 Hz? the faster you render, the lower your latency. its pointless for 3D modelling / artwork, but very nice for 3D games. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New ATI FireGL drivers announced
On Thu, Nov 21, 2002 at 04:33:47PM +0100, Alexander Stohr wrote:
Hello,
i know that DRI is targeting open source development,
but i know myselves that for a developer there can
always be a need for a 2nd source driver reference.
There are several other reasons why an alternate
Linux driver might be of interest for the audience.
So please excuse me for posting this information to your lists.
So this passed the news wires today:
ATI drives graphics performance for Linux users with new unified driver
http://mirror.ati.com/companyinfo/press/2002/4574.html
The drivers can now be downloaded for free at www.ati.com
(see e.g. Linux FireGL 8800).
The drivers should run on Linux/x86 with glibc 2.2,
some common kernel modules do come precompiled and
a build environment for gcc2.96 and gcc3.2 is included,
thus making that drivers compatible with
e.g. RedHat(R) Linux(R)/x86 8.0 or 7.3 versions.
Supported cards should be (list might not be complete):
- ATI Radeon 8500 {/DV/LE}, 9000 {/PRO}, 9500 {/PRO}, 9700 {/PRO} - Built
by ATI
- ATI FireGL 8700, 8800, E1, X1, Z1/X1-128MB (just announced for retail),
Mobility
I installed that drivers and tested them a tiny little bit.
Simple applications like glxgears do perform very well and
they are working quite nice for ut2003_demo (S3TC!), Maya and Houdini.
My impression is that things like Quake, Chromium or Blender should work.
I just had a few minutes of a one-man tournament session this noon.
I tried XVideo support and it showed that the CPU usage of TOP
was higher than that of the video player application. Features
that you will on FireGL boards are Overlays and PBuffer rendering
support.
Please excuse me again, i furthert want to give a few of the end
users an alternative to the dri drivers, which are often only
really useable if you do have downloaded som 60 MB of CVS sources
and built whole XF86 with a not totally trivial process.
Let me express that i do _not_ object to any of the DRI-Devel works.
DRI did great job and it resolves for situations where ATI
cant provide solutions as of today and possibly long term.
Just saying embedded Radeon chipsets, ATI chipsets on BSD,
old ATI chipsets prior to the R200 and further any sort of
experimental and custom extensions to the DRI open source
drivers.
Let's hope, no one does mind this mailing.
-Alex.
PS: not speaking for my employer, just documenting things that
are already publicly availabel.
Quote from the webpage (URL above):
The new unified driver provides robust OpenGL® 2.0 support for many of ATIs
award-winning graphics boards including:
Does these drivers _really_ have OGL 2.0 support?
-- Pasi Kärkkäinen
^
. .
Linux
/-\
Choice.of.the
.Next.Generation.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48)
On Thu, Nov 21, 2002 at 08:28:01AM -0500, Adam K Kirchhoff wrote:
On Wed, 20 Nov 2002, Ian Romanick wrote:
On Tue, Nov 19, 2002 at 11:06:16PM -0800, Linus Torvalds wrote:
On Wed, 20 Nov 2002, Dieter Nützel wrote:
Am Mittwoch, 20. November 2002 00:55 schrieb Ian Molton:
Linus updated 2.5.48 with Brian's latest DRM r200 stuff so I should do
some testing.
No go so far.
Modules are somewhat broken in 2.5.48.
One approach is to not use modules, just compile the thing in. Works for
me (damn, I'd like to see how the commercial tuxracer looks with bump
mapping. But apparently DRI doesn't support the right extension or
something ;)
The problem is that it uses EXT_texture_env_dot3 (which the driver does
advertise), but the driver doesn't actually implement only implements
EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly. I noted this in an
earlier thread about glaxium, but I haven't posted a fix yet.
I have attached a patch to the DRI CVS trunk that should fix the problem. I
don't have access to an 8500, so I haven't actually tested it. I would
really appreciate it if people with 8500 (or 9000) cards could try this
patch and tell me if it works. If I get a few positive results and no
negatives, I'll commit the patch.
I've applied the patch to two machines, one running Linux and one running
FreeBSD. I compiled on both machines and installed. Unfortunately, I
won't be able to test the Linux box till I get home, but I'm going to
assume that the results are going to be the same :-)
http://memory.visualtech.com/glaxium.png
Unfortunately, it doesn't look like the patch worked :-(
My bad! Change the at the end of line 1082 in r200_texstate.c to ||.
The if-statement that compares against GL_DOT3_{RGB,RGBA}_EXT should match
the one that compares against GL_DOT3_{RGB,RGBA}. Sorry.
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] ATI Rage Mobility 128 probs with normal users...
Hi all, i have a problem with the R128 driver: when i launch X from a normal user, the XFree driver r128 is loaded, but when i launch an openGL application like glxinfo i get this output: name of display: :0.0 drmR128GetParam (R128_PARAM_IRQ_NR): -13 Segmentation fault The lsmod output shows that r128 and agpgart kernel drivers have been loaded. My machine is a ibook2 laptop with an Ati Rage 128 Mobility with 8 Megs. If the user is 'root', all works correctly. Thanks, -- Francesco Sportolari --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Do Matrox/ATI help DRI devs?
I asked about this on dri-users but I think it may be better placed here. I was just browsing around the developer relations areas of the ATI and Matrox sites, and I'm getting the impression that they don't really care about having open source DRI drivers available for their products. Are these companies friendly towards XFree86/DRI devs? That is to say, do they provide timely, accurate, and complete docs? Are they helpful? I'm interested in supporting the most DRI-friendly manufacturers by buying their products, but I also think this information would be interesting to developers considering working on the DRI. Thank you. ---John --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)
On Thu, 21 Nov 2002, Ian Romanick wrote:
On Thu, Nov 21, 2002 at 08:28:01AM -0500, Adam K Kirchhoff wrote:
On Wed, 20 Nov 2002, Ian Romanick wrote:
The problem is that it uses EXT_texture_env_dot3 (which the driver does
advertise), but the driver doesn't actually implement only implements
EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly. I noted this in an
earlier thread about glaxium, but I haven't posted a fix yet.
I have attached a patch to the DRI CVS trunk that should fix the problem. I
don't have access to an 8500, so I haven't actually tested it. I would
really appreciate it if people with 8500 (or 9000) cards could try this
patch and tell me if it works. If I get a few positive results and no
negatives, I'll commit the patch.
I've applied the patch to two machines, one running Linux and one running
FreeBSD. I compiled on both machines and installed. Unfortunately, I
won't be able to test the Linux box till I get home, but I'm going to
assume that the results are going to be the same :-)
http://memory.visualtech.com/glaxium.png
Unfortunately, it doesn't look like the patch worked :-(
My bad! Change the at the end of line 1082 in r200_texstate.c to ||.
The if-statement that compares against GL_DOT3_{RGB,RGBA}_EXT should match
the one that compares against GL_DOT3_{RGB,RGBA}. Sorry.
Unfortunately, that only seemed to make things worse. If you check out
the same URL I posted above, you'll see what I mean.
Adam
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48)
On Thu, Nov 21, 2002 at 11:57:32AM -0500, Adam K Kirchhoff wrote:
On Thu, 21 Nov 2002, Ian Romanick wrote:
On Thu, Nov 21, 2002 at 08:28:01AM -0500, Adam K Kirchhoff wrote:
On Wed, 20 Nov 2002, Ian Romanick wrote:
The problem is that it uses EXT_texture_env_dot3 (which the driver does
advertise), but the driver doesn't actually implement only implements
EXT_texture_env_dot3 or ARB_texture_env_dot3 correctly. I noted this in an
earlier thread about glaxium, but I haven't posted a fix yet.
I have attached a patch to the DRI CVS trunk that should fix the problem. I
don't have access to an 8500, so I haven't actually tested it. I would
really appreciate it if people with 8500 (or 9000) cards could try this
patch and tell me if it works. If I get a few positive results and no
negatives, I'll commit the patch.
I've applied the patch to two machines, one running Linux and one running
FreeBSD. I compiled on both machines and installed. Unfortunately, I
won't be able to test the Linux box till I get home, but I'm going to
assume that the results are going to be the same :-)
http://memory.visualtech.com/glaxium.png
Unfortunately, it doesn't look like the patch worked :-(
My bad! Change the at the end of line 1082 in r200_texstate.c to ||.
The if-statement that compares against GL_DOT3_{RGB,RGBA}_EXT should match
the one that compares against GL_DOT3_{RGB,RGBA}. Sorry.
Unfortunately, that only seemed to make things worse. If you check out
the same URL I posted above, you'll see what I mean.
Hmm...could you try two quick tests for me? Both would be with an unpatched
driver.
1. Try running with LIBGL_ALWAYS_INDIRECT=1. I expect that will produce the
same results I see on a Radeon M6.
2. Replace GL_DOT3_RGB_EXT on line 592 of scene.cpp (in glaxium 0.5) with
GL_DOT3_RGB and rebuild glaxium. If that doesn't work, then dot3
bumpmapping is totally hosed in the R200 driver. I expect that this will
also produce correct results.
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
I just ran FlightGear with this branch (instead of employing binary snapshots) on my Radeon7500. Everything is quite fast, the colours look perfect, the previously known feature of everything appearing too dark has gone ! Hmmm, today I had to realize that this is still dependend on the direction you look at. But still better than before, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New ATI FireGL drivers announced
Let me express that i do _not_ object to any of the DRI-Devel works. DRI did great job and it resolves for situations where ATI cant provide solutions as of today and possibly long term. Just saying embedded Radeon chipsets, ATI chipsets on BSD, old ATI chipsets prior to the R200 and further any sort of experimental and custom extensions to the DRI open source drivers. Let's hope, no one does mind this mailing. I appreciate the hard work put into a commercial driver, and I'm sure a very large number of users will really appreciate the S3TC support, since an open solution has not yet been implemented due to legal issues. By reading the readme, xinerma+dri is not yet supported. Is support planned for this? if so, when? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
On Wed, 20 Nov 2002, Linus Torvalds wrote: On Thu, 21 Nov 2002, Dieter Nützel wrote: Option AGPFastWrite 1 This just makes the machine lock up for me at X startup. same here, instant and nasty lockup. Ingo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48)
On Thu, Nov 21, 2002 at 01:27:03PM -0500, Adam K Kirchhoff wrote: Hmmm... Well, line 592 of scene.cpp (in glaxium 0.5, just downloaded from the website) seems to be: glEnable(GL_TEXTURE_2D); Line 586, though, makes reference to GL_DOT3_RGB_EXT. I've made the change there. Now, with the unpatched driver and the patched game, the results look exactly look they did with the patched driver and the unpatched game! I believe that we may have discovered one of the subtle differences between the R100 family of chips and the R200 family. On the R100, when DOT3 bumpmapping is selected the driver has to manually select the implicit 4X multiplier required by the ARB EXT specs. It seems that when the R200 this is not needed. The unpatched driver programs the chip to do DOT3 and a 4X scale. It seems that the result is a 4X + 4X scale, or a 16X scale. The result is that all fragments end up saturated to white. If this theory is correct, then this patch should fix it. I'm crossing my fingers... -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html r200_DOT3_EXT.patch.gz Description: application/gunzip
Re: [Dri-devel] New ATI FireGL drivers announced
On Thu, Nov 21, 2002 at 05:50:51PM +0200, Pasi Kärkkäinen wrote: | | Quote from the webpage (URL above): | | The new unified driver provides robust OpenGL® 2.0 support for many of ATIs | award-winning graphics boards including: | | | Does these drivers _really_ have OGL 2.0 support? Couldn't possibly. There isn't even an approved spec for OpenGL 2.0 yet. Allen --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] RE: [Dri-users] ATI drivers
Title: New ATI FireGL drivers announced
with
the last drivers i got a 'third party chipset or board not suported ' ??? but
all radeon 8500 are not built by ati !!!
-Mensagem original-De:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Em nome de Alexander
StohrEnviada: quinta-feira, 21 de Novembro de 2002
15:34Para: [EMAIL PROTECTED];
[EMAIL PROTECTED]Assunto: [Dri-users] New ATI FireGL
drivers announced
Hello,
i know that DRI is targeting open source development,
but i know myselves that for a developer there can
always be a need for a 2nd source driver reference.
There are several other reasons why an alternate
Linux driver might be of interest for the audience.
So please excuse me for posting this information to your
lists.
So this passed the news wires today: ATI drives graphics performance for Linux users with new unified
driver http://mirror.ati.com/companyinfo/press/2002/4574.html
The drivers can now be downloaded for free at www.ati.com
(see e.g. Linux FireGL 8800).
The drivers should run on Linux/x86 with glibc 2.2,
some common kernel modules do come precompiled and
a build environment for gcc2.96 and gcc3.2 is
included, thus making that drivers compatible with
e.g. RedHat(R) Linux(R)/x86 8.0 or 7.3
versions.
Supported cards should be (list might not be complete):
- ATI Radeon 8500 {/DV/LE}, 9000 {/PRO}, 9500 {/PRO}, 9700
{/PRO} - "Built by ATI" - ATI FireGL 8700, 8800,
E1, X1, Z1/X1-128MB (just announced for retail), Mobility
I installed that drivers and tested them a tiny little
bit. Simple applications like glxgears do perform very
well and they are working quite nice for ut2003_demo
(S3TC!), Maya and Houdini. My impression is that
things like Quake, Chromium or Blender should work. I
just had a few minutes of a one-man tournament session this noon.
I tried XVideo support and it showed that the CPU usage of
TOP was higher than that of the video player
application. Features that you will on FireGL boards
are Overlays and PBuffer rendering support.
Please excuse me again, i furthert want to give a few of the
end users an alternative to the dri drivers, which are
often only really useable if you do have downloaded
som 60 MB of CVS sources and built whole XF86 with a
not totally trivial process.
Let me express that i do _not_ object to any of the DRI-Devel
works. DRI did great job and it resolves for
situations where ATI cant provide solutions as of
today and possibly long term. Just saying embedded
Radeon chipsets, ATI chipsets on BSD, old ATI chipsets
prior to the R200 and further any sort of experimental
and custom extensions to the DRI open source drivers.
Let's hope, no one does mind this mailing.
-Alex.
PS: not speaking for my employer, just documenting things
that are already publicly
availabel.
Followup: [Dri-devel] New ATI FireGL drivers announced
On Thu, Nov 21, 2002 at 05:50:51PM +0200, Pasi Kärkkäinen wrote: | | Quote from the webpage (URL above): | | The new unified driver provides robust OpenGL® 2.0 support for many of ATIs | award-winning graphics boards including: | | | Does these drivers _really_ have OGL 2.0 support? ATI says it's a typo, and apologizes. They intended to write OpenGL 1.4. Allen --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Re: [Dri-devel] New ATI FireGL drivers announced
By reading the readme, xinerma+dri is not yet supported. Is support planned for this? if so, when? that's something that'll have to be built into the core X infrastructure, from what I hear. maybe X 5.0 will have some capability for that; but don't hold your breath. if you need it, try XiG's Accelerated X. Carl Soderstrom. -- Systems Administrator Real-Time Enterprises www.real-time.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] New ATI FireGL drivers announced
Title: RE: [Dri-devel] New ATI FireGL drivers announced By reading the readme, xinerma+dri is not yet supported. Is support planned for this? if so, when? To be honest, i just dont know because i am not that deeply involved in 2D development. Anyways, i wouldnt be allowed to talk about it. Company and business rules. -Alex. PS: looking for OpenGL 3.0 shedules myselves. *grin*
Re: R200 DOT3 EXT problems (was Re: [Dri-devel] mesa 4.1 branch /NO go on 2.5.48)
On Thu, 21 Nov 2002, Ian Romanick wrote: On Thu, Nov 21, 2002 at 01:27:03PM -0500, Adam K Kirchhoff wrote: Hmmm... Well, line 592 of scene.cpp (in glaxium 0.5, just downloaded from the website) seems to be: glEnable(GL_TEXTURE_2D); Line 586, though, makes reference to GL_DOT3_RGB_EXT. I've made the change there. Now, with the unpatched driver and the patched game, the results look exactly look they did with the patched driver and the unpatched game! I believe that we may have discovered one of the subtle differences between the R100 family of chips and the R200 family. On the R100, when DOT3 bumpmapping is selected the driver has to manually select the implicit 4X multiplier required by the ARB EXT specs. It seems that when the R200 this is not needed. The unpatched driver programs the chip to do DOT3 and a 4X scale. It seems that the result is a 4X + 4X scale, or a 16X scale. The result is that all fragments end up saturated to white. If this theory is correct, then this patch should fix it. I'm crossing my fingers... Well, it looks better than your last patch, but still not right, and worse than it does with the unpatched driver. http://memory.visualtech.com/glaxium.png Adam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New ATI FireGL drivers announced
Hi
Does this driver works with Powered By Ati cards??
The previus driver didnt work giving the error that is not a Build By Ati
card. Here in my City is impossible to find a BBA ATI, so i had to buy a
Powercolor (powered by) ATI 8500. The nvidia binary only driver works with
any brand of card that has an nvidia chip. I hope this driver or the next
will work with powered by cards. The only reason i bought an Ati 8500 was
that the weather channel paid for the opensource DRI driver, or i would
just buy an nvidia card instead, because thier driver supports all the
cards.
Nice to see ATI support for Linux :-)
Alejandro Arrieta Rios
Computer Science Student
UTFSM, Valparaiso, Chile
On Thu, 21 Nov 2002, Alexander Stohr wrote:
Hello,
i know that DRI is targeting open source development,
but i know myselves that for a developer there can
always be a need for a 2nd source driver reference.
There are several other reasons why an alternate
Linux driver might be of interest for the audience.
So please excuse me for posting this information to your lists.
So this passed the news wires today:
ATI drives graphics performance for Linux users with new unified driver
http://mirror.ati.com/companyinfo/press/2002/4574.html
The drivers can now be downloaded for free at www.ati.com
(see e.g. Linux FireGL 8800).
The drivers should run on Linux/x86 with glibc 2.2,
some common kernel modules do come precompiled and
a build environment for gcc2.96 and gcc3.2 is included,
thus making that drivers compatible with
e.g. RedHat(R) Linux(R)/x86 8.0 or 7.3 versions.
Supported cards should be (list might not be complete):
- ATI Radeon 8500 {/DV/LE}, 9000 {/PRO}, 9500 {/PRO}, 9700 {/PRO} - Built
by ATI
- ATI FireGL 8700, 8800, E1, X1, Z1/X1-128MB (just announced for retail),
Mobility
I installed that drivers and tested them a tiny little bit.
Simple applications like glxgears do perform very well and
they are working quite nice for ut2003_demo (S3TC!), Maya and Houdini.
My impression is that things like Quake, Chromium or Blender should work.
I just had a few minutes of a one-man tournament session this noon.
I tried XVideo support and it showed that the CPU usage of TOP
was higher than that of the video player application. Features
that you will on FireGL boards are Overlays and PBuffer rendering
support.
Please excuse me again, i furthert want to give a few of the end
users an alternative to the dri drivers, which are often only
really useable if you do have downloaded som 60 MB of CVS sources
and built whole XF86 with a not totally trivial process.
Let me express that i do _not_ object to any of the DRI-Devel works.
DRI did great job and it resolves for situations where ATI
cant provide solutions as of today and possibly long term.
Just saying embedded Radeon chipsets, ATI chipsets on BSD,
old ATI chipsets prior to the R200 and further any sort of
experimental and custom extensions to the DRI open source
drivers.
Let's hope, no one does mind this mailing.
-Alex.
PS: not speaking for my employer, just documenting things that
are already publicly availabel.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Re: [Dri-devel] New ATI FireGL drivers announced
I only think it works with built by ati cards, howeverI don't have a
built by ati card and I was able to get it to work, but you risk
damaging your card. What you have to do is get a built by ATI Bios and
burn it to your card, and then you got yourself a Power By ATI Card that
says it was built by ati so the drivers will work. If you want more
information on how to do this visit http://www.rage3d.com/...Join the
forums and ask someone..I am sure they will be more than happy to help,
it has been so long since I have done it that I have forgotten.
Scott
Alejandro Arrieta wrote:
Hi
Does this driver works with Powered By Ati cards??
The previus driver didnt work giving the error that is not a Build By Ati
card. Here in my City is impossible to find a BBA ATI, so i had to buy a
Powercolor (powered by) ATI 8500. The nvidia binary only driver works with
any brand of card that has an nvidia chip. I hope this driver or the next
will work with powered by cards. The only reason i bought an Ati 8500 was
that the weather channel paid for the opensource DRI driver, or i would
just buy an nvidia card instead, because thier driver supports all the
cards.
Nice to see ATI support for Linux :-)
Alejandro Arrieta Rios
Computer Science Student
UTFSM, Valparaiso, Chile
On Thu, 21 Nov 2002, Alexander Stohr wrote:
Hello,
i know that DRI is targeting open source development,
but i know myselves that for a developer there can
always be a need for a 2nd source driver reference.
There are several other reasons why an alternate
Linux driver might be of interest for the audience.
So please excuse me for posting this information to your lists.
So this passed the news wires today:
ATI drives graphics performance for Linux users with new unified driver
http://mirror.ati.com/companyinfo/press/2002/4574.html
The drivers can now be downloaded for free at www.ati.com
(see e.g. Linux FireGL 8800).
The drivers should run on Linux/x86 with glibc 2.2,
some common kernel modules do come precompiled and
a build environment for gcc2.96 and gcc3.2 is included,
thus making that drivers compatible with
e.g. RedHat(R) Linux(R)/x86 8.0 or 7.3 versions.
Supported cards should be (list might not be complete):
- ATI Radeon 8500 {/DV/LE}, 9000 {/PRO}, 9500 {/PRO}, 9700 {/PRO} - Built
by ATI
- ATI FireGL 8700, 8800, E1, X1, Z1/X1-128MB (just announced for retail),
Mobility
I installed that drivers and tested them a tiny little bit.
Simple applications like glxgears do perform very well and
they are working quite nice for ut2003_demo (S3TC!), Maya and Houdini.
My impression is that things like Quake, Chromium or Blender should work.
I just had a few minutes of a one-man tournament session this noon.
I tried XVideo support and it showed that the CPU usage of TOP
was higher than that of the video player application. Features
that you will on FireGL boards are Overlays and PBuffer rendering
support.
Please excuse me again, i furthert want to give a few of the end
users an alternative to the dri drivers, which are often only
really useable if you do have downloaded som 60 MB of CVS sources
and built whole XF86 with a not totally trivial process.
Let me express that i do _not_ object to any of the DRI-Devel works.
DRI did great job and it resolves for situations where ATI
cant provide solutions as of today and possibly long term.
Just saying embedded Radeon chipsets, ATI chipsets on BSD,
old ATI chipsets prior to the R200 and further any sort of
experimental and custom extensions to the DRI open source
drivers.
Let's hope, no one does mind this mailing.
-Alex.
PS: not speaking for my employer, just documenting things that
are already publicly availabel.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-users
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon 7500 (QW, AIW) slowness
Hello, I was quite surprised to see that my OpenGL application ran about 3x slower with the latest DRI drivers (last week's CVS) and my brand new Radeon 7500 AIW card. I think I tracked it down to glDrawBuffer(GL_NONE) when drawing to Z buffer is enabled. I guess this is a software fallback case; maybe the status page at http://dri.sourceforge.net/doc/feature_table.html#R100 needs to be updated? What is the priority of this functionality getting hardware acceleration? Regards, Pontus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Private DMA and ring buffers on DDX for mach64
Leif, Attached is the patch to allocate private DMA and ring buffers on the DDX - the DDX part only. I'll now focus on the DRM part. The code compiles but I'll only be able to test it when the changes on DRM are also done. I would appreciate if you used those falcon eyes of yours and see if you notice any mistake! ;-) My time is still rather limited. If you want I can stop the snapshots and commit this to CVS so that we both can hack at this. Regards, José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 14.9 MILLION EMAIL ADDRESSES...PLUS $2,000 WORTH OF FREE EMAIL MARKETING SOFTWARE!
WOULD YOU LIKE TO HAVE YOUR MESSAGE SEEN BY OVER 14.9 MILLION TARGETED PROSPECTS DAILY? Below contains all the information you will ever need to market your product or service on the Internet. If you have a product, service, or message that you would like to get out to Thousands, Hundreds of Thousands, or even Millions of people, you have several options. Traditional methods include print advertising, direct mail, radio, and television advertising. They are all effective, but they all have two catches: They're EXPENSIVE and TIME CONSUMING. Not only that, you only get ONE SHOT at making your message heard by the right people. Also, Internet Search Engine Submissions, Classified Ads, Newsgroup Postings simply DO NOT WORK effectively. Now this has all changed! Thanks to the top programmers in the world and their NEW EMAIL TECHNOLOGY, You can send millions of email messages daily for FREE...Without getting terminated from your current Internet connection! It's very simple to do and you can be increasing your sales within minutes of installing this new extraordinary software! Besides...It's the only real way to advertise on the Internet that works...Period! WE WILL SUPPLY YOU WITH OVER 14.8 MILLION OPT-IN EMAIL ADDRESSES TO GET STARTED RIGHT AWAY! PLUS FREE EMAIL ADDRESS DOWNLOADS FOR LIFE! ALSO, YOU WILL RECEIVE $2,000 WORTH OF EMAIL MARKETING SOFTWARE FREE! Including.. BROADCAST EMAIL SENDING SOFTWARE...(send millions of email advertisements daily with a few clicks of your mouse, without getting your ISP trerminated. We used the same software to send you this email) EMAIL EXTRACTION SOFTWARE...(retrieve new targeted email addresses daily. Hundreds of thousands of them) LIST MANAGEMENT SOFTWARE...(keep your lists clean, opt-in and manage all your remove requests, leads, sales etc...) and much...much more! Hurry...This extraordinary offer ends at midnight tonight! To find out more information, Do not respond by email. Instead, visit our web site at: http://www.cybernetemail.bz __ Want to be removed from our email list? You were sent this email because you used our Opt-in service. We hope you enjoy reading our messages. However, if you'd rather not receive future e-mails from us in the, Go to our remove page at http://www.cybernetemail.bz/remove.htm ___ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Private DMA and ring buffers on DDX for mach64
On Thu, 21 Nov 2002, [iso-8859-15] José Fonseca wrote: Leif, Attached is the patch to allocate private DMA and ring buffers on the DDX - the DDX part only. I'll now focus on the DRM part. I didn't get the attachment, could you send it again? The code compiles but I'll only be able to test it when the changes on DRM are also done. I would appreciate if you used those falcon eyes of yours and see if you notice any mistake! ;-) My time is still rather limited. If you want I can stop the snapshots and commit this to CVS so that we both can hack at this. Sure, that works for me. BTW, I was looking at the code in glint_dri.c and it looks like it is incorrectly using drmAddBufs to allocate the page table. The last parameter is actually agp_start and is only used by DRM(addbufs_[agp,sg]). Passing DRM_RESTRICTED has no effect since that parameter isn't used for DRM(addbufs_pci). The flags parameter (the fourth parameter) is only to specify AGP, SG, or PCI. So I think there's actually a potential security bug in the glint driver. In fact, afaict, the only thing that prevents the page table from being handed out as a DMA buffer by drmDMA is the fact that it's a different order (8K vs. 4K for the DMA buffers), and the gamma Mesa client no longer passes the DRM_DMA_LARGER_OK flag (it's commented out). From what I can tell, all buffers allocated with drmAddBufs go on the dev-dma-buflist, and all of these buffers are mapped by drmMapBufs, so they are all client accesible even if none of the DRM ioctls return the index of a private buffer to a client. I think what we need is a way to have multiple buffer lists and map (or not map) each list separately (maybe with a flag to map as shared for client DMA buffers and private for the X server indirect buffers?). As far as the descriptor ring buffer goes, for the PCI case it might make sense to have a DRM wrapper around pci_alloc_consistent for general-purpose PCI DMA memory for drivers to use for things like page tables and ring buffers when agp/pcigart aren't used, since we don't need the extra bookeeping fields in drm_buf_t and drmAddMap only works for AGP or scatter-gather PCI mem. What do you think? -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New ATI FireGL drivers announced
On Thu, 21 Nov 2002, Alexander Stohr wrote: I tried XVideo support and it showed that the CPU usage of TOP was higher than that of the video player application. Features that you will on FireGL boards are Overlays and PBuffer rendering support. This is getting off-topic but, FYI, X-Video does not seem to be supported at all, in fact: $ X-Video Extension version 2.2 screen #0 no adaptors present mplayer complains about lack of xv as well. Adam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New ATI FireGL drivers announced
Never mind. I'm wrong. Adam On Thu, 21 Nov 2002, Adam K Kirchhoff wrote: On Thu, 21 Nov 2002, Alexander Stohr wrote: I tried XVideo support and it showed that the CPU usage of TOP was higher than that of the video player application. Features that you will on FireGL boards are Overlays and PBuffer rendering support. This is getting off-topic but, FYI, X-Video does not seem to be supported at all, in fact: $ X-Video Extension version 2.2 screen #0 no adaptors present mplayer complains about lack of xv as well. Adam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Private DMA and ring buffers on DDX for mach64
On Thu, Nov 21, 2002 at 05:41:55PM -0500, Leif Delgass wrote: On Thu, 21 Nov 2002, [iso-8859-15] José Fonseca wrote: Leif, Attached is the patch to allocate private DMA and ring buffers on the DDX - the DDX part only. I'll now focus on the DRM part. I didn't get the attachment, could you send it again? Oops.. I always forget to actually attach the attachments!! The code compiles but I'll only be able to test it when the changes on DRM are also done. I would appreciate if you used those falcon eyes of yours and see if you notice any mistake! ;-) My time is still rather limited. If you want I can stop the snapshots and commit this to CVS so that we both can hack at this. Sure, that works for me. BTW, I was looking at the code in glint_dri.c and it looks like it is incorrectly using drmAddBufs to allocate the page table. The last No. That's actually the way to do it - at least in the current driver model - with AGP, the DMA buffers are taken directly from the memory given by drmAgpAlloc, while with PCI it's done implicitly with the call to drmAddBufs. parameter is actually agp_start and is only used by DRM(addbufs_[agp,sg]). Passing DRM_RESTRICTED has no effect since that parameter isn't used for DRM(addbufs_pci). The flags parameter (the fourth parameter) is only to specify AGP, SG, or PCI. So I think there's actually a potential security bug in the glint driver. In fact, afaict, the only thing that prevents I haven't looked to deep in the DRM API but it appears that you may be right, assuming that there is a security risk for Glint in exposing the pgt. the page table from being handed out as a DMA buffer by drmDMA is the fact that it's a different order (8K vs. 4K for the DMA buffers), and the gamma Mesa client no longer passes the DRM_DMA_LARGER_OK flag (it's commented out). From what I can tell, all buffers allocated with drmAddBufs go on the dev-dma-buflist, and all of these buffers are mapped by drmMapBufs, so they are all client accesible even if none of the DRM ioctls return the index of a private buffer to a client. I think what we need is a way to have multiple buffer lists and map (or not map) each list separately (maybe with a flag to map as shared for client DMA buffers and private for the X server indirect buffers?). I don't know. If we need to make changes to the DRM API then I prefer go all the way and do something that allows to cleanly seperate mapping from allocation via different API calls. As far as the descriptor ring buffer goes, for the PCI case it might make sense to have a DRM wrapper around pci_alloc_consistent for general-purpose PCI DMA memory for drivers to use for things like page tables and ring buffers when agp/pcigart aren't used, since we don't need the extra bookeeping fields in drm_buf_t and drmAddMap only works for AGP or scatter-gather PCI mem. What do you think? I undoubtly agree that we should use pci_alloc_* inside the DRM API, either replacing the allocation code inside DRM(addbufs_pci), or - much cleaner - do it on a PCI dedicated API call (e.g., drmPciAlloc, to be the PCI counterpart of drmAgpAlloc). José Fonseca mach64-private-ring.diff.bz2 Description: Binary data
