Test.
Test of email delivery from legacy list. -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
dri-devel/user: List(s) SF.N
Hello dri-devel/user, It looks like these lists are no-longer in use, except for some bug tracker tickets there is vary little traffic on these lists. The lists currently being used are here: http://lists.freedesktop.org/mailman/listinfo/dri-devel http://lists.freedesktop.org/mailman/listinfo/dri-users I'm just informing you of this because I've just discovered it for myself and I wanted to make you aware that you may still be a subscriber. I'm also testing to see if the new lists will receive this message. -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: *Done* Working GTA3, sometimes.
--- Mike Mestnik [EMAIL PROTECTED] wrote: The game always(mostly) loads under cedega 5.1.1, but I only get a working setup now and then. Mostly the screen is black and no-one seams to know how to test what 'black' means. I am able to play some times and the game workes just fine! Here is my saved game folder... -rw-r--r-- 1 cheako cheako 201820 Mar 10 22:49 GTA3sf3.b -rw-r--r-- 1 cheako cheako 201820 Mar 10 22:49 GTA3sf2.b -rw-r--r-- 1 cheako cheako 201820 Mar 10 22:49 GTA3sf1.b -rw-r--r-- 1 cheako cheako 201820 Jun 23 19:34 GTA3sf8.b The Mar 10 games are the ones that pointed me towrds 5.1.1. I'm using reacent video drivers, from DRI snapshot. common-20060311-linux.i386 r300-20060306-linux.i386 I seam to get some luck removing gta3.set from the saved game folder, but with how unstable everything is luck is all I get. I'll try and compare a working run with a failed run, but what would I compare? The screen is black for the title page and the menu. Moves are only slow and are visable with sound. I hit space twice as cedega recomends to skip the slow movies. Even the cedega memory-usage overlay is not shown. Re: Working GTA3, sometimes. ATI/r300 by cheako on Sunday June 25, 2006 @ 7:43PMnew. I got it!! I had to hack the binary file gta3.set. dd if=/dev/zero of=gta3.set bs=1652 count=1 After that the game would start, but you can not play. You need to go into the Control and Audio pages and reset them to default. Do NOT set Display options to default, but instead only adjust(I max) the distance setting. I also turn on subtitles. Then that game loads and runs fine. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 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
Working GTA3, sometimes.
The game always(mostly) loads under cedega 5.1.1, but I only get a working setup now and then. Mostly the screen is black and no-one seams to know how to test what 'black' means. I am able to play some times and the game workes just fine! Here is my saved game folder... -rw-r--r-- 1 cheako cheako 201820 Mar 10 22:49 GTA3sf3.b -rw-r--r-- 1 cheako cheako 201820 Mar 10 22:49 GTA3sf2.b -rw-r--r-- 1 cheako cheako 201820 Mar 10 22:49 GTA3sf1.b -rw-r--r-- 1 cheako cheako 201820 Jun 23 19:34 GTA3sf8.b The Mar 10 games are the ones that pointed me towrds 5.1.1. I'm using reacent video drivers, from DRI snapshot. common-20060311-linux.i386 r300-20060306-linux.i386 I seam to get some luck removing gta3.set from the saved game folder, but with how unstable everything is luck is all I get. I'll try and compare a working run with a failed run, but what would I compare? The screen is black for the title page and the menu. Moves are only slow and are visable with sound. I hit space twice as cedega recomends to skip the slow movies. Even the cedega memory-usage overlay is not shown. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 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: *Done* R300: GL_INVALID_ENUM in glStencilFunc.
--- Mike Mestnik [EMAIL PROTECTED] wrote: --- Mike Mestnik [EMAIL PROTECTED] wrote: --- Mike Mestnik [EMAIL PROTECTED] wrote: I keep trying to send this :( http://www.transgaming.com/showthread.php?forum=1262thread=61671msg=61671 LIBGL_ALWAYS_INDIRECT works. Grand Theft Auto III, in game black screen. - Request for support (open) more help needed by cheako on Tuesday June 13, 2006 @ 10:20PM. Cedega Version: 5.1.4 Distribution: Debian Video Card: ATI X600. Driver: DRI r300 Sound Card: Black Sheep - onboard. Driver: ALSA Game Title: Grand Theft Auto III 3 three Using LIBGL_ALWAYS_INDIRECT fixes this problem. If any one else reports it this could be a bug in the r300 driver. I was playing GTA3 and then I don't know what I did, but now after the intro movies(hit space twice!!) all I get is a black screen. I'm able to start the game and even drive around blindly with the cops after me. The speed is fast and I'm sure I get hardware rendering... libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so drmOpenByBusid: Searching for BusID pci::02:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: drmOpenMinor returns 14 drmOpenByBusid: drmGetBusid reports pci::02:00.0 EOF Re: Grand Theft Auto III, in game black screen. by cheako on Tuesday June 13, 2006 @ 10:48PM. Ohh, wait... This is with MESA_DEBUG. Mesa: User error: GL_INVALID_ENUM in glStencilFunc I don't get this with LIBGL_ALWAYS_INDIRECT, a goggle says that this Re: Grand Theft Auto III, in game black screen. by ovek on Tuesday June 20, 2006 @ 4:07AMnew. That is normal. GTA3 initially sets an invalid stencil operation (zero), which Cedega converts into an invalid enum (zero) when converting it into a glStencilFunc call, and Mesa doesn't like it. Since stenciling is also disabled, this is not a problem. The game does set a valid stencil operation when it actually needs stenciling. The reason you don't see the message when you use LIBGL_ALWAYS_INDIRECT is because when doing indirect rendering, you no longer use Mesa client side. The server side Mesa, running inside the X server, can neither see your environment variables nor output to your terminal. I got some more news on this. I can once again use software rendering to play this game. r300 is still not working. I don't think this is the problem, but no harm in posting it. File r300_render.c function r300Fallback line 784 fallback:ctx-RenderMode != GL_RENDER What am I left with, would a register dump help? I will keep testing, but it's tempting to play games that work. Diablo II with internal SW rendering. Warcraft III, with the r300 drivers. Quake3, with the Urban Terror mod. GTA-III, with Cedega 5.1.1(and not 5.2 or anything pre 5.1) is for not drawing things. How do I know if this is emitted by the app, cedega, or mesa? -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300: GL_INVALID_ENUM in glStencilFunc.
--- Mike Mestnik [EMAIL PROTECTED] wrote: --- Mike Mestnik [EMAIL PROTECTED] wrote: I keep trying to send this :( http://www.transgaming.com/showthread.php?forum=1262thread=61671msg=61671 LIBGL_ALWAYS_INDIRECT works. Grand Theft Auto III, in game black screen. - Request for support (open) more help needed by cheako on Tuesday June 13, 2006 @ 10:20PM. Cedega Version: 5.1.4 Distribution: Debian Video Card: ATI X600. Driver: DRI r300 Sound Card: Black Sheep - onboard. Driver: ALSA Game Title: Grand Theft Auto III 3 three Using LIBGL_ALWAYS_INDIRECT fixes this problem. If any one else reports it this could be a bug in the r300 driver. I was playing GTA3 and then I don't know what I did, but now after the intro movies(hit space twice!!) all I get is a black screen. I'm able to start the game and even drive around blindly with the cops after me. The speed is fast and I'm sure I get hardware rendering... libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so drmOpenByBusid: Searching for BusID pci::02:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: drmOpenMinor returns 14 drmOpenByBusid: drmGetBusid reports pci::02:00.0 EOF Re: Grand Theft Auto III, in game black screen. by cheako on Tuesday June 13, 2006 @ 10:48PM. Ohh, wait... This is with MESA_DEBUG. Mesa: User error: GL_INVALID_ENUM in glStencilFunc I don't get this with LIBGL_ALWAYS_INDIRECT, a goggle says that this Re: Grand Theft Auto III, in game black screen. by ovek on Tuesday June 20, 2006 @ 4:07AMnew. That is normal. GTA3 initially sets an invalid stencil operation (zero), which Cedega converts into an invalid enum (zero) when converting it into a glStencilFunc call, and Mesa doesn't like it. Since stenciling is also disabled, this is not a problem. The game does set a valid stencil operation when it actually needs stenciling. The reason you don't see the message when you use LIBGL_ALWAYS_INDIRECT is because when doing indirect rendering, you no longer use Mesa client side. The server side Mesa, running inside the X server, can neither see your environment variables nor output to your terminal. I got some more news on this. I can once again use software rendering to play this game. r300 is still not working. I don't think this is the problem, but no harm in posting it. File r300_render.c function r300Fallback line 784 fallback:ctx-RenderMode != GL_RENDER What am I left with, would a register dump help? I will keep testing, but it's tempting to play games that work. Diablo II with internal SW rendering. Warcraft III, with the r300 drivers. Quake3, with the Urban Terror mod. is for not drawing things. How do I know if this is emitted by the app, cedega, or mesa? -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300: GL_INVALID_ENUM in glStencilFunc.
--- Ian Romanick [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick wrote: Mike Mestnik wrote: How do I prove that? I'm thinking they might try and say that a software mesa path is calling this, I'd assume that internally you would call something like _glStencilFunc. My other problem is that if the error is caught, why is the screen all black? What would be the next step in tracking this down be? Figure out what value is being passed to glStencilFunc. Try applying the attached patch. That will print the value of the stencil function to the error message that you're already getting. I don't know why the patch file was empty. Let's try again... I got it from CVS. I have a problem with my new audio(spdif) setup that causes some other problems now. I'll get back to you if/when I can reproduce this error. What I hate the most is that I was playing this game until I upgraded trying to get doom3 working. At that time I was only using snapshots. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300: GL_INVALID_ENUM in glStencilFunc.
--- Mike Mestnik [EMAIL PROTECTED] wrote: I keep trying to send this :( http://www.transgaming.com/showthread.php?forum=1262thread=61671msg=61671 LIBGL_ALWAYS_INDIRECT works. Grand Theft Auto III, in game black screen. - Request for support (open) more help needed by cheako on Tuesday June 13, 2006 @ 10:20PM. Cedega Version: 5.1.4 Distribution: Debian Video Card: ATI X600. Driver: DRI r300 Sound Card: Black Sheep - onboard. Driver: ALSA Game Title: Grand Theft Auto III 3 three Using LIBGL_ALWAYS_INDIRECT fixes this problem. If any one else reports it this could be a bug in the r300 driver. I was playing GTA3 and then I don't know what I did, but now after the intro movies(hit space twice!!) all I get is a black screen. I'm able to start the game and even drive around blindly with the cops after me. The speed is fast and I'm sure I get hardware rendering... libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so drmOpenByBusid: Searching for BusID pci::02:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: drmOpenMinor returns 14 drmOpenByBusid: drmGetBusid reports pci::02:00.0 EOF Re: Grand Theft Auto III, in game black screen. by cheako on Tuesday June 13, 2006 @ 10:48PM. Ohh, wait... This is with MESA_DEBUG. Mesa: User error: GL_INVALID_ENUM in glStencilFunc I don't get this with LIBGL_ALWAYS_INDIRECT, a goggle says that this Re: Grand Theft Auto III, in game black screen. by ovek on Tuesday June 20, 2006 @ 4:07AMnew. That is normal. GTA3 initially sets an invalid stencil operation (zero), which Cedega converts into an invalid enum (zero) when converting it into a glStencilFunc call, and Mesa doesn't like it. Since stenciling is also disabled, this is not a problem. The game does set a valid stencil operation when it actually needs stenciling. The reason you don't see the message when you use LIBGL_ALWAYS_INDIRECT is because when doing indirect rendering, you no longer use Mesa client side. The server side Mesa, running inside the X server, can neither see your environment variables nor output to your terminal. is for not drawing things. How do I know if this is emitted by the app, cedega, or mesa? -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300: GL_INVALID_ENUM in glStencilFunc.
On Mon, Jun 19, 2006 at 08:01:09AM -0600, Brian Paul wrote: Mike Mestnik wrote: I keep trying to send this :( http://www.transgaming.com/showthread.php?forum=1262thread=61671msg=61671 LIBGL_ALWAYS_INDIRECT works. Grand Theft Auto III, in game black screen. - Request for support (open) more help needed by cheako on Tuesday June 13, 2006 @ 10:20PM. Cedega Version: 5.1.4 Distribution: Debian Video Card: ATI X600. Driver: DRI r300 Sound Card: Black Sheep - onboard. Driver: ALSA Game Title: Grand Theft Auto III 3 three Using LIBGL_ALWAYS_INDIRECT fixes this problem. If any one else reports it this could be a bug in the r300 driver. I was playing GTA3 and then I don't know what I did, but now after the intro movies(hit space twice!!) all I get is a black screen. I'm able to start the game and even drive around blindly with the cops after me. The speed is fast and I'm sure I get hardware rendering... libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so drmOpenByBusid: Searching for BusID pci::02:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: drmOpenMinor returns 14 drmOpenByBusid: drmGetBusid reports pci::02:00.0 EOF Re: Grand Theft Auto III, in game black screen. by cheako on Tuesday June 13, 2006 @ 10:48PM. Ohh, wait... This is with MESA_DEBUG. Mesa: User error: GL_INVALID_ENUM in glStencilFunc I don't get this with LIBGL_ALWAYS_INDIRECT, a goggle says that this is for not drawing things. How do I know if this is emitted by the app, cedega, or mesa? It's emitted by Mesa when the application makes an invalid API call. -Brian How do I prove that? I'm thinking they might try and say that a software mesa path is calling this, I'd assume that internally you would call something like _glStencilFunc. My other problem is that if the error is caught, why is the screen all black? What would be the next step in tracking this down be? -- / * Mike Mestnik: Junior Admin 612-395-8932 * * [EMAIL PROTECTED] VISI/Digital North * / Alt address: [EMAIL PROTECTED] -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R300: GL_INVALID_ENUM in glStencilFunc.
I keep trying to send this :( http://www.transgaming.com/showthread.php?forum=1262thread=61671msg=61671 LIBGL_ALWAYS_INDIRECT works. Grand Theft Auto III, in game black screen. - Request for support (open) more help needed by cheako on Tuesday June 13, 2006 @ 10:20PM. Cedega Version: 5.1.4 Distribution: Debian Video Card: ATI X600. Driver: DRI r300 Sound Card: Black Sheep - onboard. Driver: ALSA Game Title: Grand Theft Auto III 3 three Using LIBGL_ALWAYS_INDIRECT fixes this problem. If any one else reports it this could be a bug in the r300 driver. I was playing GTA3 and then I don't know what I did, but now after the intro movies(hit space twice!!) all I get is a black screen. I'm able to start the game and even drive around blindly with the cops after me. The speed is fast and I'm sure I get hardware rendering... libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so drmOpenByBusid: Searching for BusID pci::02:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: drmOpenMinor returns 14 drmOpenByBusid: drmGetBusid reports pci::02:00.0 EOF Re: Grand Theft Auto III, in game black screen. by cheako on Tuesday June 13, 2006 @ 10:48PM. Ohh, wait... This is with MESA_DEBUG. Mesa: User error: GL_INVALID_ENUM in glStencilFunc I don't get this with LIBGL_ALWAYS_INDIRECT, a goggle says that this is for not drawing things. How do I know if this is emitted by the app, cedega, or mesa? -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libglx requires new symbol in loader (Was: problem with binary dri snapshots)
--- Felix Kühling [EMAIL PROTECTED] wrote: It looks like adding indirect acceleration added a new function to the loader that is used by libglx.so. So the new libglx won't work with older Xservers and I will have to build a new Xserver binary for snapshots/extras or add the Xserver to the snapshots. Yay! I came up with two workable solutions for this problem. The first one can be implemented in multiple ways. Make this function available as/in a module. I understand that this is part of the loader, but it should not be needed to boot-strap itself. The second implementation is to put this function in libglx.so, where it is used. My other solution is to include an xorg-additions.c into the snapshots that can be built and then linked against the installed xorg binary. This would need a configure script that detects what symbols are missing . Should not be too hard. I would gladly put forth the effort to bring any solution to life, I just would like to know what will/will-not be accepted. The problem with that is that the default ModulePath, RgbPath etc. I build with will only work with either one of Xorg 6.9 or 7.0, but not both. Hmm ... testing the latest and greatest stuff is getting messier. Regards, Felix Am Donnerstag, den 23.03.2006, 16:34 +0100 schrieb Michal Suchanek: Hello I tried installing the dri snapshots common-2006032[12]-linux.i386 with r200-2006032[12]-linux.i386, and I get undefined symbol in libglx.so. After reinstalling xorg-server 1.0.2 the problem goes away but it is because the library is overwritten with the older version. Using the X server and modules from http://dri.freedesktop.org/wiki/Download does not help either. Attaching the X server output. I do not see the error in the /var/log/X* files. Thanks Michal -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- 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
Re: libglx requires new symbol in loader.
--- Mike Mestnik [EMAIL PROTECTED] wrote: --- Felix K�hling [EMAIL PROTECTED] wrote: It looks like adding indirect acceleration added a new function to the loader that is used by libglx.so. So the new libglx won't work with older Xservers and I will have to build a new Xserver binary for snapshots/extras or add the Xserver to the snapshots. Yay! I came up with two workable solutions for this problem. The first one can be implemented in multiple ways. Make this function available as/in a module. I understand that this is part of the loader, but it should not be needed to boot-strap itself. The second implementation is to put this function in libglx.so, where it is used. I have a source file that can build a .o, so now all I have to do is link it with something. Build instructions are currently: replace loadmod.c in an xorg tree with this one and make loadmod.o. Here is a dependancy list for thoes interested. LoadSubModuleLocal Static marked with '*': * doLoadModule * InitPatterns * LoaderGetCanonicalName * InitPathList * FindModule * CheckVersion * FreePathList * FreePatterns * PatternPtr * stdPatterns * PatternRec * defaultPathList * FreeStringList * InitSubdirs * FreeSubdirs * stdSubdirs Unresolved: U AddSibling U ErrorF U FatalError U LoaderGetOS U LoaderOpen U LoaderOptions U LoaderSymbol U LoaderVersionInfo U NewModuleDesc U UnloadModule U Xalloc U Xfree U Xstrdup U __xstat U regcomp U regerror U regexec U snprintf U sprintf U strcat U strchr U strcmp U strcpy U strlen U strncpy U strrchr U strstr U xf86ErrorF U xf86ErrorFVerb U xf86Msg U xf86MsgVerb My other solution is to include an xorg-additions.c into the snapshots that can be built and then linked against the installed xorg binary. This would need a configure script that detects what symbols are missing . Should not be too hard. I missed Jeopardy last night... What is an absolute file. Dose some one know the answer, specificaly how can I introduce(link in) more object data? I would gladly put forth the effort to bring any solution to life, I just would like to know what will/will-not be accepted. The problem with that is that the default ModulePath, RgbPath etc. I build with will only work with either one of Xorg 6.9 or 7.0, but not both. Hmm ... testing the latest and greatest stuff is getting messier. Regards, Felix Am Donnerstag, den 23.03.2006, 16:34 +0100 schrieb Michal Suchanek: Hello I tried installing the dri snapshots common-2006032[12]-linux.i386 with r200-2006032[12]-linux.i386, and I get undefined symbol in libglx.so. After reinstalling xorg-server 1.0.2 the problem goes away but it is because the library is overwritten with the older version. Using the X server and modules from http://dri.freedesktop.org/wiki/Download does not help either. Attaching the X server output. I do not see the error in the /var/log/X* files. Thanks Michal -- | Felix K�hling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com /* $XFree86: xc/programs/Xserver/hw/xfree86/loader/loadmod.c,v 1.73 2003/11/03 05:11:51 tsi Exp $ */ /* * * Copyright 1995-1998 by Metro Link, Inc
Re: Status of X600 (5B62) support inquiry; bug 5413
--- Pawel Salek [EMAIL PROTECTED] wrote: Hi, (Q1) Can anybody summarize shortly what's the status of X600 (PCIID: 5B62, PCIE RV370 type card) support? I see its PCIID is still absent in shared-core/drm_pciids.txt in spite of few success reports: http://sourceforge.net/mailarchive/message.php?msg_id=14645441 (BSD) http://sourceforge.net/mailarchive/message.php?msg_id=14281693 (Linux) The latter message is related to https://bugs.freedesktop.org/show_bug.cgi?id=5413 - I am not sure whether the patch 4547 attached to this report (Q2) should be considered a cleanup or vital for the X600 support? Is it believed that this patch should make X600 work with linux? For what is worth, I tried just appending the id to shared-core/drm_pciids.txt and compiling it on the bleeding edge FC5t3 (after disabling module signing and replacing the kernel drm code by the one available in CVS freedesktop.org), and all I got was few drm messages: [drm] Initialized drm 1.0.1 20051102 [drm] Initialized radeon 1.23.0 20060225 on minor 0: [drm] Setting GART location based on old memory map [drm] Loading R300 Microcode [drm] writeback test succeeded in 1 usecs and a hang (the log messages were saved thanks to remote logging). Can anybody, please, answer Q1 and Q2, and comment on the hang? I would try the binary snapshots to make sure I build drm right but the snapshots obviously do not support this PCIID. Was working fine for me, until trying to use a newer snapshot. I still need to patch drm_pciids.txt and copy over the /scripts dir before ./install.sh Pawel --- 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=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- 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
Snapshots have stoped at r300-20060206.
There have been no new snapshots since the 6th. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 CVS move
--- Vladimir Dergachev [EMAIL PROTECTED] wrote: Hi all, Both R300 drm and Mesa code has been imported into main CVS repositories on freedesktop.org (drm and mesa3d correspondingly) Big thanks go to Eric Anholt :) While the CVS on r300.sf.net will remain open for anyone to experiment with, I would suggest that r300 developers get freedesktop.org accounts and access to DRM and Mesa3d CVS repositories. There are a lot of Wiki and web pages that have not been updated. It would be nice if more current data was provided without having to sift through mailing lists. Hello Every Body, I'm Back! This has several advantages: * your latest code is available for wider testing * there is no hassle of synchronizing Mesa, DRM and R300.sf.net source code * you work directly with the main repositories for DRM and Mesa. best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] VB lockup found and fixed
--- Nicolai Haehnle [EMAIL PROTECTED] wrote: On Friday 18 February 2005 16:03, Keith Whitwell wrote: Ben Skeggs wrote: I still have a 100% reproducable bug which I need to find the cause of, but time is once again a problem for me. If I move a window over the top of a glxgears window my machine locks up immediately, but sysrq still works fine. I just discovered (and should've checked before), that I can ssh in and successfuly kill glxgears, then X returns to normal. I can have a partially covered glxgears window and everything is fine, but as soon as the entire window (not incl. window decorations) is covered, it seems that the 2d driver is unable to update the screen. I think some of the other drivers do a 'sched_yeild()' or 'usleep(0)' in the zero cliprect case to get away from this sort of behaviour. Well, I can reproduce this bug and I tracked it down. There are a number of problems here, and they all have to do with DMA buffer accounting. The first (trivial) problem is that nr_released_bufs was never reset to 0. I've already fixed that in CVS. The real problem is that the following situation can occur when we have zero cliprects: 1. The command buffer contains a DISCARD command for a DMA buffer. 2. We simply drop that command buffer because there are no cliprects, i.e. nothing can be drawn. 3. As a consequence, DMA buffers aren't freed. 4. The rendering loop continues even though DMA buffers have been leaked, which eventually causes all DMA buffers to be exhausted, and this causes an infinite loop in r300RefillCurrentDmaRegion. The root cause is that we drop the command buffers with the DISCARD. I can see two possible solutions to this problem: 1. Wait until we have a cliprect again before submitting command buffers. 2. Submit command buffers even when we have no cliprects. The kernel module would basically ignore everything but the DISCARD commands. 3. Something else? I don't like option (1) because it somehow assumes that the user program only cares about OpenGL (and that's quite selfish). There are many use cases where it is plainly the incorrect thing to do: - A user running something like Quake in listenserver mode; if they switch away from Quake for some reason (incoming messages, whatever), the server will stop and eventuall all clients will timeout. There are acctualy more common reasons why video games NEED a renderer that dose not block or they should do all there rendering in another thread ?Doom3?. A video game typicaly lookes like this... Get user input/Network Input Process Draw/Play/Network Responce Loop If the Draw part above dose not return ASAP then user input and network pings will suffer grately! What I mean is the player knowes about a target(from a previous frame or sound) and he is stuck waiting 1/nth a second for the nFPS OpenGL driver to return. This is not the first time I have brought this up and I'm sad to see that the point still has not been visable, must be getting cliped by gethostbyname. - Imagine a chat application that uses some fancy 3D graphics for whatever reason (glitz, for example). Now this application may just be in the middle of drawing something when the user moves some other application above it. The end result will be that the applications essentially becomes locked up until it becomes visible again; in the mean time, the chat might time out and disconnect the user. So (1) clearly isn't a good solution. Option (2) is more correct, but it does seem a little bit hackish. Any better ideas? Perhaps tracking which buffers were discarded? That's not exactly beautiful either. cu, Nicolai Keith ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo --- 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: OpenGL apps causes frequent system locks
I'm using the new prebuilt debs that include an Xorg server and I get a hardlock just after mode swich, befour the desktop shows. There is no usefull debuging I have been able todo, exept to say commenting out the dri Xmod stopes the problem. 2005.01.26-2 from John Lightsey [EMAIL PROTECTED]. Untill now I thought it was just me and my r200. --- Geller Sandor [EMAIL PROTECTED] wrote: On Sun, 6 Feb 2005, Richard Stellingwerff wrote: On Sun, 06 Feb 2005 13:45:47 -0500, Michel Dänzer [EMAIL PROTECTED] wrote: Does it also happen without either or all of the options in the radeon device section? I just removed the AGPFastWrite and DynamicClocks options. The crashes still happen though. Looks like not only I have problems with the radeon driver. I update the X.org, drm, Mesa CVS once a week, but haven't found a working combination since 4-5 months... I don't intend to start a flame-war, but is there anybody who can use the r200 driver without X crashes? I'm testing X.org CVS regularly (almost on every weekend) with my RV280, with the latest linux 2.6 kernel. I checked out X.org on last Saturday, played with Descent3 for some minutes, it didn't crashed. Good. Restarted X, started Descent3 again, it crashed almost immediately, as expected :(( That's why I have a 'shutdown -r 5' in the background, when I test X.org CVS... Compiled Mesa CVS, installed the libraries and the driver, started D3. (Descent3 looks great, textures are visible, thanks to Eric Anholt's projected texture patch which is in Mesa CVS) The game crashed X in a few seconds. This was expected too :(( I tried out other OpenGL-based games, unfortunately, I can crash X with almost every game I have - it is only a matter of time. I tried setting color depth to 16 bit, changed the AGP to 1x in the system BIOS, none of these helped. Last time I used the 2.6.11-rc3 linux kernel, X.org CVS (updated on 20050205), Mesa CVS (20050205, linux-x86-dri target). I didn't built the drm module, I used the kernel's radeon drm module. I used to test the drm compiled from the CVS version, but I found out, that it is only a matter of time to crash the X server, so I skipped the drm CVS test. Of course the real tests will be these: 1. build and install everything from CVS, if the X server can be crashed, go to step 2, otherwise be happy :)) 2. use the X.org CVS version with the stock kernel's drm, if X still crashes, go to step 3. Otherwise use the X.org CVS, live without projected textures... 3. use the X.org and Mesa CVS versions. If X still crashes, then the bug can be in X.org or Mesa or in drm - I'm not able to trace down the problem. Unfortunately all 3 scenarios give the same result: X crashes. Is there any way I can help to track down the problem(s)? My machine doesn't have network connection, so I can use only scripts which run in the background. With expect and gdb maybe it is possible to get at least a backtrace from my non-local-interactive machine. Regards, Geller Sandor [EMAIL PROTECTED] --- 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 __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- 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 depth tiling questions.
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Jacek Rosik wrote: Hi, Dnia 28-01-2005, pi± o godzinie 16:27 +0100, Roland Scheidegger napisa³(a): Jacek Rosik wrote: Hi, I have some questions about r200 depth tiling. Generally I'm also interested in r100 tiling too, but currently i work on r200. First of all in functions r200_mba_z16|32 from r200_span.c frontPitch offset is used. Is it intentional or just because depthOffset is also the same? Maybe it should be depthOffset? Yes, I think depthPitch (you surely meant that, yes?) instead of frontPitch might be a good idea. I don't think there's a good reason to use frontPitch there, even though currently they are always the same. Yes, I meant depthPitch. They are the same but only for resolutions where width is multiple of 32. Depth pitch is rounded to be multiple of 32. Hmm... I think that is wrong since tile size seems to depend on fb depth and probably tiles on r100 also have different sizes. So this is correct only for r200 with 32bpp fb depth. Depth tiles on r200 are 32x16 or 64x16, depending on FB depth, right? Well, the span functions would indicate that. It doesn't quite match the experiences made when implementing hyperz, however (where the same number of tiles needed to be cleared regardless of 16 or 32bit z depth, and tile size more seemed to correspond to 4x4 microtiles and 8x2 macrotiles, thus a tile size of 32x8). I never really fully understood that however, something just doesn't fit. See th drm clear code for details. Thanks, I'll take a look at it. I don't quite follow third line before last? Can someone enlighten me? You mean the pitch 0x20 stuff? Yeah, looks strange. Looking at it, it seems like it ensures that each block line starts with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will have set that (for x 0-31) to 0, y 16-31 to 1 and so on. Seems to me like it might be related to how the ram is organized (e.g. something like ensuring it's on a different memory channel or different bank or whatnot). Yeah, I thought something similar. This is, btw, quite similarly strange to what Stephane needed on his rv100 to get the correct pixel address for color tiling, this one also tinkered with that 11th bit (see RadeonDoAdjustFrame). Generally if one could explain tiling a bit for me I would be grateful. What I'm trying to do is to is to modify depthOffset to be as close to top-left corner of viewport as possible and modify. I this possible with shared depth buffer. This means that each 3D window would have different depthOffset but pointing to the same shared buffer. I'm not sure if it's possible to do that with depthOffset (well maybe). There is however an interesting bit in RB3D_CNTL (R200_DEPTH_XZ_OFFEST_ENABLE, I guess XZ is a typo, just as is OFFEST?) and the corresponding (?) register (R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly invented for that... So this would mean that depth buffer can start at different x,y than color buffer? Can someone with the docs confirm that. Anyway I think I will experiment with it a little more and see what I'll get. Unfortunately I'll be quite busy in next weeks, but I hope I'll get back to it soon. BTW: I have working solution for color but I wonder if this will work with color tiling. Of course offset Would have to be aligned to the closest tile. Can You take a look at it? (It's missing some bits but generaly apps which don't use depth should work Unfortunately I don't think there are many ;). Attached is a patch. Any comments are welcome. I somehow missed this discussion the first time, but thankfully Alex pointed it out to me... Anyway... I've applied your patch, Jacek. It mostly works, but definitely has some issues: http://68.44.156.246/glforestfire.png http://68.44.156.246/glplanet.png This is what happens when I move the window to the lower right hand corner on a MergedFB setup running at 2560x1024. The OFFSETS get changed but then the output needs to be translated back into position. AMY ONE HAVE A FIX FOR THIS Also you seam tobe getting something I did not get. In my attempts the img moved to the boarder of the window, so that the cutoff was allways at a window boundry. This could mean there are some math problems in the patch your using. Adam --- 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
Re: Texture heap preference in driAllocateTexture
--- Felix Kühling [EMAIL PROTECTED] wrote: Am Montag, den 24.01.2005, 15:27 -0800 schrieb Mike Mestnik: --- Felix Khling [EMAIL PROTECTED] wrote: Am Montag, den 24.01.2005, 18:12 +0100 schrieb Roland Scheidegger: Felix Khling wrote: I intend to improve the heuristics that chooses the texture heap in driAllocateTexture. This may involve the texture size to allocate, the heap sizes and the amount of free space on each heap and maybe the ages of textures on each heap. I haven't thought too much about the details yet. If anyone has already put some thought into this I'd appreciate your input. IMHO, the ages of textures might be crucial to get a reasonable heuristic. I'm not sure how much of a performance hit (especially with agp 4x and the relatively slow savage chips) agp texturing has (if the cards in question only have slow, narrow ram interfaces it might actually even be faster), but I would think that in general it would be beneficial to try local memory first, but if no recently-not-accessed textures exist (though determining of the threshold what is recent enough might involve some black magic), just use the agp gart heap instead of throwing some local texture out. At least on the Savage4 with 4x AGP there is no major performance Is there a way to clock this performance? on all chips? If so this should be done by the DRM for the first fue runes of each size bracket, yes it's tax season. Not easily. You'd have to do some actual rendering with textures on I was thinking allong the lines of not doing any thing extra exept getting the time and comparing time stamps. I just can't see how this would work for something like a GPU/chip access. different heaps. In order to get meaningful numbers you'd have to do a lot of rendering (a few seconds in time) with each tex heap as texture source. This would be very hard to do in a driver-independent way. The My asumption was we woulden't need these numbers untill after was had been rendering since I was thinking about doing this system-wide. easiest way would probably be a hook in the driver. The easiest implementation of such a hook would be to return constants based on previous benchmarks. ;-) This dosen't take into account memory bus speeds and AGP brige vendor/product and settings. difference between local and AGP textures. However, the performance hit of texture uploads is really bad (could probably be improved a lot by This is too. With pipelined texture uploads this is hard to measure, because you're interested in throughput, not in latency. The Savage driver doesn't pipeline texture uploads, so it would be easier to measure, but you asked for something driver-independent, didn't you? I didn't think it would be independent, the hooks should reside in the text upload and *use* functions. What would be driver-independent is where, how and if the results are stored. Also, it's not at all clear to me how these two different performance values would influence the heap choice heuristics. Upload performance is Let's say heap one(A) is half a fast as head two(B). For every block(16 bytes?) in B that we swap out there should be 2 for A. Basicaly so that the time we spend swaping in each heap is the same, not the amount. easy to consider. But texture rendering performance is harder. Would you refuse to use the AGP heap because it's slower? Maybe in that case you'd This is where things get driver-specific. I don't realy think this of use unless text can be premoted and demoted. This type of performance may not need to be measured. want to disable the AGP heap altogether. optimizing the tiling functions). So my assumptions for an optimization will be that, if you have to start kicking textures, you want to balance kicks fairly (proportionally?) between texture heaps. I don't think the other criteria you suggest (such as texture size in relation to heap size) are really a good indicator where you'd want to place the texture (ok for that just-fits-local-heap big texture you might be better off usually with gart heap so all other textures fit into local memory, but OTOH maybe it's the only texture currently really accessed). I started thinking about some variation of round robin that would ensure Weighted by ?performance?, ?total heap size?, ?number of textures?, ?avg texture size?, ?avg|max age?. Then the textures in this heap should be unmaped by age. Weighted by heap size. In my eyes it makes sense that a heap with more data also has data uploaded and kicked at a higher rate. In the ideal case you'd observe the same behavior as if you arbitrarily split a single texture heap and measure the kick/upload rate on each part. yes, but if one heap is slower it's kick/upload rate won't be able to be as high per byte
Re: Texture heap preference in driAllocateTexture
--- Felix Kühling [EMAIL PROTECTED] wrote: Am Montag, den 24.01.2005, 18:12 +0100 schrieb Roland Scheidegger: Felix Kühling wrote: I intend to improve the heuristics that chooses the texture heap in driAllocateTexture. This may involve the texture size to allocate, the heap sizes and the amount of free space on each heap and maybe the ages of textures on each heap. I haven't thought too much about the details yet. If anyone has already put some thought into this I'd appreciate your input. IMHO, the ages of textures might be crucial to get a reasonable heuristic. I'm not sure how much of a performance hit (especially with agp 4x and the relatively slow savage chips) agp texturing has (if the cards in question only have slow, narrow ram interfaces it might actually even be faster), but I would think that in general it would be beneficial to try local memory first, but if no recently-not-accessed textures exist (though determining of the threshold what is recent enough might involve some black magic), just use the agp gart heap instead of throwing some local texture out. At least on the Savage4 with 4x AGP there is no major performance Is there a way to clock this performance? on all chips? If so this should be done by the DRM for the first fue runes of each size bracket, yes it's tax season. difference between local and AGP textures. However, the performance hit of texture uploads is really bad (could probably be improved a lot by This is too. optimizing the tiling functions). So my assumptions for an optimization will be that, if you have to start kicking textures, you want to balance kicks fairly (proportionally?) between texture heaps. I don't think the other criteria you suggest (such as texture size in relation to heap size) are really a good indicator where you'd want to place the texture (ok for that just-fits-local-heap big texture you might be better off usually with gart heap so all other textures fit into local memory, but OTOH maybe it's the only texture currently really accessed). I started thinking about some variation of round robin that would ensure Weighted by ?performance?, ?total heap size?, ?number of textures?, ?avg texture size?, ?avg|max age?. Then the textures in this heap should be unmaped by age. that each heap kicks an equal proportion of data on average over time. Weighted by performance. There is no need to force a slow heap to swap the smae as a faster one. This would avoid the black magic of age thresholds and the like and would allow new textures to replace old textures on all heaps, thus reducing texture trashing on the first heap. Texture trashing on faster heaps should be encouraged, providad there is nothing realy old on any other heap. Mike Roland -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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 __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com --- 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: Radeon and viewport size limits.
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Thu, 2005-01-20 at 20:09 +0100, Jacek Rosik wrote: Anyway I don't think that these groups would be multiple of 2048. I can't set offset to any value, it must be aligned as i wrote before. So this would be something around 2040. Or, am I missing something? The alignment only matters for the first group I think, the other ones will automatically be aligned. This is correct. Just out of curiosity is it posible to have the viewport be smaller then 2048, something better/diffrent then using a cliprect. The reason I ask is that I'd like to play around with rendering to slivers(6 * Y) vs (128 * Y). It would look ugly to have more then just OFFSET == (X | 16), I.E. if Y 2048 and (Y - X) 4096; OFFSET = ((X - (Y - X) / 4) | 16). -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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 __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com --- 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: Radeon and viewport size limits.
--- Jacek Rosik [EMAIL PROTECTED] wrote: Dnia 20-01-2005, czw o godzinie 13:59 -0500, Michel Dänzer napisa³(a): On Thu, 2005-01-20 at 12:49 +0100, Jacek Rosik wrote: Radeon and R200 drivers report GL_MAX_VIEWPORT_DIMS=4096, 4096, but I think that hardware can maximally suport 2048, 2048. Anyway I don't think current drivers don't even support 1, 1 if window will be placed further from top left corner than 2048 in any direction. Yes, this has been discussed a couple of times before. So, I was trying to fix this problem by changing offset used by accelerator to point to top left corner of the viewport. This will likely be a useful optimization, but the general solution is probably needed as well: Split cliprects on boundaries of multiples of 2048 and iterate over the resulting 'cliprect regions' with the viewport state changing as necessary for every iteration. That's exactly what I'm trying to achieve as my end result :). Changing offset if first point of my plan, when I have this working I can move on to splitting cliprects and iterating over the resulting groups. As I understand it now i need to change offset for each such group. I was able to change the offset, but I got stuck with then having to translate all the drawing back into place. What would happen was the gears would be moved right and no longer be centered. I'd love to continue once I see a solution to this problem. Anyway I don't think that these groups would be multiple of 2048. I can't set offset to any value, it must be aligned as i wrote before. So this would be something around 2040. Or, am I missing something? 1024 would be good(1/2) but 2/3 will sometimes get better results. 3/4 since it's (1536)110b or 0x600 would probly be the best. Trying to break it up into larger/smaller fractions will result in a sliver(5 x Y) being rendered too, I don't see why this would be good. Keep in mind that triangles that cross these lines might need to be emited twice. Only testing can tell thought, I'd be happy to help here. Best, -- Jacek Rosik [EMAIL PROTECTED] --- 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 __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 --- 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
Building DRI snapshots for sarge once stable, big problems if nothing is done.
I have not heard from the debian X ppl on if, at this late hour, thay will accept patches for things like this. --- Michel Dänzer [EMAIL PROTECTED] wrote: On Thu, 2004-12-30 at 12:33 -0800, Mike Mestnik wrote: --- Michel Dnzer [EMAIL PROTECTED] wrote: * X server from the X.Org tree. Will building the X.Org binarys and puting them on a system expecting Xfree86 binarys work? Hmm, there may indeed be issues, in particular related to stuff like XKB. Someone would have to try... or, if you (or anybody else, for that matter) want to make snapshots from XFree86 CVS instead, go ahead. This is what I'v beed trying to say. 1. The old xc tree is dead. 2. It's currently the only way to build Xfree86 server for Debian. Look at the recent(2004.11.23) source! 3. This has recently stoped working. Can we fix this as an easy way out? 4. It would be nice to fold these changes into Debian's Xfree86. 5. What are these changes? 6. Replacing Xorg for Xfree86 on Debian stable(sarge)... Dosen't seem like a good idea, the day for this may come but it is not this day. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 --- 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
glxcmds.c: Building with Debian's Xfree86.
I came accross a building broblem I'm not able to handle. AFAICT there is a problem in one of the GL or X11 header files. glxcmds.c: In function `CreateContext': glxcmds.c:504: error: `X_GLXCreateNewContext' undeclared (first use in this function) glxcmds.c:504: error: (Each undeclared identifier is reported only once glxcmds.c:504: error: for each function it appears in.) glxcmds.c:516: error: `xGLXCreateContextWithConfigSGIXReq' undeclared (first use in this function) I found these in glxproto.h but including this file dose not solve the problem, it only creates another one(missing CARD32). I eventually came full circle when I included both X11/Xdm.h and glxproto.h. Could it be that these .h files are order dependent? glxproto.h includes glxclient.h wich includes glxmd.h(This file should include it's parent X11/Xdm.h , no?). However glxproto.h hase no includes, should there AT THE VARY LEAST be a remark listing what X11/Xorg and glx/dri headers is needs. All of this might be folly as last time I used DRI w/o DRI's xfree86 server(That is dead) I got ABI errors. __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 --- 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: libdrm issues blocking accelerated indirect GL
--- Roland Mainz [EMAIL PROTECTED] wrote: Jon Smirl wrote: glxProxy effectively would put the GL rendering in its own thread. And nothing necessarily prevents us from creating a new thread for in-server DRI. If the rendering is properly encapsulated, then making it multicore-friendly is cheap and easy; if libglx is redone such that both in-process and out-of-process indirect GL are possible, then the rendering is probably pretty close to being properly encapsulated. Not disagreeing with you, just saying that discussion is quite a bit down the line ;). Why is this so different that what a local process does right now? For the remote GLX user split off a new process, it uses DRI to do all of it's drawing and then calls back into the server for GLX. A more efficient scheme would be for the server to directly run GLX calls when received from the remote user and then ship all of the GL call off to the second process. The idea of forking a complete new process worries me a lot... why is it What's the problem, if it's only done at client connect(read as once in a while)? neccesary to use a new process here and no new thread ? A thread could communicate much easier with the main Xserver thread than a fully-blown new process and would even share the same memory mappings... What about root privs? I'm talking in terms of exploit prevention. Has anyone ever considered a model where the X server process forks Many times, in history it has been an exepted idea. Would you like to actualy code this? off another process for each remote user, and the that process listens on the remote net connection and makes X/GL/GLX calls just like a local process, forwarding GLX/X requests to the server process as needed? This may be the best model for the X on GL world. 1. Doesn't this mean we will have multiple process switches just to process the traffic ? No, you close the handel in the parent process and release/logout on SIGCHILD. Connection 'back' the the X server could be done prefork so there is 'NO' chance of the process not being able to connect. 2. How will such a model handle applications which render in the same window but run under different UIDs ? Why would [EMAIL PROTECTED] have a UID on host foo? For a local connection this whole thread dose not apply. Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) --- 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 __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com --- 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: dri_util.c:157: warning: pointer targets differ in signedness.
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Wed, 2004-12-29 at 17:46 -0800, Mike Mestnik wrote: --- Philip Armstrong [EMAIL PROTECTED] wrote: On Tue, Dec 28, 2004 at 06:41:38PM -0600, John Lightsey wrote: First let me say that if anyone would like to take over updating the dri-trunk-sid packages on a semi-regular basis, I'd really appreciate it. I don't track the Debian X or DRI mailing lists closely enough to keep up with changes. I'd like to, but I'm not sure I have the time. I'll pull the sources over sometime over the new year and take a look. This might not be posible untill there is a sutable Xserver avalable !with out! using DRI's old xc tree, read below. The DRI xc tree is dead, it's been folded into the X.Org tree. I know, this causes a problem for any one building Xfree86 DRI. We need to fold the DRI xc tree into Xfree86 or stop using Xfree86 alltogether. On Tue, 2004-12-28 at 15:00 -0800, Mike Mestnik wrote: At this time Xorg is used for most of the DRI development. It also seams that the dri, glx, and opengl Xdrivers can be built in the Mesa tree with libGL and the dri_ Xdrivers. Since Mesa is now able to build against Xfree86 and Xorg this would seam to fix most of the problems. This is news to me. I thought the current recommended way of doing things was to build an Xorg xserver, glx, and libgl, then build the 3D drivers in Mesa. Maybe he's referring to embedded Mesa? No, the current unofficial pkgs use the OLD xc tree to build Mesa and we also need to build X from that tree. Since the Mesa tree has changed the xc tree is now totaly bittroten, with no reason to correct this. I don't think it will be posible to build the Xserver binary w/o using a(read as any) xc tree. The only solution I see is to port the needed, if any, changes to a working and maintained xc tree. When this is done the only problem that remains is the 2d Xdrivers, as I woulden't expect any one to pickup the MeargedFB code. The DRI xc tree has been folded into the X.Org tree, including MergedFB etc.; it's dead. Read Above. I think with little effort the Mesa tree can be made to build a wider veriaty of Xdrivers since currenty the 3d Xdrivers are built in this tree. What 'veriaty of Xdrivers' are you talking about, in particular, what's a '3d Xdriver'? If you mean DDX drivers, I don't think those will ever build in the Mesa tree. I'm talking about 2d Xdrivers, where current MergedFB is built. I think these can be built with the Mesa/lib/r200_dri.so files that live in X11R6/lib/modules/dri/r200_dri.so? I think this is the best way to get the Debian DRI pkgs building again. I would hope that some one familure with Mesa builds would atleast create the makefiles and symlinked headers for the 2d Xdrivers to build on. FWIW, if I had the time to work on those packages again, I'd do it along the lines of: * DRM packages from the directory du jour of the mess that is the DRI CVS drm module. * libGL and 3D drivers from the Mesa tree (building libGL requires adding glxproto.h to the tree though). * X server from the X.Org tree. Will building the X.Org binarys and puting them on a system expecting Xfree86 binarys work? When sarge is released there will be ppl(like me) not willing to run Xorg, since it's not shiped with sarge. The real problem is how to get the changes out of the old xc tree, this I can't solve but I know it must be done, if it must be done. Repeat after me: The DRI xc tree has been folded into the X.Org tree; it's dead. The... The DRI xc tree has been folded into the X.Org tree; it's dead. Ohh, lord what will we do? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo --- 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: dri_util.c:157: warning: pointer targets differ in signedness.
--- Dave Airlie [EMAIL PROTECTED] wrote: I know, this causes a problem for any one building Xfree86 DRI. We need to fold the DRI xc tree into Xfree86 or stop using Xfree86 alltogether. I'm talking about 2d Xdrivers, where current MergedFB is built. I think these can be built with the Mesa/lib/r200_dri.so files that live in X11R6/lib/modules/dri/r200_dri.so? here you are talking about 2D drivers, mergedfb is a 2D thing really, it's been merged into Xorg, but not XFree86, take it up with XFree86, Alanh merges DRI changes into the XFree86 tree still on a regular basis, but mergedfb isn't really a DRI change it was just developed in the DRI tree as the XFree86 tree was too closed shop for anyone to use... so I don't think he can merge it into the XFree86 tree (I've no idea how their developers work or don't...) This unfortunatly will not help with snapshots or Debian. When Debian's next realese sarge is frozen no more upgrades from the Xfree86 tree will be made. Untill recent changes to the Mesa tree have made building the DRI xc tree next to imposible this has not been a problem. Now that the xc tree is dead Debian users who wish to run DRI snapshots are left with ought any *GOOD* way of doing so. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 --- 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: dri_util.c:157: warning: pointer targets differ in signedness.
--- Philip Armstrong [EMAIL PROTECTED] wrote: On Tue, Dec 28, 2004 at 06:41:38PM -0600, John Lightsey wrote: First let me say that if anyone would like to take over updating the dri-trunk-sid packages on a semi-regular basis, I'd really appreciate it. I don't track the Debian X or DRI mailing lists closely enough to keep up with changes. I'd like to, but I'm not sure I have the time. I'll pull the sources over sometime over the new year and take a look. This might not be posible untill there is a sutable Xserver avalable !with out! using DRI's old xc tree, read below. On Tue, 2004-12-28 at 15:00 -0800, Mike Mestnik wrote: At this time Xorg is used for most of the DRI development. It also seams that the dri, glx, and opengl Xdrivers can be built in the Mesa tree with libGL and the dri_ Xdrivers. Since Mesa is now able to build against Xfree86 and Xorg this would seam to fix most of the problems. This is news to me. I thought the current recommended way of doing things was to build an Xorg xserver, glx, and libgl, then build the 3D drivers in Mesa. Maybe he's referring to embedded Mesa? No, the current unofficial pkgs use the OLD xc tree to build Mesa and we also need to build X from that tree. Since the Mesa tree has changed the xc tree is now totaly bittroten, with no reason to correct this. I don't think it will be posible to build the Xserver binary w/o using a(read as any) xc tree. The only solution I see is to port the needed, if any, changes to a working and maintained xc tree. When this is done the only problem that remains is the 2d Xdrivers, as I woulden't expect any one to pickup the MeargedFB code. I think with little effort the Mesa tree can be made to build a wider veriaty of Xdrivers since currenty the 3d Xdrivers are built in this tree. I think this is the best way to get the Debian DRI pkgs building again. I would hope that some one familure with Mesa builds would atleast create the makefiles and symlinked headers for the 2d Xdrivers to build on. The real problem is how to get the changes out of the old xc tree, this I can't solve but I know it must be done, if it must be done. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com --- 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: dri_util.c:157: warning: pointer targets differ in signedness.
--- John Lightsey [EMAIL PROTECTED] wrote: First let me say that if anyone would like to take over updating the dri-trunk-sid packages on a semi-regular basis, I'd really appreciate it. I don't track the Debian X or DRI mailing lists closely enough to keep up with changes. On Tue, 2004-12-28 at 15:00 -0800, Mike Mestnik wrote: The source I'm using contains the old DRI xc. I can see where the old xc source is needed to build the OLD Xserver and Mesa is needed there to build it's dri, glx, and opengl Xdrivers. How ever I can't see why this old xc code has not been diffed in to debian's Xfree86? Would submitting a patch to TDBTS help? I'm not a member of the Debian X team so I don't speak for them, but I wouldn't expect that a patch of DRI's changes to XFree86 will be accepted. The reason I started updating Michel Daenzer's packages was that I needed MergedFB support and wanted some of the fixes that were being incorporated into DRI. Requests for MergedFB in Debian's X packages date back to June 2003. I wouldn't imagine there will be any major changes to Debian's X until Sarge releases. At this time Xorg is used for most of the DRI development. It also seams that the dri, glx, and opengl Xdrivers can be built in the Mesa tree with libGL and the dri_ Xdrivers. Since Mesa is now able to build against Xfree86 and Xorg this would seam to fix most of the problems. This is news to me. I thought the current recommended way of doing things was to build an Xorg xserver, glx, and libgl, then build the 3D drivers in Mesa. http://dri.sourceforge.net/cgi-bin/moin.cgi/Building The problem is building the Xserver. I think this is why the xc tree is used. There is also the problem of building diffrent 2d XDrivers, for MFB and the like. Rather than updating the dri-trunk-sid packages to build Xorg it might be easier to direct users to the experimental Xorg packages at http://debian.linux-systeme.com/ This lookes like a good solution. If it where easy to use DRIs snapshots then there would be little need for Debian pkgs. With a new libGL in place, installing Mesa and drm CVS by hand isn't that difficult and doesn't have to overwrite the packaged X server. It would be nice if driconf had a way of overriding LIBGL_DRIVERS_PATH on a per-user or global basis though. The Mesa tree can build both libGL and libGLU. Last time I tryed using Debian's xserver-xfree86 pkg with Mesa built libGL and 3d Xdrivers it complained about ABI versioning and other stuff I had little desier to read about. I got this after cvs updating the tar.gz of the unofficial debian source... This source is at least missing the DRI_NEW_INTERFACE_ONLY define dri_util.c:1073, cause it uses the xc Makefiles to build Mesa. dri_util.c: In function `glx_find_dri_screen': dri_util.c:157: warning: pointer targets in passing arg 1 of `glXGetProcAddress' differ in signedness I ran into the same problem, but this message convinced me there was little point in trying to fix it. http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg20719.html John ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com --- 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
DRI Wiki has bad snapshots links.
http://dri.freedesktop.org/wiki/Download Has links to http://www.freedesktop.org/~dri/snapshots/, that should be fixed up. I would be gald to help, but the page is immutable. __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com --- 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
Doom3 screenshots.
I'm putting broken Doom3 screenshots up at http://train.is-a-geek.org/~cheako/. __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com --- 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: Looking for some answers.
This defenatly belongs on another Xrelated list. --- Austin Yuan [EMAIL PROTECTED] wrote: On Sat, Dec 18, 2004 at 04:54:20AM +0800, Alex Deucher wrote: On Fri, 17 Dec 2004 10:35:42 +, Ian Molton [EMAIL PROTECTED] wrote: Hi. Is MergedFB going to replace xinerama in the long run? maybe. they will probably co-exist for the forseeable future. regular multi-head allows you do have two independant X servers while mergedfb always creates one single logical desktop. I have a question about regular multi-head with one card,two screens. It allows we use two independant desktops. But from /etc/X11/xorg.conf,keyboard and mouse configuration are included into ServerLayout section,not Screen section. It seems that one Xserver can't use two independant keyboard and mouse. If I want to do a thing like this: one machine,1 video card with 2 CRTS,2 mice, 2 keyboard. The individual keyboard/mouse is intended to work with one CRT, so that 2 person can use one machine at the same time. But one Xserver cann't handle this circumstance. Miguel gave us a method on http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/g450.html. But it needs to hack Xserver, and start up two Xservers running on fbdev. Do you have some comment on this issue? I would quote the original document... I would love to see XFree86 supporting simultaneous layouts (without another instance). The X(7x) manpage has some info on how this should work under it's DISPLAY NAMES section. --- 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 __ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com --- 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
Doom3 Blood over everything, Depth problem?
http://train.is-a-geek.org/%7Echeako/DebthClear.tga The blood that should be one the floor is on the gun, doors, walls(around corners). Also some other things like logos(sings) ect show through. This could be a diffrent bug, but some times rounded walls seam to have a translucent property to them. __ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com --- 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: Looking for some answers.
--- Alex Deucher [EMAIL PROTECTED] wrote: On Sat, 18 Dec 2004 10:56:42 +, Ian Molton [EMAIL PROTECTED] wrote: Mike Mestnik wrote: if not, will xinerama be able to use 3D / Xv properly on radeon (9000) in the near future? I don't think there are any plans to support 3D for xinerama. Is there a technical problem or is it just lack of interest? It's somewhat of a technical problem. It could be done with indirect rendering (opengl commands are send through the X server via glx), but that is not yet hw accelerated. right now id does work with sw rendering. With direct rendering the 3d app talks directly to the hardware via libGL, bypassing the Xserver. if you wanted to support direct rendering with xinerama you'd have to have some sort of intellegent dispatch layer to coordinate rendering between potential multiple 3d engines. Once we have hw accelerated indirect rendering, we could disable direct rendering when xinerama is active and use If this realy was the correct solution?! Now that we have futexs(In linux 6 any way) the shm-transportis has overcome one of it's big problems. Shared memory transports would speed lots(2d, 3d, X11R6) of the drawing ops up, if it can be implemented so that it's faster then unix sockets. In any event local client's that don't have access to the drm device would use the Xserver for rendering, so there is at least one good reason to implement DXRI(It is direct shared memory to an Xserver rendering). glxproxy to dispatch 3d commands to the backend X servers. Mergedfb works because it's just one big framebuffer with two viewports looking into it so the 3d engine treats it as such. It provides it's own version of xinerama so apps know how behave from a screen persective. Alex __ Do you Yahoo!? Jazz up your holiday email with celebrity designs. Learn more. http://celebrity.mail.yahoo.com --- 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: Looking for some answers.
--- Ian Molton [EMAIL PROTECTED] wrote: Hi. Is MergedFB going to replace xinerama in the long run? MergedFB only workes on hardware that supports it, where both heads can share the same continious framebuffer. This can only be done if the DACs(heads) share the same video memory. if not, will xinerama be able to use 3D / Xv properly on radeon (9000) in the near future? I don't think there are any plans to support 3D for xinerama. why doesnt radeon xinerama use mergedFB techniques to acieve its ends ? The only big hurdel is wather or not the heads share enuff videomemory for the entire FB. --- 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 __ Do you Yahoo!? Send a seasonal email greeting and help others. Do good. http://celebrity.mail.yahoo.com --- 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: New ioctl for surface allocation/deallocation
--- Stephane Marchesin [EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
+ // allocate the surface
+ for(i=0;i8;i++)
+ if (!(dev_priv-surfaces(1i)))
+ break;
+
+ if (i=8)
+ return DRM_ERR(ENOMEM);
+ else
+ dev_priv-surfaces=(1i);
+
+ if ( DRM_COPY_TO_USER( alloc.surface, i,
+ sizeof(int) ) ) {
+ DRM_ERROR( copy_to_user\n );
+ return DRM_ERR(EFAULT);
IMHO it should also manage the ranges (prevent overlapping, ...) and
parameters of the surfaces.
Ok, that was one of my doubts.
So if we go that route, it would manage the ranges, prevent overlapping,
and also try to spare the surfaces by merging adjacent ones with
similar properties.
+ DRM_COPY_FROM_USER_IOCTL( memfree, (drm_radeon_mem_free_t __user
*)data,
+ sizeof(memfree) );
+
+ dev_priv-surfaces= (~(1memfree.surface));
It should definitely ensure that only the owner can free a surface
though. It would also need to free a client's surfaces if it dies, etc.
How do you know the owner ? I'm not sure the pid would be enough.
I'm sure there is a better way, also keep inmind GLX-remote direct
rendering.
For now using the PID to get the UID and EUID would allow any process by
that user to dealloc the reasource(for threaded programs).
Stephane
---
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
__
Do you Yahoo!?
All your favorites on one personal page Try My Yahoo!
http://my.yahoo.com
---
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: Multiple hardware locks
--- Thomas Hellström [EMAIL PROTECTED] wrote: You are probably right, and it would be quite easy to implement such checks in the via command verifier as long as each lock is associated with a certain hardware address range. However, I don't quite see the point in plugging such a security hole when there are a similar ways to accomplish DOS, hardware crashes and even complete lockups using DRI. The ideas is to plug all of them, soner or later. On via, for example, writing random data to the framebuffer, writing random data to the sarea, taking the hardware lock and sleeping for an indefinite amount of time. Writing certain data sequences to the HQV locks the north bridge etc. Seems like DRI allow authorized clients to do these things by design? /Thomas __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
--- Nicolai Haehnle [EMAIL PROTECTED] wrote: On Monday 01 November 2004 07:01, Thomas Hellström wrote: You are probably right, and it would be quite easy to implement such checks in the via command verifier as long as each lock is associated with a certain hardware address range. However, I don't quite see the point in plugging such a security hole when there are a similar ways to accomplish DOS, hardware crashes and even complete lockups using DRI. On via, for example, writing random data to the framebuffer, writing random data to the sarea, taking the hardware lock and sleeping for an indefinite amount of time. Writing certain data sequences to the HQV locks the north bridge etc. Seems like DRI allow authorized clients to do these things by design? From what I've learned, the DRI isn't exactly designed for robustness. Still, an authorized client should never be able to cause a hardware crash/lockup, and an authorized client must not be able to issue arbitrary DMA requests. As far as I know, all DRMs that are enabled by default enforce at least the latter. Personally I believe that in the long term, the DRI should have (at least) the following security properties: 1. Protect against arbitrary DMA (arbitrary DMA trivially allows circumvention of process boundaries) This can be done via command-stream checks. 2. Prevent hardware lockup or provide a robust recovery mechanism (protection of multi-user systems, as well as data protection) Should be relatively cheap via command-stream checks on most hardware (unless there are crazy hardware problems with command ordering like there This is something I think has been discussed. Hopefully the DRM currently varifies the cmd stream so that only the order in DRI's client side drivers is accepted. Other ordering could be fixed, sine the size of the cmds dosen't change, by simply memcpy'ing every thing into this right order. seem to be on some Radeons). I believe that in the long term, recovery should be in the kernel rather than the X server. 3. Make sure that no client can cause another client to crash (malfunctioning clients shouldn't cause data loss in other applications) In other words, make sure that a DRI client can continue even if the shared memory areas are overwritten with entirely random values. That does seem like a daunting task. 4. Make sure that no client can block access to the hardware forever (don't force the user to reboot) I have posted a watchdog patch that protects against the take lock, sleep forever problem a long time ago. The patch has recently been updated by Dieter Nützel (search for updated drm.watchdog.3). However, I have to admit that the patch doesn't feel quite right to me. 5. Enable the user to kill/suspend resource hogs Even if we protect against lock abuse, a client could still use excessive amounts of texture memory (thus causing lots of swap) or emit rendering calls that take extremely long to execute. That kills latency and makes the system virtually unusable. Perhaps the process that authorizes DRI clients should be able to revoke or suspend that authorization. A suspend would essentially mean that drmGetLock waits until the suspend is lifted. I know that actually implementing these things in such a way that they Just Work is not a pleasant task. I just felt like sharing a brain dump. cu, Nicolai ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
--- Thomas Hellström [EMAIL PROTECTED] wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers? In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip. My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of. 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected There is a problem with A client being able to lock/unlock resources it may/may not be using. It's important that Client's arn't able to DOS the system by submitting junk cmds /wo setting the right locs for that junk. by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? /Thomas --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
--- Thomas Hellström [EMAIL PROTECTED] wrote: Such a case would be a client submitting 2D engine commands while the X server waits for 2D engine idle. Either this has to be implemented in the command verifier or considered acceptable behaviour. Today any dri client can continously clear the screen without taking the hardware lock. There are many factors that come into play. However if a potentialy hamfull interface can be fixed easily there may be no reason not to. __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
--- Thomas Hellström [EMAIL PROTECTED] wrote: Keith Whitwell wrote: The typical case here: I want a DRI client to flip a video frame to screen, using a hardware entity called the HQV. This is a rather time critical operation. To do this I have to take the hardware lock. While this is happening, another thread is waiting for the mpeg decoder to complete a frame. To to that, this thread needs to take the hardware lock, wait for quiescent DMA, and then wait for the mpeg decoder to signal idle. It might be that the DMA command queue does not even contain mpeg data. This waiting delays the frame flip enough to create a visible jump in the video. With multiple locks: The first thread checks the HQV lock, it is available and frame flipping is done immediately. The other thread meanwhile takes the MPEG engine lock, waits until the DMA engine has processed all MPEG commands in the command queue and then waits for the MPEG engine to be idle. DMA might still be processing 3D commands. Only while submitting command buffer data. This will hopefully be a very fast operation. The IOCTL copying this data to the ringbuffer will check that all locks are held for the hardware entities that the submitted command batch touches. The user will have to tell the IOCTL which entities these are, or possibly the command verifier checks this but I consider that an overkill since that is more of a bug-check than a security check. Part of security is making sure authorised users can't make changes to other users tasks. In this case killing all the tasks, by causing a hardware fault, is a good example. It's a fackt that any user with rights to the DRM device can use any other code or program to play with the card or send junk into the cmd streem. The DRM should detect and prevent this, even if it means a slight proformance loss. Can I get an AMEN? __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X11R6.8.2 maintenance release plans and call for comments.
--- Sérgio M. Basto [EMAIL PROTECTED] wrote: Hello, On Wed, 2004-10-27 at 09:28, Ely Levy wrote: I supported it then and I still think it's a great idea, It would let people feel that they have influance and let us see what people want (but we said it all in the thread there). what I would like to see, is two trees one for testings (stable) and one for development (unstable) The one for developing should have also development of Mesa and drm (that it is now on trunk tree) and the test tree should be updated ( drives , dri-drives, Mesa, drm and whatever ) only when is consolidated the development. There is another problem with the Xorg(stable or unstable) tree getting too far ahead of the Mesa/drm trees, AKA can't build Mesa with latesed Xorg. As A solution I propose that branch tags be added to the Xorg tree for Mesa/drm developement. 1. These branchs should have corrisponding statik/regular tags in the Mesa and drm trees. 2. This way if you look for the tag(in Mesa) for the last tag-id your CO had, you could CO that branch from Xorg and it would allways(IAPW) build. 3. When Mesa development needs another feature(or bugfix from another Xorg branch) added to there branch it's easy. 4. These changes would be folded into Xorg's unstable whenever Mesa's code is knowen to build with it... The Xorg branch gets mearged to unstable. Another Xorg branch is created. The Mesa and drm trees get taged with the new tag-id used in Xorg's CVS. Conclusion in my point of view: The development tree should be, what is now the trunk tree and xorg tree should be more stable, if someone want try experimental code can do it in trunk (of course trunk has to be one xorgR6.8.1). thats my opinion. thats, -- Sérgio M. B. --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
--- Philipp Klaus Krause [EMAIL PROTECTED] wrote: Thank you for doing this work. We really need to get the open-source ATI driver on par with the propretary driver (both feature-wise and performance-wise). But sadly we will NEVER match it. NO SmoothVision, HyperZ docu ever The nonfree xig driver has been developed without HyperZ docs and outperforms fglrx. It's my opinion that xig uses trickery to get there FPS higher then it should be posible to under OpenGL compliant rendering. It's also true in the font and 2d(like lack of xv support) accelerations as well. Do you mean fglrx or opengl.dll - radeon.drv? Even though I just have a Radeon 9200, I'm very excited about the ongoning R300 effort and with there was a similar project for NVidia cards too. Above applies here, too. - Sorry. The situation seems to be much worse in the future. Bad IP (TRIPS, etc.) madness due to USA-law. True. ATI no longer releases docs. 3dlabs no longer does. Nvidia never did. Intel requires an NDA now. If there weren't all those patents out there we might just try to develop a free graphics chip. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
--- Philipp Klaus Krause [EMAIL PROTECTED] wrote: Dieter Nützel schrieb: The nonfree xig driver has been developed without HyperZ docs and outperforms fglrx. Are you sure. I thought Xig had it all before. Do you have actual numbers? Haven't looked at them for very long time, but I bought the first version of there X server 1994 (?) for mga. Roland made a comparison a year ago: http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oct03.html Xig even outperforms the ATI windows drivers. This has allot more todo with OSs then video drivers. Take the original doom and quake for example. Both had software rendering directly to the HW, via DOS. It's also true that on a 386(33mhz) doom was playable on linux(about 23 FPS) and unplayable in DOS(about 18 FPS) about just by changing OSs. For quake the numbers where less devistating on a 486(32 FPS) but in windows emulated dos(with IP/UDP support) got only 27 with quake. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote: Mike Mestnik wrote: --- Philipp Klaus Krause [EMAIL PROTECTED] wrote: Thank you for doing this work. We really need to get the open-source ATI driver on par with the propretary driver (both feature-wise and performance-wise). But sadly we will NEVER match it. NO SmoothVision, HyperZ docu ever The nonfree xig driver has been developed without HyperZ docs and outperforms fglrx. It's my opinion that xig uses trickery to get there FPS higher then it should be posible to under OpenGL compliant rendering. It's also true in the font and 2d(like lack of xv support) accelerations as well. What do you mean by the lack of xv support? I often use the XiG driver and have never encountered this limitation. This is when you run (mplayer, xine, ext) and you go full screen. With xv ONE of the things you will see is the video gets streached to fill the whole screen. Withought xv the video stayes the same size and the extra screen is filled with black. Adam ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problem with remap_pfn_range on older 2.6.8 kernels.
--- Dieter Nützel [EMAIL PROTECTED] wrote: Am Samstag, 23. Oktober 2004 08:59 schrieb Dave Airlie: try it now .. I've just checked in a compat fix.. hopefully it works... Dave. CC [M] /opt/drm/linux-core/drm_stub.o /opt/drm/linux-core/drm_stub.c:50: error: parse error before int make[3]: *** [/opt/drm/linux-core/drm_stub.o] Fehler 1 make[2]: *** [_module_/opt/drm/linux-core] Fehler 2 make[2]: Leaving directory `/usr/src/linux-2.6.5-7.108' make[1]: *** [modules] Fehler 2 make[1]: Leaving directory `/opt/drm/linux-core' make: *** [radeon.o] Fehler 2 7.862u 2.181s 0:37.11 27.0% 0+0k 0+0io 92pf+0w I didn't realy look to se if the build faild thought I don't think it did. Now I get (WW) RADEON(0): [agp] AGP not available even thought it's loaded as b4. eeprom 7816 0 radeon 79744 0 drm68260 1 radeon i2c_algo_bit9800 1 radeon amd_k7_agp 7820 1 agpgart34536 1 amd_k7_agp -Dieter On Fri, 22 Oct 2004, Mike Mestnik wrote: A recent DRM checkin Bring in patch from kernel for remap_pfn_range only workes if your 2.6 kernel has remap_pfn_range, unlike Debain's 2.6.8-1-k7. ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Where to get shiney new libGL for current DRI CVS?
I used -D Fri Oct 22 16:03:19 2004 UTC to detect my AGP, now (II) RADEON(0): Direct rendering enabled This is where I got with my old Xserver(Debian's xserver-xfree8 4.3.0.dfsg.1-8). I thoguht it would be trivial to replace with Xorg from SS. After linking XF86Config.4 to xorg.conf every thing worked fine. Maby the SS version should look for this older conf file and not try to run getconfig at all. I still don't have DR client's I just built the drivers from Mesa CVS. I only got the sym links for libGL, no binary. I have tried all 3 versions I have, one built from the old DRI xc tree, one from debian(note these have never been compatible), and the last from fglrx(worth a try). ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Problem with remap_pfn_range on older 2.6.8 kernels.
A recent DRM checkin Bring in patch from kernel for remap_pfn_range only workes if your 2.6 kernel has remap_pfn_range, unlike Debain's 2.6.8-1-k7. ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 ReadPixels optimization
--- Ville Syrjälä [EMAIL PROTECTED] wrote: On Thu, Oct 07, 2004 at 02:02:38PM +0100, Alan Cox wrote: Note that there's some code in there already which uses the blitter to copy from framebuffer to agp memory, though it tries to implement the entire readpixels() operation rather than being a useful low-level operation. AGP memory is hostside uncached (CPU limitations on x86 for one) which means it is better (swap PCI for DDR ram bus latencies is good) but still benefits from the treatment. Why can't we make AGP memory cached? Wouldn't it be enought to flush the caches at some critical points? I was playing around with DirectFB and AGP some years ago and enabling write-back caching didn't seem to have any side effects. Without caching AGP is almost as bad as video memory for sw fallbacks. I don't get it... We would have to flush the cache after the AGP transfer any way, right? If this truely can't be cached then woulden't the AGP transfer slow us down even more? So unless we get vastly improved performance, the end result is more painfull to use the AGP transfer. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: doom3 linux client and demo has been released
How is I in the below page, I'd like to cc him on this... --- Jacek Pop³awski [EMAIL PROTECTED] wrote: Sorry if it is not best place to write about it, but I believe Doom3 is very This is the place. Unless your talking about an older application, then I'd try the dri-users list first. important application, and many developers will be interested in testing it It will be supported by both drivers, the question is when. What was needed is a release from ID. Now that we have it, it's only a matter of time. with DRI driver (linux client author wrote, that he hasn't tested it with DRI at all, and that it doesn't work with fglrx!). I wasn't able to test it yet, I Funny, in the list of Minimum Specs it says OpenGL hardware acceleration. This should(it would be nice if) be elaborated into another section(maby a whole new page) with a list of REQUIERED and optional OpenGL extentions. There just happens to be a [1]thread on the diffrences of FGLRX and DRI with an R200. It contains a list of currently supported extentions for both drivers. The I person should/could look at the list and tell what needs tobe done. 1. http://marc.theaimsgroup.com/?l=dri-develm=109654891412569w=2 just noticed it, and I am at work. http://zerowing.idsoftware.com/linux/doom/ (downloads and some docs) -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: doom3 linux client and demo has been released
--- Fryderyk Dziarmagowski [EMAIL PROTECTED] wrote: --- Jacek Pop³awski [EMAIL PROTECTED] wrote: Sorry if it is not best place to write about it, but I believe Doom3 is very important application, and many developers will be interested in testing it with DRI driver (linux client author wrote, that he hasn't tested it with DRI at all, and that it doesn't work with fglrx!). I wasn't able to test it yet, I just noticed it, and I am at work. uh, it won't run (R200 aka Radeon 8500, Xorg 6.8.1): [...] using ARB_vertex_buffer_object memory using ARB renderSystem Mesa implementation error: unexpected texture format in r200ChooseTextureFormat Please report to the Mesa bug database at www.mesa3d.org doom.x86: texstore.c:2260: _mesa_store_compressed_teximage2d: Assertion `texImage-TexFormat' failed. signal caught: Aborted si_code 0 Trying to exit gracefully.. [...] It this that application bug where a function is bound but not listed in the supported extentions list and the app dosen't check. Maby the error msg should be changed? -- Fryderyk Dziarmagowski --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRM and fbdev
What about moving the DRM and FB specific code into there own per card libs? radeon - attached to hardware radeon-drm drm - library radeon-fb fb - library fbcon - library Keeping in mind that any/all external symbols to/from radeon-drm and radeon-fb can/should be weak. __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxinfo: R200 VS FGLRX side by side...
--- Alex Deucher [EMAIL PROTECTED] wrote:
On Thu, 30 Sep 2004 11:27:28 -0700, Ian Romanick [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
Here is a straigth diff, I didn't do a udiff since I think we all
know the
glxinfo output fairly well. I did make one change s/, $//g and s/,
/\n
/g. I'm also attaching the 'source'.
A better way to get meaningful diffs is to pipe the output of
glxinfo
to grep GL_ | sed 's/, /\n/g' | sort -u. It's a bit more tricky for
GLX extensions because there are multiple listings for that (client,
server, and combined).
Looking at the list, I noticed a couple of odd things. Why don't the
ATI drivers support GL_{ARB,EXT,NV}_texture_rectange or
GL_{ARB,EXT}_blend_equation_separate? Beyond that, there are
basically
5 groups of useful extensions that they have but we don't:
- GL_ARB_texture_env_crossbar
- GL_ARB_occlusion_query and similar extensions.
- GL_ARB_point_parameters (I thought support was added for this?)
- GL_EXT_multi_draw_arrays
- GL_EXT_fog_coord
Crossbar, point parameters, and multi draw arrays should be easy
enough
to add. I tried to add support for fog coord, but there's some bit of
documentation that we're missing. I just could not get it to work in
TCL mode. :( For occlusion query, we're missing a significant amount
of
documentation.
Vladimir's glxtest code may be helpful in figuring out the missing
bits if anyone is so inclined...
Are you implying that this program will/could work with the fglrx driver?
Alex
__
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxinfo: R200 VS FGLRX side by side...
--- Alex Deucher [EMAIL PROTECTED] wrote:
On Fri, 1 Oct 2004 08:52:58 -0700 (PDT), Mike Mestnik
[EMAIL PROTECTED] wrote:
--- Alex Deucher [EMAIL PROTECTED] wrote:
On Thu, 30 Sep 2004 11:27:28 -0700, Ian Romanick [EMAIL PROTECTED]
wrote:
Mike Mestnik wrote:
Here is a straigth diff, I didn't do a udiff since I think we
all
know the
glxinfo output fairly well. I did make one change s/, $//g and
s/,
/\n
/g. I'm also attaching the 'source'.
A better way to get meaningful diffs is to pipe the output of
glxinfo
to grep GL_ | sed 's/, /\n/g' | sort -u. It's a bit more tricky
for
GLX extensions because there are multiple listings for that
(client,
server, and combined).
Looking at the list, I noticed a couple of odd things. Why don't
the
ATI drivers support GL_{ARB,EXT,NV}_texture_rectange or
GL_{ARB,EXT}_blend_equation_separate? Beyond that, there are
basically
5 groups of useful extensions that they have but we don't:
- GL_ARB_texture_env_crossbar
- GL_ARB_occlusion_query and similar extensions.
- GL_ARB_point_parameters (I thought support was added for this?)
- GL_EXT_multi_draw_arrays
- GL_EXT_fog_coord
Crossbar, point parameters, and multi draw arrays should be easy
enough
to add. I tried to add support for fog coord, but there's some
bit of
documentation that we're missing. I just could not get it to work
in
TCL mode. :( For occlusion query, we're missing a significant
amount
of
documentation.
Vladimir's glxtest code may be helpful in figuring out the missing
bits if anyone is so inclined...
Are you implying that this program will/could work with the fglrx
driver?
This wasn't ovious by the documentation, thought it dose answer my Q as to
why there is all the guess work involved in using glxtest.
Well, yeah. that's how it works. It captures commands sent to the
card which can then be decoded to figure out how things work. it
should work with any card supported by fglrx.
LOL, it might but if GL_EXT_fog_coord dosen't work for the r200, even with
the fglrx driver, it's of little use.
I could be doing something wrong, like using an SDL example.
http://nehe.gamedev.net/data/lessons/linuxsdl/lesson41.tar.gz
Alex
Alex
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give
us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sparse and DRM on non-x86
--- Jon Smirl [EMAIL PROTECTED] wrote: On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: This implies that DRM should be passing back two distinct handle types, one for normal and one for IOMEM, so that the user space app will use the correct access function. This is also a pretty good argument for hiding direct framebuffer access and forcing access with read/write calls on a handle like the IA64 people want to do. When you say read and write and handle, do you mean read(2)/write(2) and filehandle? Or some sort of #defined read/write macros? or something else? They want to use read(2)/write(2). IMHO this is loonisy... You will also need to use lseek(2) since ssize_t read(int fd, void *buf, size_t count); is missing some things that mmap(2) was made to work around. I realy don't think there is ANY device on this planet that uses registers for it's framebuffer, not that registers are any diffrent from a memory stick. It's just that most IO ports arn't memory there fifos that sometimes will recall the last value writen if asked. A framebuffer by it's vary nature MUST recall the last value writen when asked, thus it's memory not an IOmaped FIFO. Keith -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sparse and DRM on non-x86
--- Keith Whitwell [EMAIL PROTECTED] wrote: Jon Smirl wrote: On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Second the DRM code always treats the framebuffer as if it is in IOMEM. But what about IGP type devices where the framebuffer is in main memory? These only exist on the x86 so treating their framebuffer as IOMEM works since there is no difference between IOMEM and normal memory access on an x86. The framebuffer lives in agp memory on those devices, presumably this is iomem as it appears to be memory of the agp device. On normal AGP/PCI cards the memory is on the card. It is accessed over the AGP/PCI bus which requires special IO instructions on non-x86 hardware. IGP cards use the normal system memory for their buffers. You don't use the special IO instructions to access this memory. The key is where the memory lives, on the graphics card or on the motherboard. On x86 both types of memory use the same access instructions since the x86 makes AGP/PCI memory look like normal system memory. So we don't have a problem. I understand this. I'm pointing out that agp memory, ie. system memory mapped into the GART table, though it is backed by system memory, is typically accessed through an io range of the gart device. So what sort of memory is that? Yes, thoguht it might help you better to view this IO port is a ?multi?point-to-point AGP bus. From the CPU, on the FSB, this memory as well as any other mmaped IO is accesed as system memory(with intructions like mov) and not IO-Ports that use in(asm) and out(asm) intructions. For the Intel chipsets, again, although the framebuffer is backed by system memory, all accesses to that memory are through a device io memory range, not by reading/writing to the backing memory directly. io memory range, still dosen't sound like an IO-Port(from the CPU's FSB PoV). This would most likely be memory-maped IO? On other platforms introduction of an IGP type device will break X/mesa since they don't know to switch from IO instruction access to normal memory access. IA64 may have already run into this on unreleased products since they have been asking questions along these lines. I've seen stuff on the web that suggests Intel wants to unify its chipsets to support both x86 and IA64, so that's not a huge suprise. It'd still be good to base any design on actual known examples rather than guesses as to what might be coming. Good, lets talk about i386's ISA bus. Most every 16bit operation is still valid, the number of bits shoulden't be an issue. Port IO uses the same Address and Data bus as memory IO, the only difference being the PORTIO bit is 1(not 0 like with memeory reads/writes). When A program wishes to use PORTIO it must use the out(asm) and in(asm) instructions. All other IO is done with a multitude of other instructions. This is why mmaped IO is the way togo, there are more operations one can do with one instruction. To go one more layer up we start talking about C. --- BOTOM LINE --- In C all memory access can be done with operators(like '='), wather it's a memory maped device or not. This is simply a product of the blocks on witch it's built. From C to asm to hardware buss, memory IO is not device(destination) specific. Port-io is the only other destination(port). We can change where memory IO goes by fideling with ports with our new fancy PCI bus, but this still dose not change the instructions(asm) or operators(C) that we use to access memory. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sparse and DRM on non-x86
--- Keith Whitwell [EMAIL PROTECTED] wrote: Jon Smirl wrote: On Fri, 01 Oct 2004 21:11:54 +0100, Keith Whitwell [EMAIL PROTECTED] wrote: Maybe there's a problem with terminology, but when we write to agp memory in the drivers, we are definitely using the GART. The GART is remapping your addresses, but it's still a normal system RAM access. Hmm, maybe the i8x0 is unusual. To access the GART on those systems, when internal graphics is active, you have to map an io range of the gart device. Maby IO in this case means MMIO vs PIO. I seriously doubt PIO would be used for anything other then setup and configuration/state mngmnt. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
winex: ARB_VBO and DirectX for r200 cards.
I was playing with winex, after paying for some games and a TransGaming subscription. In the cfg there are options to enable/disable the use of some OpenGL extensions, one being ARB_VBO. I saw that when using frglx there were some of these advertised by glxinfo, but not with SW/Mesa or R200/DRI. First I was wondering what it would take, as far as bribes, to get at least as far as the frglx drivers have with supporting this extension. Since I have to pay for winex... I also saw on this list that some R200 DMA memory layouts matched thoes used by DirectX and that to match the OpenGL ordering there was some swaping going on. I know the overhead is minimal, especialy with 32bit CPUs. However it would be a nice laught if OpenGL had some extentions for the CARDs idea of how things should be ordered. The idea being that any DirectX implementation for X(like winex) would not need to swap the bytes into OpenGLs prefered order when the CARD expects the data tobe in DirectX's order. __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
glxinfo: R200 VS FGLRX side by side...
I'm interested in switching back and fourth, if any one has some info on doing this better I'd like to know. Right now I'm symlinking libGL-fglrx.so.1.2 or libGL-dri.so.1.2 into libGL.so.1.2. I also have to unload and load kmods too, I do this by hand as well. I can go from DRI to fglrx fine, but to go back I have to reboot first. Here is a straigth diff, I didn't do a udiff since I think we all know the glxinfo output fairly well. I did make one change s/, $//g and s/, /\n /g. I'm also attaching the 'source'. 6a7 GLX_ARB_multisample 10,11c11,16 client glx vendor string: ATI client glx version string: 1.3 --- GLX_OML_swap_method GLX_SGI_make_current_read GLX_SGIS_multisample GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.2 12a18,20 GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_import_context 15c23,34 GLX_EXT_import_context --- GLX_MESA_allocate_memory GLX_MESA_swap_control GLX_MESA_swap_frame_usage GLX_OML_swap_method GLX_OML_sync_control GLX_SGI_make_current_read GLX_SGI_swap_control GLX_SGI_video_sync GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_visual_select_group GLX extensions: 18,20c37 GLX_ATI_pixel_format_float GLX_ATI_render_texture GLX extensions: --- GLX_EXT_import_context 23,26c40,51 GLX_EXT_import_context OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: RADEON 8500 DDR Generic OpenGL version string: 1.3.4510 (X4.3.0-3.12.0) --- GLX_MESA_allocate_memory GLX_MESA_swap_control GLX_MESA_swap_frame_usage GLX_OML_swap_method GLX_SGI_video_sync GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_visual_select_group OpenGL vendor string: Tungsten Graphics Inc. OpenGL renderer string: Mesa DRI R200 20040906 AGP 4x TCL OpenGL version string: 1.3 Mesa 6.2 27a53,54 GL_ARB_imaging GL_ARB_multisample 29,33d55 GL_EXT_texture_env_add GL_EXT_compiled_vertex_array GL_S3_s3tc GL_ARB_occlusion_query GL_ARB_point_parameters 39d60 GL_ARB_texture_env_crossbar 41a63 GL_ARB_texture_rectangle 43d64 GL_ARB_vertex_blend 47,58d67 GL_ATI_element_array GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_map_object_buffer GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_ATI_vertex_array_object GL_ATI_vertex_attrib_array_object GL_ATI_vertex_streams GL_ATIX_texture_env_combine3 GL_ATIX_texture_env_route GL_ATIX_vertex_shader_output_point_size 61a71 GL_EXT_blend_equation_separate 65a76,78 GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture 67,68c80 GL_EXT_fog_coord GL_EXT_multi_draw_arrays --- GL_EXT_histogram 70c82 GL_EXT_point_parameters --- GL_EXT_polygon_offset 75c87,88 GL_EXT_texgen_reflection --- GL_EXT_subtexture GL_EXT_texture 77,78d89 GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map 79a91 GL_EXT_texture_env_add 88,90c100,109 GL_EXT_vertex_shader GL_HP_occlusion_test GL_NV_texgen_reflection --- GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos 92c111,113 GL_NV_occlusion_query --- GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection 94c115,116 GL_SGIS_texture_edge_clamp --- GL_SGI_color_table GL_SGIS_generate_mipmap 95a118 GL_SGIS_texture_edge_clamp 97,98d119 GL_SGIS_generate_mipmap GL_SUN_multi_draw_arrays 107,126c128,143 0x25 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x26 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x27 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x28 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x29 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x2a 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x2b 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x2c 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x2d 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x2e 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x2f 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x30 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x31 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x32 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x33 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x34 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0
Re: Design for setting video modes, ownership of sysfs attributes
--- Jon Smirl [EMAIL PROTECTED] wrote: Isn't there an enviroment variable that tells what device is the console for the session? How do you tell what serial port you're on when multiple people are logged in on serial lines? The FDs 0, 1 and posibly 2 will be the console. Per posix? There should be no other ties to the current console. Right? I think this is totaly a userspace question or do we need to find out the procs console in an ioctl? On Sat, 18 Sep 2004 16:33:54 -0700, Keith Packard [EMAIL PROTECTED] wrote: Around 18 o'clock on Sep 18, Jon Smirl wrote: The sysfs scheme has the advantage that there is no special user command required. You just use echo or cp to set the mode. But it makes it difficult to associate the sysfs entry with the particular session. Seems like permitting multiple opens of /dev/fb0 with mode setting done on that file pointer will be easier to keep straight -- Jon Smirl [EMAIL PROTECTED] ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Design for setting video modes, ownership of sysfs attributes
--- Jon Smirl [EMAIL PROTECTED] wrote: You did that from an xterm, right? Which console device is the xterm running on? X starts up a process that knows which device it is running and it can remember that device since X stays running. Remember X opens the VC sepratly from it's console, hence it workes even when run from a serial or ssh terminal. Maybe the answer is that this is something for the VC layer since the VC layer stays running and knows what device it was started on. An escape sequence could query the device from the VC terminal emulator. Is there some way to figure this out from the environment? On Sat, 18 Sep 2004 21:57:32 -0400 (EDT), Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 18 Sep 2004, Jon Smirl wrote: Isn't there an enviroment variable that tells what device is the console for the session? How do you tell what serial port you're on when multiple people are logged in on serial lines? From any program you can do this: [EMAIL PROTECTED]:~$ ls -l /proc/self/fd/0 lrwx-- 1 volodya users 64 Sep 18 21:56 /proc/self/fd/0 - /dev/pts/1 So you get the pointer to the actual device stdin is associated to. -- Jon Smirl [EMAIL PROTECTED] ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Design for setting video modes, ownership of sysfs attributes
--- Jon Smirl [EMAIL PROTECTED] wrote: On Sun, 19 Sep 2004 14:45:37 +1000, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Typically, with X: We don't want X itself to have to be the one setting the mode, but rather set the mode and have X be notified properly before and after it happens so it can catch up. This is going to require some more thought. Mode setting needs two things, a description of the mode timings and a location of the scan out buffer. With multiple heads you can't just assume that the buffer starts at zero. There also the problem of the buffer increasing in size and needing to be moved since it won't fit where it is. There will be cases where there won't be enuff memory for both framebuffers. Most video cards will support power-saving modes or an off state. This can be used so that the user won't see the Framebuffer get overriten with the new data, whatever gets swaped into that memory location. Keith, how should this work for X? We have to make sure all DRI users of the buffer are halted, get a new location for the buffer, set the mode, free the old buffer, notify all of the DRI clients that their target has been wiped and has a new size. I was wanting to switch mode setting into an atomic operation where you passed in both the mode timings and buffer location. I think it would work best if the buffer where setup/maped/allocated(in revers order), then the call to program the DAC. It dosen't make any differance if it is attomic, worst case the user will just see trash. -- Jon Smirl [EMAIL PROTECTED] --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Design for setting video modes, ownership of sysfs attributes
--- Felix Kühling [EMAIL PROTECTED] wrote: On Sun, 19 Sep 2004 12:46:13 -0400 Jon Smirl [EMAIL PROTECTED] wrote: On Sun, 19 Sep 2004 14:45:37 +1000, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: One issue here... When we discussed all of this with Keith, we wanted a mecanism where the user can set the mode without owning the device. The owning part is for multiuser systems. If I have four users logged into the same system I have to assign them ownership of their video devices so that they can't mess with each other. I want to avoid needing root priv to change the monitor mode. Typically, with X: We don't want X itself to have to be the one setting the mode, but rather set the mode and have X be notified properly before and after it happens so it can catch up. This is going to require some more thought. Mode setting needs two things, a description of the mode timings and a location of the scan out buffer. With multiple heads you can't just assume that the buffer starts at zero. There also the problem of the buffer increasing in size and needing to be moved since it won't fit where it is. Keith, how should this work for X? We have to make sure all DRI users of the buffer are halted, get a new location for the buffer, set the mode, free the old buffer, notify all of the DRI clients that their target has been wiped and has a new size. Sounds a lot like moving and resizing GL windows in X. A similar (if not I'd like to point out that this is not smooth on my system, exept for when using fglrx. When I move, or resize, a DRI window I get vary noticable(more then 10th second) stoped system, mouse updates aren't even recorded. the same mechanism) could be used here. Whenever a client takes the lock and detects that someone else had the lock in the mean time it checks for a new window position and size. Checking for a changed mode or frame buffer layout would fit in nicely. AFAIK these kind of changes are communicated through the sarea which is shared by all DRI clients, the Xserver and the kernel driver, so the checks are pretty low cost (no system calls or context switches required). You only have to take the lock before changing the mode. DRI clients and X will detect the change when they take the lock the next time and adjust to the new conditions. I was wanting to switch mode setting into an atomic operation where you passed in both the mode timings and buffer location. -- Jon Smirl [EMAIL PROTECTED] | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Design for setting video modes, ownership of sysfs attributes
--- Jon Smirl [EMAIL PROTECTED] wrote: Original proposal. At OLS we talked about a system like this for setting video modes: 1) user owns graphics devices 2) user sets mode with string (or similar) format using ioctl common to all drivers. 3) driver is locked to prevent multiple mode sets 4) common code takes this string and does a hotplug event with it. 5) hotplug event runs root context in user space 6) mode is decoded and verified, this may involve a little process that maintains the DDC database and reads a file of legal modes. Other schemes are possible. 7a) mode is set using VBIOS and vm86, signal driver mode is set 7b) the register values needed to set the mode are passed into a root priv ioctl. 8) driver is unlocked. In this model all of the verification happens in user space. If you want to set modes other than the ones from DDC you have to add them to the config file. There is no need for DDC support and mode verification in the kernel. To give credit this is Alan Cox's design. - I'm now starting to implement this design. Would it be better to set the mode via sysfs attributes? This would allow mode settting with something like: echo 'my mode string' /sys/class/drm/card0/mode A list of available modes could be in /sys/class/drm/card0/modes This is intersting... I'd like to know how you plan to use VCs? That is more then one tty sharing the same monitor. I'd also like to see VCs able to change modes while not being active, thought I can't imagin how one would plan todo this /wo blocking. I don't see any good reason why it can't be an ioctl, you can have the same exe/bin/app handle BOTH the user and root parts of the mode change. This way it can keep a cache of things, like modes that will currently not be valid. Can PAM change the ownership of a sysfs attribute/directory on login? For this to work logging in needs to assign you ownership of the attribute since you want to be able to change it but not anyone else. DRM may need to assign the ownership of multiple attributes, is this easy to do? How are errors going to be communicated in this scheme? I can cat the sysfs mode variable to get a status. Is there a good way to do this without polling? If the sysfs scheme doesn't work mode setting will need to be an IOCTL with a small program since PAM can change the ownership of the DRM device. The sysfs scheme has the major advantage of avoiding the need for the small program. There is another thing I can't see. Why can't the module for the drm create fb[0-9]* devices, one for each monitor? This would seam to solve the problem with having another app and ioctl(API). If we go the sysfs route what is BSD going to do, will we have to build parallel implementations? -- Jon Smirl [EMAIL PROTECTED] --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Design for setting video modes, ownership of sysfs attributes
--- Jon Smirl [EMAIL PROTECTED] wrote: On Sat, 18 Sep 2004 12:58:07 -0700 (PDT), Mike Mestnik [EMAIL PROTECTED] wrote: This is intersting... I'd like to know how you plan to use VCs? That is more then one tty sharing the same monitor. I'd also like to see VCs able to change modes while not being active, thought I can't imagin how one would plan todo this /wo blocking. I don't see any good reason why it can't be an ioctl, you can have the same exe/bin/app handle BOTH the user and root parts of the mode change. This way it can keep a cache of things, like modes that will currently not be valid. VCs should be dealt with at a higher layer. This higher layer would track what mode is on each virtual console and set it back after console swap. The VC code would provide it's own sysfs mode attribute in the VC's sysfs entry. A VC layer may suppress direct access to the head specific mode attribute. This brings up a question, how do I know which sysfs VC entry corresponds to the one I'm logged into? In this(the above) model this may work. How will Xorg handle VT swaps in the above model? I'm trying to allow for a user space VC implementation at some point in the future so I don't want to build assumptions about a kernel space VC implementation into the code. That seams like a good plan, thought current user space multi-'screen' implementations leave much too desier. 'detachtty' seams like the best one, but it dosen't directly support switching tasks. Befour this idea will get off the ground a good system too handel this in userspace is needed, I think. I don't think that this app/daemon would have anything todo with mode setting or video drivers, exept the console drivers allready provided by most OSs. The sysfs scheme has the advantage that there is no special user command required. You just use echo or cp to set the mode. We allready have programs that change the video mode. It's true thay lack support for some things, but I can't see the harm in adding on to existing mode-setting programs. If that's not good enuff there's no reason that the userland hotplug script/program can't also provide these features if called by a non-root user. If called by root, it just dose what it's told /wo the hp or mode setting ioctl. I'm still undecided if there needs to be a root priv daemon caching the EDID and polling for a monitor change. EDID can be regenerated on each request to change mode but it takes a few seconds. The root priv daemon will dynamically link to card specific libraries. Initially I'm going to add the functions to the mesa libraries but they may get broken out later. /etc/mtab is a good concept, you might want to put this some where in /var thought. Then there's no need to TSR. There is another thing I can't see. Why can't the module for the drm create fb[0-9]* devices, one for each monitor? This would seam to solve the problem with having another app and ioctl(API). The DRM driver I'm working on already creates one DRM device for each head. Doing this also creates a sysfs entry for each head too. Each head has it's own mode/modes attributes. So can we link fb to drm, for compatibility reasons? Another item is merged fb. Initially heads will be unowned. Logging into a head makes you the owner. If you ask for the modes available on your head the list will also contain merged fb mode. If you set a merged fb mode, the login process on the secondary screen needs to be killed. If some one is logged into the secondary head merged fb modes won't be in the list. This scheme has the nice side effect of making all heads equal, there is no separate controlling device for the card. I don't see this as more then a fue more ioctls or rather just appending some data on the end of existing structures to say what location/framebuffer to attach too or create. The other code has tobe done no matter what. -- Jon Smirl [EMAIL PROTECTED] ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Permanent maps and hardware detection
--- Felix Kühling [EMAIL PROTECTED] wrote: Hi Jon, I'm going to start writing the code for permanent maps in the Savage driver now. I'm becoming aware of the practical problems now and I'd like to know if my understanding is correct so far. The first problem I have is that I need to find out the size of the video memory in order to create the framebuffer map correctly. Since permanent maps are supposed to be created when the driver is loaded in the preinit or postinit hooks, X can't provide that information in the init ioctl. So I'll have to copy some pretty magic (to me at least) code from the DDX to the kernel driver in order to do the hardware and video memory detection. The code in the Savage DDX uses MMIO register access in order to find out the amount of video ram. This means I'll have to enable MMIO in the kernel driver now. I hope that won't interfere with the DDX driver that probably expects MMIO to be disabled when it is first loaded. Would putting the card back the way it was b4 you where loaded be an OK solution, this will allow othere(some being non-open) software too still work. I havn't found any example of a driver using permanent maps in the current DRM sources. You referred to the radeon driver sometimes, but the only thing I could find was a comment above radeon_preinit. Grep doesn't find any call to initmap in any of the drivers. Is this something you forgot to commit? I'd really like to take a look at an example, since this is the first time I'm working with a DRM driver. Regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
--- Keith Whitwell [EMAIL PROTECTED] wrote: Vladimir Dergachev wrote: Alan, I would like to disagree with you. On Fri, 10 Sep 2004, Alan Cox wrote: On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote: If the kernel developers can address this point I would be most interested, in fact I don't want to hear any more about sharing lowlevel VGA device drivers until someone addresses why it is acceptable to have two separate driver driving the same hardware for video and not for anything else.. (remembering graphics cards are not-multifunction cards - like Christoph used as an example before - 2d/3d are not separate functions...)... We've addressed this before. Zillions of drivers provide multiple functions to multiple higher level subsystems. They don't all have to be compiled together to make it work. 2D and 3D _are_ to most intents and purposes different functions. They are as different as IDE CD and IDE disk if not more so. Functions - yes, but they become such only at a higher level. 3d for example does not really exist in kernel in any form. I would like to see unified fb (or the hardware-specific part of fb) and drm for one simple reason that I think you mentioned: One driver per device. I.e. one driver per *physical* device. Lastly, one point that you appear to have missed: DRM does DMA transfers (among everything else). FB sets video modes - i.e. messes with PLL. The problem is that there are configurations where messing with PLL while a DMA trasfer is active will lock up PCI (or AGP) bus hard. For example, a video decoder can be clocked off pixel clock for video pass through mode. If we trasfer video data to main RAM at the same time and FB gets a command instructing it to change resolution there would be a hard lockup. I can see this being the case, but why can't fb just using existing drm interfaces to achieve device quiescence before touching the PLL's? I can see the problem here... This happens with old(current) gatos and fglrx. Where DRI sets up some state in the card and then dosen't clear it after being unloaded. This leaves the card in an unknowen state that gatos or fglrx dosen't know any thing about. What will happen is that when the FB or DRM turns on a new feature the other driver MAY need to be aware of the change. This would imply that we must now version as if there where an ABI. The REAL problem is that the ABI is all in hardware! The bottom line is that nether of these drivers SHOULD assume that the other won't change the way it uses the card, thus forcing a bianary compatability issue. Keith --- 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 __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- 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: radeon-pre-2
--- Christoph Hellwig [EMAIL PROTECTED] wrote: If the kernel developers can address this point I would be most interested, in fact I don't want to hear any more about sharing lowlevel VGA device drivers until someone addresses why it is acceptable to have two separate driver driving the same hardware for video and not for anything else.. (remembering graphics cards are not-multifunction cards - like Christoph used as an example before - 2d/3d are not separate functions...)... Well, Alan's proposal gets things back into a working shape with both fbdev and get additional benefits like hotplug and autloading without a major revamp of everything. The major rework will have to happen sooner or later anyway, but by fixing the obvious problems we face now first it can be done in small pieces and with far less pressure. Not to step on toes, but... From what I can tell the idea is to add code into FB that calles functions in the DRM and vice vers. This would seam to add another ABI. Unless the code gets linked into one module, this idea has been flamed and killed already. I would be willing to bet that if some one did this, into one module, it would be exepted by all. However I don't see why we can't add multi-head support, posibly at the same time? -Since Joe seams so willing to do this, why not let him. --- 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 __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- 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: radeon-pre-2
--- Alan Cox [EMAIL PROTECTED] wrote: On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote: Lastly, I am not saying you have to put all the code in the same file. All I am saying we can mandate that all Radeon HW specific code is linked in one module - and this would make things easier for developers. And if I want dri but not frame buffer, or vice versa, as the majority of current users do Hopefully any change to the kernel will allow building FB without DRM. This is a trivial seperation of code, that I might add has allready been done, a good point that we should keep it this way. Yes, there will be some new memory mngmt code, posibly optonal as well, that is needed for multi-headed setups. I would agree that this can be coded as well - but why bother ? Or is it done and working already ? Splitting the modules up is the easy bit. The API is the hard bit so you might as well formalize it. It also gives the users the ability to not load huge radeon modules. --- 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 ___ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com --- 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
drm_bufs.h: order as an OS specific way of computation?
What would be the method for submiting a patch to to move this into
non-OS_specific code?
Here is the current diff from Linux to BSD...
-/**
- * Compute size order. Returns the exponent of the smaller power of two
which
- * is greater or equal to given number.
- *
- * \param size size.
- * \return order.
- *
- * \todo Can be made faster.
+
+/*
+ * Compute order. Can be made faster.
*/
int DRM(order)( unsigned long size )
{
int order;
unsigned long tmp;
- for (order = 0, tmp = size 1; tmp; tmp = 1, order++)
- ;
+ for ( order = 0, tmp = size ; tmp = 1 ; ++order );
- if (size (size - 1))
+ if ( size ~(1 order) )
++order;
return order;
}
Aside from copying the doxygen it would be nice the spellout where the
name 'order' came from and what it means. Do these functions still
compute the same value and can the changes be synced?
___
Do you Yahoo!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool
---
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: [BUG] r200 dri driver deadlocks
--- Felix Kühling [EMAIL PROTECTED] wrote: On Sun, 05 Sep 2004 20:14:43 -0400 Lee Revell [EMAIL PROTECTED] wrote: On Sun, 2004-09-05 at 16:18, Patrick McFarland wrote: [snip] That shouldn't matter, should it? The userland stuff should never lock the machine up. I'll test it anyhow, though. No, it shouldn't. Anything that directly accesses hardware belongs in the kernel. How to fix this is a pretty hot topic now. That's not the whole truth. There are just too many ways to lock up those 3D chips. For instance I fixed a lockup in the r100 driver where the order in which state changing commands were sent to the hardware would cause a lockup. Each individual state changing command is perfectly valid. Finding all permutations that trigger a lockup would have been too much of a hassle and may not even have been true for all supported hardware out there. So we made the user-space driver emit state changing commands in a fixed order, which seems to work everywhere. Dose the DRM varify that the cmds are in this order? Why not just have the DRM 'sort' the cmds? A simple bouble sort would have no more overhead then the check for correct order, but it would fix missordered cmd streams. Once this is done the statement holds true, userland stuff should never... Regars, Felix Lee | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail --- 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=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG] r200 dri driver deadlocks
Most IMPORTANT is that some-one some-where there is a list of ALL of these. These are best in the form of code comments so the the respective places in the code can be changed. --- Dave Airlie [EMAIL PROTECTED] wrote: Dose the DRM varify that the cmds are in this order? Why not just have the DRM 'sort' the cmds? A simple bouble sort would have no more overhead then the check for correct order, but it would fix missordered cmd streams. Once this is done the statement holds true, userland stuff should never... Feel free to implement it and profile it, but there are so many ways to lock up a radeon chip it is scary, the above was just one example, some days if you look at it funny it can lockup :-), it is accepted that userland can crap out 3D chips, the Intel ones are fairly easy to hangup also.. I'd love to, where do I start? The problem he is that I have no-idea... 1. What values I'd neet to test for and sort. 2. The order of the sorting(probly documented in DRI-client code). 3. Where in the DRM I can proform the needed test and sort. I would also love a list of ALL of these so I can fix them one by one. A good project for a new DRI developer, no. Dave. __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail --- 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=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG] r200 dri driver deadlocks
Sorry, I don't know why we are cross posting and including subscribers in CC. This belongs on the DRI list, as it is only with 3rd party DRI-client code that the problem exists. --- Dave Airlie [EMAIL PROTECTED] wrote: On Tue, 07 Sep 2004 09:07:11 +0200, Arjan van de Ven [EMAIL PROTECTED] wrote: On Tue, 2004-09-07 at 08:54, Dave Airlie wrote: Feel free to implement it and profile it, but there are so many ways to lock up a radeon chip it is scary, the above was just one example, some days if you look at it funny it can lockup :-), it is accepted that userland can crap out 3D chips, the Intel ones are fairly easy to hangup also.. hmmm.. I thought the entire reason for having part of DRM in the kernel was to be able to prevent such events from happening only one reason... http://dri.sourceforge.net/doc/drm_low_level.html But to be honest the chips are entirely capable of locking up on what the docs say are valid things, writing enough workarounds and test would bloat the drm considerably, at the moment we try and have it so a valid OpenGL application doesn't lock it up, but someone writing directly to the DRM would be able to lockup a fair few chips in many interesting ways Dave. --- Roland Scheidegger [EMAIL PROTECTED] wrote: I seriously doubt this is doable. Unless you put the whole driver in the kernel, which of course nobody wants. I frequently caused gpu lockups by experimental driver changes (for instance, wrong vertex setup). I think the consensus was that it's ok for the driver to lock up the gpu, but it should not lock up the kernel. It might be possible to prevent lockups by a watchdog, resetting the gpu if a lockup is detected. This is how ATI deals with lockups in windows (dubbed VPU Recover), and there is a patch floating around for DRI too (though it is not exactly for that, and doesn't always work). Roland It's a simple matter of enforcing 3rd party(this means every DRM user) clients to use DRI's *dialect or style*. If the DRM see activities that are not expected to be generated by pure DRI-clients, action should be taken to prevent a posible lockup. This means that even valid activities should be treated as invalid IF the DRM can clerly detect a deviation from pure DRI-client activities. For example, pure DRI-clients emit state changing commands is a vary specific order. The DRM could easily spot if these cmds where out of any knowen/used order or if any other cmds where also inserted into the expected order. This should be denied. Only DRI-clients(any client) using the DRI supplied order(the one used by pure DRI-clients) should be allowed to access the hardware. __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail --- 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=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cond_resched: DRM Patch.
Read my comment at the end where iritations not time should be passed to this macro. The time we set is allways '1'. --- Francois Romieu [EMAIL PROTECTED] wrote: Mike Mestnik [EMAIL PROTECTED] : [DRM_UDELAY patch] Does actually a DRM_UDELAY(d) with d 100 appear somewhere in the sources ? -- Ueimor __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- 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=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
cond_resched: DRM Patch.
Coulden't cause DRI/DRM to break on my non-SMP radeon preempt system.
Could this be commited, in one form or another?
cvs diff: Diffing .
Index: drm_os_linux.h
===
RCS file: /cvs/dri/drm/linux/drm_os_linux.h,v
retrieving revision 1.21
diff -u -r1.21 drm_os_linux.h
--- drm_os_linux.h 27 Aug 2004 09:11:06 - 1.21
+++ drm_os_linux.h 29 Aug 2004 21:39:47 -
@@ -14,7 +14,17 @@
#define DRM_ERR(d) -(d)
/** Current process ID */
#define DRM_CURRENTPID current-pid
-#define DRM_UDELAY(d) udelay(d)
+extern int panic_timeout;
+#define DRM_UDELAY(d) do { \
+ if (!panic_timeout) { \
+ cond_resched(); \
+ if (d 100) \
+ msleep(d); \
+ else \
+ udelay(d); \
+ } else \
+ udelay(d); \
+} while (0)
/** Read a byte from a MMIO region */
#define DRM_READ8(map, offset) readb(((unsigned long)(map)-handle) +
(offset))
/** Read a word from a MMIO region */
The msleep will never be trigered, cause 'd' is time( == 1) not
iritations( == i). This should be fixed in the code that uses DRM_UDELAY,
and maby a name change too.
___
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
---
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=5047alloc_id=10808op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm patch
Not to be a nit prick, but shoulden't there at least be a warning that
VesaFB and the DRM are using the same Hardware? Thought this is
supported.
Warning: VesaFB and the DRM are using the\n
same Hardware, Thought this is supported.
--- Jon Smirl [EMAIL PROTECTED] wrote:
Here is the current version of the patch. As soon as Dave approves it
will go in.
The problem was a conflict between VesaFB and DRM. The patch detects
VesaFB and puts DRM in stealth mode.
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail = linux/drm_drv.h 1.9 vs
edited =
--- 1.9/linux/drm_drv.h Wed Aug 25 16:55:12 2004
+++ edited/linux/drm_drv.hThu Aug 26 00:40:06 2004
@@ -602,7 +602,7 @@
static int __init drm_init( void )
{
struct pci_dev *pdev = NULL;
- struct pci_driver *pdriver = NULL;
+ struct pci_device_id *pid;
int i;
DRM_DEBUG( \n );
@@ -613,25 +613,39 @@
DRM(mem_init)();
- for (i=0; DRM(pciidlist)[i].vendor != 0; i++) {
- pdev = pci_get_subsys(DRM(pciidlist[i]).vendor,
DRM(pciidlist[i]).device, DRM(pciidlist[i]).subvendor,
DRM(pciidlist[i]).subdevice, NULL);
- if (pdev)
- {
- pdriver = pci_dev_driver(pdev);
- if (pdriver)
- {
- DRM(fb_loaded)=1;
- drm_probe(pdev, DRM(pciidlist[i]));
- }
- else
+ for (i=0; (DRM(pciidlist)[i].vendor != 0) !DRM(fb_loaded); i++) {
+ pid = DRM(pciidlist[i]);
+
+ /* pass back in pdev to account for multiple identical cards */
+ while ((pdev = pci_get_subsys(pid-vendor, pid-device,
pid-subvendor, pid-subdevice, pdev))) {
+ /* is there already a driver loaded, or (short circuit saves
work)
*/
+ /* does something like VesaFB have control of the memory
region? */
+ if (pci_dev_driver(pdev) || pci_request_regions(pdev, DRM
scan)) {
+ /* go into stealth mode */
+ DRM(fb_loaded) = 1;
pci_dev_put(pdev);
+ break;
+ }
+ /* no fbdev or vesadev, put things back and wait for normal
probe */
+ pci_release_regions(pdev);
+ pci_dev_put(pdev);
}
}
- if (DRM(fb_loaded)==0)
+ if (DRM(fb_loaded) == 0)
pci_register_driver(drm_driver);
- else
+ else {
+ for (i=0; DRM(pciidlist)[i].vendor != 0; i++) {
+ pid = DRM(pciidlist[i]);
+
+ /* pass back in pdev to account for multiple identical cards */
+ while ((pdev = pci_get_subsys(pid-vendor, pid-device,
pid-subvendor, pid-subdevice, pdev))) {
+ /* stealth mode requires a manual probe */
+ drm_probe(pdev, DRM(pciidlist[i]));
+ }
+ }
DRM_INFO(Used old pci detect: framebuffer loaded\n);
+ }
return 0;
}
___
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
---
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: 2.4.8.1+P6: radeon, dri xruns
I guess I don't understand, the article said the sound(OSS) took the BKL? It didn't say that ALSA's OSS is effected, I'm assuming that it is not. In any case ALSA still uses ioctls. So no mater what sound takes the BKL and disables preemption? I don't think that preemption could work at all, unless when the BKL is [1]droped you preemptate. I think you have something wrong, as DRI dose these things alot so it might not block preemption. 1. msleep, usercpy, ect. --- Lee Revell [EMAIL PROTECTED] wrote: On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: Michel pointed out that all IOCTL calls hold the big kernel lock. Releasing this lock is sure to case problems since the DRM code is not designed to be reentrant. I don't know what it will take to fix locking to allow this, maybe one of the original DRM authors will pop in here with the answer. Until locking is adjusted we can't add the schedule call. From what I'v read, http://lwn.net/Articles/86859/, it's not a global kernel lock (I.E. it dosen't stop non-locked kernel code from running). So the only reason it effects audio performace is that well, read the article :) The reason the BKL affects audio performance is that taking the BKL disables preemption. Lee --- 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 __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail --- 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=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
--- Lee Revell [EMAIL PROTECTED] wrote: On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: Michel pointed out that all IOCTL calls hold the big kernel lock. Releasing this lock is sure to case problems since the DRM code is not designed to be reentrant. I don't know what it will take to fix locking to allow this, maybe one of the original DRM authors will pop in here with the answer. Until locking is adjusted we can't add the schedule call. From what I'v read, http://lwn.net/Articles/86859/, it's not a global kernel lock (I.E. it dosen't stop non-locked kernel code from running). So the only reason it effects audio performace is that well, read the article :) The reason the BKL affects audio performance is that taking the BKL disables preemption. But ONLY while your not sleeping. Lee __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- 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: Proper way of implementing context switches....
--- Eric Anholt [EMAIL PROTECTED] wrote: On Mon, 2004-08-23 at 15:24, Ian Romanick wrote: Thomas Hellström wrote: As some of you might have read on another thread, there is a discussion how to handle the X server (and possibly other) 2d contexts in the via / unichrome family of drivers that expects certain 2d engine register values to stay the same even when other contexts or DMA commands have played. Looking at the now obsolete gamma driver and ffb_context.c, some register values are saved at context switches whereas in other drivers this does not seem to happen. What is the common practice? That all clients always reinitialize the engines every time they are used or that the drm saves the registers that are commonly used by different clients as part of the context switch? The common practice is to define a set of register groups, and define a bit mask for with 1 bit per group (usually called dirty bits). When a context gets the hardware lock, it checks to see if any other context has held the lock since the last time it held it. If another context has, it looks at the bit mask (stored in the SAREA). Any set dirty bits mean the some other context modified some register in that group. The dirty register(s) is then reset to the value expect by the context now holding the lock. Another way is what the radeon/r200 drivers do: When you grab the lock from someone else, *all* state is dirty. You can see an example in radeon_dri.c. When we grab the lock, we mark the 3d state invalid so that the next use of it (Render acceleration) resets it all. To be totally correct, in my opinion, the EnterServer for Radeon should be resetting some of the 2d state that it depends on, as well. As it is, it looks like if someone wanted to set things like the default offset in the 3d driver, they'd have to update the 2d driver to reset it when grabbing the lock, bump the DDX version, and check for that version in the 3d driver and deal with it appropriately. Are there alot of registers, more then 300? If not why would they be broken up into groups, I'm guessing each function/group only has 7 to 10 registers. It seams like you would wast more cycles on conditional jumps then on just pushing the state. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- 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 __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail --- 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: 2.4.8.1+P6: radeon, dri xruns
--- Jon Smirl [EMAIL PROTECTED] wrote: Michel pointed out that all IOCTL calls hold the big kernel lock. Releasing this lock is sure to case problems since the DRM code is not designed to be reentrant. I don't know what it will take to fix locking to allow this, maybe one of the original DRM authors will pop in here with the answer. Until locking is adjusted we can't add the schedule call. From what I'v read, http://lwn.net/Articles/86859/, it's not a global kernel lock (I.E. it dosen't stop non-locked kernel code from running). So the only reason it effects audio performace is that well, read the article :) Also DRI allready runes with it off in ioctls, every time there is a sleep. This is why DRI has spinlocks, right? Now if we turn BKL off for our ioctls we defeat the pupose it was turned on for, what is that? Would it be posible to use differed execution instead of blindly droping the BKL? As for the other DRI-spinlocks the code presented by Ingo Molnar lookes correct, no arguments here. I just don't see why DRI needs to drop the BKL any sooner then any other part of the kernel? After all DRI dosen't request it, it's just one of many victums of the ioctl BKL. So I think it would be best to let upstream fix the DRI BKL problem. --- Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] wrote: On Fri, 2004-08-20 at 22:59, Jon Smirl wrote: I don't believe the DRM drivers are holding any global kernel locks when they do wait_for_fifo. Any locks held would be internal to DRM and can be changed if needed. There must be a lock. I used to use a patch that I found somewhere (that does conditional reschedules), but it triggers the scheduling while lock held kernel oops if you enable that option in the kernel configuration. -- Fernando --- Lee Revell [EMAIL PROTECTED] wrote: On Sat, 2004-08-21 at 01:29, Jon Smirl wrote: What's the right way to write a loop like this that meets the above requirements and also satisfies the audio needs? I think it depends on which locks you are holding, and what kind of locks they are. Lee = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- 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 __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail --- 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: 2.4.8.1+P6: radeon, dri xruns
--- Ingo Molnar [EMAIL PROTECTED] wrote:
* Jon Smirl [EMAIL PROTECTED] wrote:
--- Ingo Molnar [EMAIL PROTECTED] wrote:
the cleanest and highest performing solution would be to have an
interrupt source for 3D completion - do you have such an interrupt
handler handy? If yes then you can sleep precisely up to completion:
Interrupts are not a good solution. The hardware would generate
millions of them per second. This is the same problem network cards
have, you can interrupt the machine to death.
you'd only have to enable interrupt generation when you are not
busy-polling. In 99.9% of the cases (when !need_resched()) you could
busy poll as much as you want, and keep IRQ generation off. Very likely
IRQ generation can be turned on/off via a single PCI write on most 3D
hardware. Anyway, IRQ generation would just be a 'nice' thing. But the
following property is a must:
This lookes like a great idea. We turn on interrupt generation just after
we drop our spinlock(in the if need_resched() block). This would greatly
improve system proformance as IRQs would only be used when we wait for
long periods.
I would expect the best solution is to make a few passes through the
loop delaying a couple usec to catch the common case of quick
completion. Then switch to doing need_resched().
no. If need_resched() is set then the code *must* try to schedule ASAP.
There is no excuse for not doing so - 'performance will suffer' is not a
correct argument becase _if_ need_resched() is true then the system (and
the user) doesnt want the 3D app to run right now. There will be no
performance difference to the 3D app, since by having high latencies the
DRI code does not give any extra performance to 3D apps, it only
increases the scheduling latency! The timeslices of the 3D app are used
up depending on how long the 3D app runs - so if it burns cycles
busy-polling it will in fact get less CPU time on average. (if the CPU
is contended.)
I see jerky ness alot with Q3, where frame rate spikes for one frame.
This lookes like a good explination, as the frame b4 and after would have
many of the same GL calls.
End Of Line.
Anyway, need_resched() set is not a common condition, and if it happens
then kernel code _must_ react. (In fact most kernel code will be
preempted right away - but the DRI code runs under spinlocks.)
So the correct solution is to add something like this to _at least_ the
busy-polling code:
if (need_resched()) {
... drop locks ...
cond_resched();
... reacquire locks ...
}
or, if there's a single spinlock held (the BKL doesnt count) then:
cond_resched_lock(driver-lock);
(but the locking obviously has to be correct and safe.)
ok?
Ingo
---
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
__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
---
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: [Xorg] Any patches for X.Org release?
--- Dave Airlie [EMAIL PROTECTED] wrote: Can the VIA DRI stuff get pushed through to the kernel with the S3 stuff please, even if we mark VIA as experimental the DRM stuff? We need to mark as insecure, I really don't want anything that the authors consider insecure to go anywhere outside the DRM... Just for calarity. The DRM stuff is insecure, it should not go anywhere outside CVS. If it allows the user to control the PCI bus mastering registers we can't really put it in the kernel... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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 __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail --- 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: dri/sparc64 status
Yes, it is posible. However my Ultra5 only has 4MB video ram(this MUST be wrong) detected by XFree86. Also I don't know how or why but XFree86 insinsts on not EVER changing the video resolution, thought it is posible to change the number of colors and use VirtualDesktop space. So if I made sure to tell the openprom to boot in a low resolution mode I could get DRI to work, thought I think 1024x768 is small enuff and I still need like 16k more memory to turn on DRI with 8bpp. This post is to make the dri-devel archive more complete. --- Stilgar [EMAIL PROTECTED] wrote: Hello, I've noticed you're trying to make DRI work on sparc64 hardware. I'm thinking of buying an Ultra5 or Ultra10 to do some OpenGL. I don't know what kind of hardware you've got, and how far you made it... Someone I know on freenode told me it was possible to build dri and get the U5's onboard framebuffer to work with it. Any pointers / information ? Stilgar ___ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Toutched registeres, and other state, are not poped at exit.
I have had this problem B4 with gatos, loading DRI then gatos crashed. Now I have the same problem with Debian's xserver-xfree86. I can run my r200 in MergedFB mode then xinermia. After finding that nether had ForceMinDotClock I switched to Debian's 2D driver. My system froze like a box of chocolates. After reboting Debian's 2D driver worked fine. This all goes back to needing 'one' device driver, but can be fixed/bypased if all device drivers play nice(DRI dose not/has not). __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- 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
DRI: Still not working on Sparc(Mach64).
I have an SUN-Ultra10 with a built in mach64. The one thing hanging me up is getting an Xserver that will load the DRI(ver). I have built the DRIver from the Mesa tree and the DRM as well. These by them selves seam to be in good order and loadable. However the only Xserver I can build is Debian's Xfree86(4.3.0.dfsg.1-6). I have also tryied to use xserver-xfree86-dri-mach64(2003.05.04-1) with broken/old ABI support. This is what I get trying to build DRI's Xserver(make World). As I understand it sparc asm support is only for solaris at this time. I was able to fix all the header problems but then the build stoped on the old global register problem. sparc.c:32:21: context.h: No such file or directory sparc.c:33:26: math/m_xform.h: No such file or directory sparc.c:34:27: tnl/t_context.h: No such file or directory sparc.c:35:19: sparc.h: No such file or directory sparc.c:72: error: parse error before '*' token sparc.c:72: warning: function declaration isn't a prototype ... make[6]: *** [sparc.o] Error 1 make[6]: Leaving directory `/root/xfree86/xc/lib/GL/mesa/sparc' make[5]: *** [all] Error 2 __ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ --- 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: ltrace: Logging openGL calls.
I found this cool program ltrace that I have tested on glxgears... gettimeofday(0xb7e8, 0xb7f0) = 0 XPending(0x804c008, 0x322, 0, 0x4014, 0xcccd) = 0 glClear(16640, 0xb850, 0xb7f8, 0x4018ed28, 0) = 0x8004 glPushMatrix(16640, 0xb850, 0xb7f8, 0x4018ed28, 0) = 0x806a0b0 glRotatef(0x41a0, 0x3f80, 0, 0, 0) = 0x3f80 glRotatef(0x41f0, 0, 0x3f80, 0, 0) = 0x3f80 glRotatef(0, 0, 0, 0x3f80, 0)= 0x8054020 glPushMatrix(0, 0, 0, 0x3f80, 0) = 0x806a160 glTranslatef(0xc040, 0xc000, 0, 0x3f80, 0) = 0x8069fb0 glRotatef(0x4500e000, 0, 0, 0x3f80, 0) = 0x3f80 glCallList(1, 0, 0, 0x3f80, 0) = 0 glPopMatrix(1, 0, 0, 0x3f80, 0) = 0x806a000 glPushMatrix(1, 0, 0, 0x3f80, 0) = 0x806a160 glTranslatef(0x4046, 0xc000, 0, 0x3f80, 0) = 0x8069fb0 glRotatef(0xc5812800, 0, 0, 0x3f80, 0) = 0x3f80 glCallList(2, 0, 0, 0x3f80, 0) = 0 glPopMatrix(2, 0, 0, 0x3f80, 0) = 0x806a000 glPushMatrix(2, 0, 0, 0x3f80, 0) = 0x806a160 glTranslatef(0xc046, 0x4086, 0, 0x3f80, 0) = 0x8069fb0 glRotatef(0xc581a800, 0, 0, 0x3f80, 0) = 0x3f80 glCallList(3, 0, 0, 0x3f80, 0) = 0 glPopMatrix(3, 0, 0, 0x3f80, 0) = 0x806a000 glPopMatrix(3, 0, 0, 0x3f80, 0) = 0x806a000 glXSwapBuffers(0x804c008, 0x322, 0, 0x4014, 0xcccd) = 0x8004 gettimeofday(0xb7e8, 0xb7f0) = 0 XPending(0x804c008, 0x322, 0, 0x4014, 0xcccd) = 0 --- Daniel Vogel [EMAIL PROTECTED] wrote: could you please enlighten us which code path UT2003/2004 use on r200/rv250 when firing the 'Shock Rifle'? The engine doesn't have a special code path per weapon effect but rather relies on a material system artists use to come up with materials used for visual effects that then get translated to the fixed function pipeline with varying amount of passes depending on HW capabilities. One/two texture units? Sorry, I don't know. I suggest you create a small cube test level in UnrealEd, disable the HUD (killall HUD) and first person weapon (either show gun or show weapon - forgot which one), give yourself all weapons (loaded), switch to the shock rifle, log the number of primitives rendered for each DrawArrays or whatnot call and then change the driver code to create a snapshot of the current state on other calls (aka when you fire the gun). Alternatively you could change the driver to force synchronization after each rendering call and dump the current state if you detect the card doesn't respond. Dunno how feasible this is with R200 but it should definitely work with R300. -- Daniel, Epic Games Inc --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 driver crashes
What good is 1/3 FPS?? The OpenGL implem. needs to have some sort of accountability in not supporting an operation if there are not enuff resources. I would have to point out that if it's not feasable to accomplish a task in less then 3 seconds that maby there needs to be more resources. --- Michel Dänzer [EMAIL PROTECTED] wrote: On Sat, 2004-07-03 at 00:51 +0200, Dieter Nützel wrote: Am Freitag, 2. Juli 2004 18:55 schrieb Michel Dänzer: On Fri, 2004-07-02 at 18:46 +0200, Dieter Nützel wrote: Run gltestperf on r200. http://marc.theaimsgroup.com/?l=dri-develm=108213539614605w=2 Benchmark: 2 ZSmooth Triangles Current size: 480 Elapsed time for the calibration test (341): 2.003000 Selected number of benchmark iterations: 851 Elapsed time for run 0: 15.413000 Elapsed time for run 1: 15.377000 Elapsed time for run 2: 15.303000 r200WaitIrq: drmRadeonIrqWait: -16 ZSmooth Triangles Maybe a starting point? The same symptom doesn't necessarily mean it's the same problem. This is a common symptom after the chip has locked up, but IIRC that's not the case for you? True. But maybe a starting point? Or maybe gltestperf simply queues commands which take longer than the drmRadeonIrqWait() timeout (3 seconds IIRC)? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Nothing written to snort logfiles
Too be honest, I don't know anything about snort. :) I just was looking at another users snort.conf cause of the strange error he posted and saw the coding problem via the source(AKA force). --- James Sinnamon [EMAIL PROTECTED] wrote: Mike, Thanks for the information and the useful regexp. I can't quite work out what was happening yesterday. I think I removed any /^#.*\\$/ lines which were intermingled between one line with a continuation character and its continuation line. As I wrote on the snort-users list: I have been able to reach first base by adding the following rule: alert tcp any any - any any (msg:ANY PROBE any attempt;) to /etc/snort/rules/experimental.rules, which is included in /etc/snort/snort.conf. Of course this causes a flood of messages and warnings, but at least I can see that Snort is responding to attempted and actual connections made to my firewall computer ports. Conversely, removing the above rule causes the flood of warnings to diminish to practically nothing. I am still not sure why the nmap probes referred to earlier did not trigger any messages, but at least I now have some ability to test cause and effect. If, from now on, the presence of any /^#.*\\$/ lines causes a problem, which I can reproduce I will open a bug report as you suggested. Thanks for your help. Best regards, James On Wed, 16 Jun 2004 04:36 am, Mike Mestnik wrote: If you read the archives of June 14-15(just 2 days agoe) you will see that we suspect any line in the form of /^#.*\\$/ to cause bad behaviour. These comments are getting meesed up by the cuntinue operator '\'. What's worse is that these comment lines most likely contain valid code. Thus the error is in a line much greater than the comment that caused the error. This could be something that just sliped into the latesed release. Try running an older version and see if the problem persits, also get in touch with the other person who had simular problems. See if there is a Debian bug repot, if not work with the other person too open one. --- James Sinnamon [EMAIL PROTECTED] wrote: Dear Debian firewallers, I am not getting anything written to my log files. snip/ -- James Sinnamon jps at westnet com auStralia ph +61 412 319669, +61 2 95692123, +61 2 95726357 __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Exatly, so what's the problem?? The new program won't do that. However the older X server will so this is a non-issue. We are 'hopefully' talking about DRI enabeled systems, making them better than Longhorn. For non 3d(DRI) systems I would hope that Mesa would be able to use there 2d parts to help the software renderer work faster. This work is needing tobe done, it would speed up ALL OpenGL apps for these older systems, with or with-out Joe's work(The DirectFB replacement). --- Alan Cox [EMAIL PROTECTED] wrote: Where DRI is not supported it's not used, why should any other driver be forced to work every where? All the current drivers barring some OS specific things like Linux frame buffer driver work when DRI isnt available on that platform and fall gracefully back to 2D with software 3D, including those that when DRI is available use the DRI layer for 2D. This is an important part of the XFree/Xorg tradition. __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Opps, Jon sorry. It's Jon Smirl's DirectFB replacement. --- Mike Mestnik [EMAIL PROTECTED] wrote: Exatly, so what's the problem?? The new program won't do that. However the older X server will so this is a non-issue. We are 'hopefully' talking about DRI enabeled systems, making them better than Longhorn. For non 3d(DRI) systems I would hope that Mesa would be able to use there 2d parts to help the software renderer work faster. This work is needing tobe done, it would speed up ALL OpenGL apps for these older systems, with or with-out Joe's work(The DirectFB replacement). --- Alan Cox [EMAIL PROTECTED] wrote: Where DRI is not supported it's not used, why should any other driver be forced to work every where? All the current drivers barring some OS specific things like Linux frame buffer driver work when DRI isnt available on that platform and fall gracefully back to 2D with software 3D, including those that when DRI is available use the DRI layer for 2D. This is an important part of the XFree/Xorg tradition. __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Mon, 2004-06-14 at 21:08 -0700, Mike Mestnik wrote: Your right about adding interfaces into the kernel, but what's proposed(the non hotplug stuff) is small and relitively uninteresting since it's not used by X. There are no currently pkged programs that would use these extentions so there is nothing stoping a rewrite b4 the user part is released. So you propose to add an immature interface to the mainline DRM/kernel and cross fingers that it won't turn into a maintenance and/or security nightmare before it gets rewritten? Sounds a little backwards to me. maintenance: No apps currently shiped would use it I.E. it's not going into X. security: It's a simple ioctl to change modes, if it's not easy to audit then it's overly complex for what it dose. Surely X has the same problem, if you can some how make a modeline that runs arbitrary code? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Sun, 2004-06-13 at 12:35 -0700, Jon Smirl wrote: 2) copy of the user space code from XFree86 into a standalone library - now you have to be root to play with the chip. 3) Add a couple of IOCTLs to DRM to support modes/cursors. Do as much of the work as possible in user space and just pass final register values to the IOCTLs. I would like to see #3. I have implemented #3 locally for the radeon but there is no acceptance for adding it to main DRM drivers. Of course, you neglect to mention the reasons for that. For one, you The reasons for that? I don't think I understand what reasons your talking about. haven't presented an interface yet that you have shown to remove the The inerface would be card specific, all cards set modes diffrently. need to be root and a significant amount of code from the kernel at the X runes as root and dose all the mode setting!! same time. Obviously, immature solutions can't go into the DRM trunk and Like I said some cards may need more kernel side then others, however I think the library approch workes best. Using a secure 0666 mode setting devce with a std lib API is the best way to go. Thought the kernel interface is GOING to be card specific, some cards will requier a setuid root(Xserver) to do the acctual mode switching. consequently the kernel because if they don't work out, they can become maintenance nightmares: If the client code was going into XFree86 I'd agree. However it's not, it's going into a new project that currently Isn't shiped by any one. maintenance nightmares. You have repeatedly been encouraged to develop a prototype system on branches or separate trees though. Don't wait for Like I said, paches avalible. everyone else to drop everything else. Lookes like a project that just needs some loving. DirectFB might have done better if it had some support as well. Lookes like a case of 'Not Made Here' syndrome. Gatos was also effected by this, it had a working DRI but was ignored for woking on the 'Made Here' DRI that was less capable in the Xvideo respects. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Tue, 2004-06-15 at 14:11 -0700, Mike Mestnik wrote: --- Michel Dnzer [EMAIL PROTECTED] wrote: On Mon, 2004-06-14 at 21:08 -0700, Mike Mestnik wrote: Your right about adding interfaces into the kernel, but what's proposed(the non hotplug stuff) is small and relitively uninteresting since it's not used by X. There are no currently pkged programs that would use these extentions so there is nothing stoping a rewrite b4 the user part is released. So you propose to add an immature interface to the mainline DRM/kernel and cross fingers that it won't turn into a maintenance and/or security nightmare before it gets rewritten? Sounds a little backwards to me. maintenance: No apps currently shiped would use it I.E. it's not going into X. Then why does it need to go mainline? *shrug* Is a branch considered mainline for the DRM? security: It's a simple ioctl to change modes, if it's not easy to audit then it's overly complex for what it dose. Surely X has the same problem, if you can some how make a modeline that runs arbitrary code? No, that's the difference between an abstract mode description and a register dump. For the latter, you either need to prevent harmful register value combinations (which I'm not convinced takes significantly if any less code than generating the register values in the first place) or require root privileges. (And root can already write to registers with the existing interface...) Like I said every card will do things diffrently, what we need is just a replacement for XFree86 mode setting. Like I hinted XFree86 could be used to set the mode, then it would have to exit or step out of the way. The cuttrent setuid root aproch workes fine, thought it's less secure then a kernel based solution(that may never exist for some cards). -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Ohh I get it, on non dri OSes there is a PROFORMANCE LOSS!!! --- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 22:58, Mike Mestnik wrote: The DRM is a kernel driver that allowes the user-apps to use a 3D cards API. Fbdev is smaller then the DRM and will be asimulated and it's functions emulated or replaced. On Linux and FreeBSD only, and there isnt yet a consensus on the Fbdev+DRI+text console+security+hotplug pile other than that it needs to be resolved. Hopefully the kernel summit in July will provide some more definitive answers on plans and once Linus has agreed to something (or destroyed all the ideas one by one 8)) it becomes easier to plan. In the shorter term however the sooner the current DRI is in the current X server the better. The kernel expects recent DRI, many users require it (eg for all modern laptops) with Linux and FreeBSD. Alan --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 22:58, Mike Mestnik wrote: The DRM is a kernel driver that allowes the user-apps to use a 3D cards API. Fbdev is smaller then the DRM and will be asimulated and it's functions emulated or replaced. SNIP In the shorter term however the sooner the current DRI is in the current X server the better. The kernel expects recent DRI, many users require it (eg for all modern laptops) with Linux and FreeBSD. Is this another reason to not add functionality to XAA for DRI supported cards? Alan __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 03:07, Jon Smirl wrote: Why not help getting mesa-solo working so that we can move to X on top of OpenGL? For one, in the two years that is going to take to bear fruit, we need a working X server. Two because mesa-solo isnt supported on most of the Xorg platforms. Alan Where DRI is not supported it's not used, why should any other driver be forced to work every where? __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Xorg] DRI merging
--- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 20:47, Matt Sealey wrote: Linux basically falls behind on two simple fronts at the moment: it has no simple 2D or 3D framework capable of much more than I deal with embedded Linux people on a daily basis. I think they would disagree. For 2D it has several in heavy use - Keith's tiny X server work - Nanogui (2D down to about 50K RAM) - DirectFB (particularly strong at multimedia) I looked at DirectFB and found it not maintained, I could try toget it working with mesa-solo cause the old branch(used in the install docs) is not used. Dose this project even still work, I'd love to try it out. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
The second half of the first paragraph controdics with the first. There are patches and the like avalible. The second sentance is refering to the hotplug code, only needed for multi cards(currently not suported)? Or did you mean something else. Your right about adding interfaces into the kernel, but what's proposed(the non hotplug stuff) is small and relitively uninteresting since it's not used by X. There are no currently pkged programs that would use these extentions so there is nothing stoping a rewrite b4 the user part is released. --- Michel Dänzer [EMAIL PROTECTED] wrote: On Sun, 2004-06-13 at 12:35 -0700, Jon Smirl wrote: 2) copy of the user space code from XFree86 into a standalone library - now you have to be root to play with the chip. 3) Add a couple of IOCTLs to DRM to support modes/cursors. Do as much of the work as possible in user space and just pass final register values to the IOCTLs. I would like to see #3. I have implemented #3 locally for the radeon but there is no acceptance for adding it to main DRM drivers. Of course, you neglect to mention the reasons for that. For one, you haven't presented an interface yet that you have shown to remove the need to be root and a significant amount of code from the kernel at the same time. Obviously, immature solutions can't go into the DRM trunk and consequently the kernel because if they don't work out, they can become maintenance nightmares. You have repeatedly been encouraged to develop a prototype system on branches or separate trees though. Don't wait for everyone else to drop everything else. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Non DRI systems don't support DRI and have XAA instead. We should be free to 'rm -rf' any thing we can replace with something better. I can see XAA getting moved into Mesa(YUCK), but it's posible to do all 2d drawing via OGL calls with a modified Xserver. --- Keith Packard [EMAIL PROTECTED] wrote: Around 21 o'clock on Jun 13, Philipp Klaus Krause wrote: There would be no 2d drivers, only some basic mode switching and cursor support and OpenGL? For systems which would support OpenGL, this would be all that was required. However, we still need to deal with the unwashed masses yearning to run X who don't have OpenGL-enabled systems. For them, we're stuck with a 2D-only driver, perhaps with a bit of Render acceleration to make Composite tolerable on them. -keith ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Unichrome-devel] Re: Via DDX for DRI?
Yes, is this not the esiest way to extend the protocol, by adding a new field to a string value? --- Eric Anholt [EMAIL PROTECTED] wrote: On Mon, 2004-06-14 at 20:34, Mike Mestnik wrote: Ohh, is it realy that hard of a feature to add?? foo:bar Old systems try to open path/foo:bar_dri.so and maby thay will fail or there will be a symlink there. A simpl parser could be added, making a new system pars for the ':' and try each one. That solution sounds worse than the problem -- break all new DDX vs old libGL for the sake of one (questionable, IMO) DDX's requirement that could be handled easier with a symlink. The thing to do, if this feature were really desired, would be to extend the XF86DRI protocol. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
