Re: New proposed DRM interface design
On Sun, Sep 05, 2004 at 11:33:53AM -0400, Jon Smirl wrote: Then how am I going to merge fbdev and DRM so that we don't have two drivers fighting over the same hardware? I was planning on adding pieces of the existing fbdev code to DRM in order to implement printk from the kernel. It seems silly for me to rewrite 10,000 lines of code just to make it BSD licensed when BSD isn't even going to use the code. Is the code in question attributed to a single developer or to a horde? I only have a 2.4 kernel handy, so I can't check. If it's a single developer or just a few, you could ask them for permission to put it under a less restrictive license. Petr Vandrovec gave that permission for his components of the matroxfb code. A lot of times the FB people don't really care about the license and slap GPL on it just because that's the default thing to do for code going into the Linux kernel. It doesn't necessarily mean that they would only grant permission for the code to be used in GPL scenarios. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[Bug 1220] Garbage screen after resume from suspend to disk
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1220 --- Additional Comments From [EMAIL PROTECTED] 2004-09-06 00:38 --- hi, the dri module was enabled. I have and had 700+Fps in glxgears It works for X.org 7.6.rc2 and Xfree86 4.3 too, so it's not an direct X.org problem. But I need the power management of the CVS version, which rise my laptop work in accu mode a half hour longer! I know that it worked with the old DRI version on several laptops, so I think it can be fixed in code. Is there a chance to add the acpi support to dri/x.org, so it'll work on all ACPI Systems? Greetz Konstantin -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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: r250 and black screen
There were reports (and I experienced it myself) of Radeon 9200-based cards where the DVI output got disabled by DRI applications. After exiting the 3D application, VT switching to another virtual terminal and back to X restored the display. Are you using the DVI output on your card? If yes, can you test if the analog VGA port works? I investigated the problem a bit before I returned that card. I was able to get the same effect by running x11perf for a while. So I suspect it's not directly related to DRI or the 3D engine but a general power supply or overheating problem that occurs when the chip is stressed for some time. With 3D applications it took only one or two seconds for the DVI port to switch off. With x11perf it took a few minutes. When I played q3demo for about 10 min on the analog VGA port it took several minutes before VT switching would restore the DVI output. That's why I believe it may be heat related. With Windows drivers I didn't manage to the the DVI port working at all on this card. Regards, Felix On Fri, 3 Sep 2004 17:03:32 +0200 Luca Zini [EMAIL PROTECTED] wrote: I have an ati 9000 on a asus a7n8x-x. the direct rendering works well, and I can use glxgears, celestia and some other application that need it, but a lot of games don't work. For example when I try to start tuxracer the screen goes black and I can only exit pressing esc. I can listen game's audio, but the video is completely black. I looked for some errors, but I didn't find anything. I have this problem whith xfree 4.3 xfree 4.4 and x.org on Fedora, mandrake, debian, slackware (9.1/10/current). I installed last version of dri following http://dri.sourceforge.net/cgi-bin/moin.cgi/Building but the problem is not resolved. I attached the output of glxinfo and xorg.conf I don't know what log can be useful for understand the problem, so I attend your requests ;) regards, Luca PS: Your antispam filter block the smtp server of one of the most used italian provider (fastweb 213.140.2.52) | 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
[BUG] cvs snapshots dont compile on 2.6.8.1
Both r200 and savage dri cvs snapshots for 20040905 fail to compile on virgin 2.6.8.1 dri.log says make DRM_MODULES=radeon.o modules make[1]: Entering directory `/home/diablo/code/dri/dripkg/drm' rm -f linux ln -s . linux make -C /lib/modules/2.6.8.1/source SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules make[2]: Entering directory `/usr/src/linux-2.6.8.1' CC [M] /home/diablo/code/dri/dripkg/drm/radeon_drv.o In file included from /home/diablo/code/dri/dripkg/drm/radeon_drv.c:47: /home/diablo/code/dri/dripkg/drm/drm_drv.h: In function `radeon_release': /home/diablo/code/dri/dripkg/drm/drm_drv.h:974: error: structure has no member n amed `free_filp_private' /home/diablo/code/dri/dripkg/drm/drm_drv.h:975: error: structure has no member n amed `free_filp_private' make[3]: *** [/home/diablo/code/dri/dripkg/drm/radeon_drv.o] Error 1 make[2]: *** [_module_/home/diablo/code/dri/dripkg/drm] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.8.1' make[1]: *** [modules] Error 2 make[1]: Leaving directory `/home/diablo/code/dri/dripkg/drm' make: *** [radeon.o] Error 2 -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 --- 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
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. 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
Re: [BUG] r200 dri driver deadlocks
On Sun, 05 Sep 2004 20:14:43 -0400, Lee Revell [EMAIL PROTECTED] wrote: How to fix this is a pretty hot topic now. Yow, I didn't mean to cause such an upset. ;) Currently, the dri cvs snapshot for 20040905 doesn't compile with 2.6.8.1 for me (I've sent a bug report to the dri-devel mailing list about this) so Lee and Michel, you'll have to wait until tomorrow (or maybe even the day after that) to see how the test goes. I'm hoping it does work, this bug is pretty nasty imho. Who knew Quake could take an entire box out in under 10 seconds. ;) -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 --- 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: vertex programs for r200 patch
Am Freitag, 27. August 2004 21:56 schrieb Philipp Klaus Krause: The same as the patches I sent earlier, but as a single unified file. For those that didn't read the original posting: This patch enables GL_ARB_vertex_program support for the r200 driver. The vertex programs are executed in software, but since this only replaces tcl everything from the perspective divide onward is still hardware accelerated, even when a vertex program is active. When will we see this in? http://marc.theaimsgroup.com/?l=dri-develm=109408144803743w=2 Thanks, Dieter --- 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] cvs snapshots dont compile on 2.6.8.1
In file included from /home/diablo/code/dri/dripkg/drm/radeon_drv.c:47: /home/diablo/code/dri/dripkg/drm/drm_drv.h: In function `radeon_release': /home/diablo/code/dri/dripkg/drm/drm_drv.h:974: error: structure has no member n amed `free_filp_private' /home/diablo/code/dri/dripkg/drm/drm_drv.h:975: error: structure has no member n amed `free_filp_private' make[3]: *** [/home/diablo/code/dri/dripkg/drm/radeon_drv.o] Error 1 I checked in the fix.. but the snapshots mightn't have picked it up ... just change the free_filp_private to free_filp_priv, it was for consitency sakes.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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: vertex programs for r200 patch
When will we see this in? http://marc.theaimsgroup.com/?l=dri-develm=109408144803743w=2 I've reviewed it and would be happy with it as well, but I would like a driconf option to turn it off in case it some apps have issues.. adding a driconf option is explained at: http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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: r250 and black screen
sn, 05,.09.2004 kl. 21.13 -0400, skrev Michel Dnzer: On Fri, 2004-09-03 at 17:03 +0200, Luca Zini wrote: I have an ati 9000 on a asus a7n8x-x. the direct rendering works well, and I can use glxgears, celestia and some other application that need it, but a lot of games don't work. For example when I try to start tuxracer the screen goes black and I can only exit pressing esc. I can listen game's audio, but the video is completely black. Sounds like https://freedesktop.org/bugzilla/show_bug.cgi?id=982 ? Have you tried lower AGP modes? (I wouldn't expect that to make a difference for a non-lockup though) For me at least this problem started with xorg 6.7.99.x from cvs, the old XFree86 releases and DRI cvs worked fine. I don't have to do any 3d to have the screen black out, just ctrl-+/- or xrandr -s. Also doing ctrl-+ then ctrl-- doesn't return me to the original mode, I have to keep pushing ctrl-+ or ctrl-- a random number of times, if I run xrandr while doing this it sometimes appears very confused - listing resolutions in wrong order or no order at all. The heat issue Felix mentioned doesn't seem to apply to me as I can run ut2k4 in windowed mode for hours (even if I make the window fullscreen) without problem, but as soon as I try to run fullscreen mode at a different resolution it blacks out. I did a quick diff between radeon_driver.c in dri and xorg cvs but there's been too many changes for me to easily find a suspect since I don't really know that part of the code at all. -- Ronny V. Vindenes [EMAIL PROTECTED] --- 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] cvs snapshots dont compile on 2.6.8.1
Am Montag, 6. September 2004 13:32 schrieb Dave Airlie: In file included from /home/diablo/code/dri/dripkg/drm/radeon_drv.c:47: /home/diablo/code/dri/dripkg/drm/drm_drv.h: In function `radeon_release': /home/diablo/code/dri/dripkg/drm/drm_drv.h:974: error: structure has no member n amed `free_filp_private' /home/diablo/code/dri/dripkg/drm/drm_drv.h:975: error: structure has no member n amed `free_filp_private' make[3]: *** [/home/diablo/code/dri/dripkg/drm/radeon_drv.o] Error 1 I checked in the fix.. but the snapshots mightn't have picked it up ... just change the free_filp_private to free_filp_priv, it was for consitency sakes.. I hope you've read my post DRM... Compiled fine and works. Cheers, Dieter --- 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
Savage DRM problem: multiple framebuffer mappings
Hi, after upgrading the DRM (it has been a while since the last cvs update) the Savage driver stopped working. I tracked it down to the DRM refusing to create multiple framebuffer-type mappings. If it finds an existing mapping it returns it instead of creating a new one. However, the Savage driver needs multiple framebuffer-type mappings. The real frame buffer is supplemented by a so-called aperture where front/back/depth buffers can be accessed at fixed addresses (independent of their actual locations in the frame buffer) linearly even if the framebuffer is physically tiled. This behaviour is controlled by a set of tiled surface registers (IIRC). The HwMC code makes yet another framebuffer-type mapping. :-/ Anyway, I suspect the behaviour of DRM(addmap) changed recently. The only addmap-related comment I could find on dri-patches is this: addmap-base-2 patch from Jon Smirl: sets up the DRM to have the ability to have permanent maps while the driver is loaded... Is it really necessary to limit drivers to a single framebuffer-type mapping? 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 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
Re: r250 and black screen
As suggested I tried to connect a vga cable, and seem to work even in dvi mode. Thanks for the info! regards, Luca --- 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: New proposed DRM interface design
Lee Revell [EMAIL PROTECTED] said: [...] Wrong and wrong. If you run Debian unstable (which is WAY more stable than, say, FC2) then you can apt-get upgrade to the latest kernel. What makes you say this? I've seen no stability problems with FC2. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 --- 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: vertex programs for r200 patch
Dave Airlie schrieb: When will we see this in? http://marc.theaimsgroup.com/?l=dri-develm=109408144803743w=2 I've reviewed it and would be happy with it as well, but I would like a driconf option to turn it off in case it some apps have issues.. adding a driconf option is explained at: http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure Dave. So I'll add driconf options for both GL_ARB_vertex_program (on by default) and GL_NV_vertex_program (off by default). Maybe we should add the 1.4 extensions and make an option for GL_ARB_depth_texture someday. Philipp --- 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
On Mon, 2004-09-06 at 07:01 -0400, Patrick McFarland wrote: On Sun, 05 Sep 2004 20:14:43 -0400, Lee Revell [EMAIL PROTECTED] wrote: How to fix this is a pretty hot topic now. Yow, I didn't mean to cause such an upset. ;) Currently, the dri cvs snapshot for 20040905 doesn't compile with 2.6.8.1 for me (I've sent a bug report to the dri-devel mailing list about this) so Lee and Michel, you'll have to wait until tomorrow (or maybe even the day after that) to see how the test goes. You can test the r200_dri.so from the snapshot with the DRM from the kernel... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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
vertex programs patch for r200 with configuration options
This patch enables GL_ARB_vertex_program and GL_NV_vertex_program support in the r200 driver. Both extensions can be enabled via options, GL_ARB_vertex_program is on by default, GL_NV_vertex_program off. Option descriptions are in german, english and french. Apply with cat r200_vp.patch | patch -p1 in Mesa/src/mesa/drivers/dri Philipp Klaus Krause diff --unified -r dri.bak/common/xmlpool.h dri/common/xmlpool.h --- dri.bak/common/xmlpool.h 2004-05-08 12:08:21 +0200 +++ dri/common/xmlpool.h 2004-09-06 20:32:38 +0200 @@ -273,4 +273,25 @@ DRI_CONF_DESC(de,Anzahl der Textureinheiten) \ DRI_CONF_OPT_END +/* Options for features that are not done in hardware by the driver (like GL_ARB_vertex_program + On cards where there is no documentation (r200) or on rasterization-only hardware). */ +#define DRI_CONF_SECTION_SOFTWARE \ +DRI_CONF_SECTION_BEGIN \ +DRI_CONF_DESC(de,Funktionalität, die nicht durch die Hardware beschleunigt wird) \ +DRI_CONF_DESC(en,Features that are not hardware-accelerated) + +#define DRI_CONF_ARB_VERTEX_PROGRAM(def) \ +DRI_CONF_OPT_BEGIN(arb_vertex_program,bool,def) \ +DRI_CONF_DESC(de,GL_ARB_vertex_program aktivieren) \ +DRI_CONF_DESC(en,Enable GL_ARB_vertex_program) \ +DRI_CONF_DESC(fr,Activer GL_ARB_vertex_program) \ +DRI_CONF_OPT_END + +#define DRI_CONF_NV_VERTEX_PROGRAM(def) \ +DRI_CONF_OPT_BEGIN(nv_vertex_program,bool,def) \ +DRI_CONF_DESC(de,GL_NV_vertex_program aktivieren) \ +DRI_CONF_DESC(en,Enable GL_NV_vertex_program) \ +DRI_CONF_DESC(fr,Activer GL_NV_vertex_program) \ +DRI_CONF_OPT_END + #endif diff --unified -r dri.bak/r200/r200_context.c dri/r200/r200_context.c --- dri.bak/r200/r200_context.c 2004-07-04 22:33:49 +0200 +++ dri/r200/r200_context.c 2004-09-06 20:23:26 +0200 @@ -62,7 +62,7 @@ #include r200_vtxfmt.h #include r200_maos.h -#define DRIVER_DATE 20030328 +#define DRIVER_DATE 20040906 #include vblank.h #include utils.h @@ -166,6 +166,7 @@ _tnl_fog_coordinate_stage, _tnl_texgen_stage, _tnl_texture_transform_stage, + _tnl_vertex_program_stage, /* Try again to go to tcl? * - no good for asymmetric-twoside (do with multipass) @@ -406,6 +407,10 @@ _mesa_enable_extension( ctx, GL_EXT_blend_equation_separate ); _mesa_enable_extension( ctx, GL_EXT_blend_func_separate ); } + if(driQueryOptionb(rmesa-optionCache, arb_vertex_program)) + _mesa_enable_extension( ctx, GL_ARB_vertex_program); + if(driQueryOptionb(rmesa-optionCache, nv_vertex_program)) + _mesa_enable_extension( ctx, GL_NV_VERTEX_PROGRAM); #if 0 r200InitDriverFuncs( ctx ); diff --unified -r dri.bak/r200/r200_screen.c dri/r200/r200_screen.c --- dri.bak/r200/r200_screen.c 2004-07-04 22:33:49 +0200 +++ dri/r200/r200_screen.c 2004-09-06 20:24:02 +0200 @@ -75,6 +75,10 @@ DRI_CONF_SECTION_DEBUG DRI_CONF_NO_RAST(false) DRI_CONF_SECTION_END +DRI_CONF_SECTION_SOFTWARE +DRI_CONF_ARB_VERTEX_PROGRAM(true) +DRI_CONF_NV_VERTEX_PROGRAM(false) +DRI_CONF_SECTION_END DRI_CONF_END; static const GLuint __driNConfigOptions = 11; diff --unified -r dri.bak/r200/r200_state.c dri/r200/r200_state.c --- dri.bak/r200/r200_state.c 2004-05-27 18:56:47 +0200 +++ dri/r200/r200_state.c 2004-09-06 20:22:41 +0200 @@ -2043,6 +2043,10 @@ r200UpdateSpecular ( ctx ); break; + case GL_VERTEX_PROGRAM_ARB: + TCL_FALLBACK(rmesa-glCtx, R200_TCL_FALLBACK_TCL_DISABLE, state); + break; + default: return; } diff --unified -r dri.bak/r200/r200_tcl.h dri/r200/r200_tcl.h --- dri.bak/r200/r200_tcl.h 2004-06-03 00:09:11 +0200 +++ dri/r200/r200_tcl.h 2004-09-06 20:22:41 +0200 @@ -60,6 +60,7 @@ #define R200_TCL_FALLBACK_TEXGEN_5 0x200 /* texgen, unit 5 */ #define R200_TCL_FALLBACK_TCL_DISABLE 0x400 /* user disable */ #define R200_TCL_FALLBACK_BITMAP0x800 /* draw bitmap with points */ +#define R200_TCL_FALLBACK_VERTEX_PROGRAM0x1000/* vertex program active */ #define TCL_FALLBACK( ctx, bit, mode ) r200TclFallback( ctx, bit, mode )
vertex programs patch for r200 with configuration options -- corrected
'Did some more testing and found bugs. Here is the corrected patch. Philipp diff --unified -r dri.bak/common/xmlpool.h dri/common/xmlpool.h --- dri.bak/common/xmlpool.h 2004-05-08 12:08:21 +0200 +++ dri/common/xmlpool.h 2004-09-06 20:39:06 +0200 @@ -273,4 +273,25 @@ DRI_CONF_DESC(de,Anzahl der Textureinheiten) \ DRI_CONF_OPT_END +/* Options for features that are not done in hardware by the driver (like GL_ARB_vertex_program + On cards where there is no documentation (r200) or on rasterization-only hardware). */ +#define DRI_CONF_SECTION_SOFTWARE \ +DRI_CONF_SECTION_BEGIN \ +DRI_CONF_DESC(de,Funktionalität, die nicht durch die Hardware beschleunigt wird) \ +DRI_CONF_DESC(en,Features that are not hardware-accelerated) + +#define DRI_CONF_ARB_VERTEX_PROGRAM(def) \ +DRI_CONF_OPT_BEGIN(arb_vertex_program,bool,def) \ +DRI_CONF_DESC(de,GL_ARB_vertex_program aktivieren) \ +DRI_CONF_DESC(en,Enable GL_ARB_vertex_program) \ +DRI_CONF_DESC(fr,Activer GL_ARB_vertex_program) \ +DRI_CONF_OPT_END + +#define DRI_CONF_NV_VERTEX_PROGRAM(def) \ +DRI_CONF_OPT_BEGIN(nv_vertex_program,bool,def) \ +DRI_CONF_DESC(de,GL_NV_vertex_program aktivieren) \ +DRI_CONF_DESC(en,Enable GL_NV_vertex_program) \ +DRI_CONF_DESC(fr,Activer GL_NV_vertex_program) \ +DRI_CONF_OPT_END + #endif diff --unified -r dri.bak/r200/r200_context.c dri/r200/r200_context.c --- dri.bak/r200/r200_context.c 2004-07-04 22:33:49 +0200 +++ dri/r200/r200_context.c 2004-09-06 22:17:06 +0200 @@ -62,7 +62,7 @@ #include r200_vtxfmt.h #include r200_maos.h -#define DRIVER_DATE 20030328 +#define DRIVER_DATE 20040906 #include vblank.h #include utils.h @@ -166,6 +166,7 @@ _tnl_fog_coordinate_stage, _tnl_texgen_stage, _tnl_texture_transform_stage, + _tnl_vertex_program_stage, /* Try again to go to tcl? * - no good for asymmetric-twoside (do with multipass) @@ -406,6 +407,10 @@ _mesa_enable_extension( ctx, GL_EXT_blend_equation_separate ); _mesa_enable_extension( ctx, GL_EXT_blend_func_separate ); } + if(driQueryOptionb(rmesa-optionCache, arb_vertex_program)) + _mesa_enable_extension( ctx, GL_ARB_vertex_program); + if(driQueryOptionb(rmesa-optionCache, nv_vertex_program)) + _mesa_enable_extension( ctx, GL_NV_vertex_program); #if 0 r200InitDriverFuncs( ctx ); diff --unified -r dri.bak/r200/r200_screen.c dri/r200/r200_screen.c --- dri.bak/r200/r200_screen.c 2004-07-04 22:33:49 +0200 +++ dri/r200/r200_screen.c 2004-09-06 22:09:18 +0200 @@ -75,8 +75,12 @@ DRI_CONF_SECTION_DEBUG DRI_CONF_NO_RAST(false) DRI_CONF_SECTION_END +DRI_CONF_SECTION_SOFTWARE +DRI_CONF_ARB_VERTEX_PROGRAM(true) +DRI_CONF_NV_VERTEX_PROGRAM(false) +DRI_CONF_SECTION_END DRI_CONF_END; -static const GLuint __driNConfigOptions = 11; +static const GLuint __driNConfigOptions = 13; #if 1 /* Including xf86PciInfo.h introduces a bunch of errors... diff --unified -r dri.bak/r200/r200_state.c dri/r200/r200_state.c --- dri.bak/r200/r200_state.c 2004-05-27 18:56:47 +0200 +++ dri/r200/r200_state.c 2004-09-06 20:39:06 +0200 @@ -2043,6 +2043,10 @@ r200UpdateSpecular ( ctx ); break; + case GL_VERTEX_PROGRAM_ARB: + TCL_FALLBACK(rmesa-glCtx, R200_TCL_FALLBACK_TCL_DISABLE, state); + break; + default: return; } diff --unified -r dri.bak/r200/r200_tcl.h dri/r200/r200_tcl.h --- dri.bak/r200/r200_tcl.h 2004-06-03 00:09:11 +0200 +++ dri/r200/r200_tcl.h 2004-09-06 20:39:06 +0200 @@ -60,6 +60,7 @@ #define R200_TCL_FALLBACK_TEXGEN_5 0x200 /* texgen, unit 5 */ #define R200_TCL_FALLBACK_TCL_DISABLE 0x400 /* user disable */ #define R200_TCL_FALLBACK_BITMAP0x800 /* draw bitmap with points */ +#define R200_TCL_FALLBACK_VERTEX_PROGRAM0x1000/* vertex program active */ #define TCL_FALLBACK( ctx, bit, mode ) r200TclFallback( ctx, bit, mode )
Re: New proposed DRM interface design
On Llu, 2004-09-06 at 21:58, Hamie wrote: The fs - SCSI interface is a logical one. We just have to make the fb and DRI to hardware one logical. Unless you can have fb sitting on top of DRM of course... (I discount DRM on-top of fb, because of the D == Direct... No other reason :)... Does it make sens to have fb ontop of DRM at all? Anyone? In some cases yes. The DRM is happy with the idea of the kernel being a DRM client too. --- 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: vertex programs patch for r200 with configuration options -- corrected
On Llu, 2004-09-06 at 21:19, Philipp Klaus Krause wrote: 'Did some more testing and found bugs. Here is the corrected patch. Not having looked at this before - is there a reason for DRI_CONF_DESC not using standard internationalisation functions. --- 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: New proposed DRM interface design
Alan Cox wrote: On Sul, 2004-09-05 at 23:11, Jon Smirl wrote: What is the advantage to continuing a development model where two groups of programmers work independently, with little coordination on two separate code bases trying to simultaneously control the same piece of hardware? This is a continuous source of problems. Why can't we fix the development model to stop this? I don't see that as much of a problem. The mess arises from some simple lacks in the objects in kernel and the methods required to co-ordinate. Lots of drivers are written by a lot of people in the kernel and they work just fine. The ext3 authors don't spend their lives co-ordinating with SCSI driver authors, they just get the API right. Sorry, but I think that's (Possibly?) a really really bad misleading example... Apples Apples vs Chocolate Milkshakes... The dual screen problem with DRM fb is two drivers accessing (Sometimes) the same hardware. The ext3 vs SCSI is a filesystem, that sits on-top of a disk device that may just be SCSI.. Or IDE.. The fs - SCSI interface is a logical one. Unless you can have fb sitting on top of DRM of course... (I discount DRM on-top of fb, because of the D == Direct... No other reason :)... Does it make sens to have fb ontop of DRM at all? Anyone? regards Hamish. --- 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: r250 and black screen
I investigated the problem a bit before I returned that card. I was able to get the same effect by running x11perf for a while. So I suspect it's not directly related to DRI or the 3D engine but a general power supply or overheating problem that occurs when the chip is stressed for some time. I tried to use proprietary ati driver to see if they have the same problem and everythink worked well even without the vga cable connected. This seems to exclude a hardware problem. regards Luca --- 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: r250 and black screen
I investigated the problem a bit before I returned that card. I was able to get the same effect by running x11perf for a while. So I suspect it's not directly related to DRI or the 3D engine but a general power supply or overheating problem that occurs when the chip is stressed for some time. I tried to use proprietary ati driver to see if they have the same problem and everythink worked well even without the vga cable connected. This seems to exclude a hardware problem. regards Luca -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Rinfresca la tua estate con i climatizzatori ed i ventilatori * che trovi disponibili Crios, Orieme, Hokkaido, Argo, Carrier, Vortice Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2650d=6-9 --- 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: New proposed DRM interface design
Some examples of merging are turning two independent radeon personality modules into a single one. Another thing I need to do is to extract the printk support from the core fb module and put it somewhere I can get to it from DRM. We can't have two cores trying to attach to the same device and then doing takeover_console(). Mode setting will be a lot of new code since Alan's proposed design doesn't match any of the existing solutions. I will try to reuse snippets where I can. On Mon, 06 Sep 2004 22:38:05 +0100, Hamie [EMAIL PROTECTED] wrote: Alright... So you have drm at the lower level, and the fb sits ontop of that... The fb just becomes a user of the DRM... No merge necessary then, because all the actual hardware access, memory allocation etc would live in drm? Is that right? And all the 2D code would also move into the DRM? (IIRC the DRM just has 3D stuff in it yes? IMO It would made sense to have all the acceleration hardware access in the DRM together rather than in a separate place... Correct?) -- Jon Smirl [EMAIL PROTECTED] --- 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: vertex programs patch for r200 with configuration options -- corrected
On Mon, 06 Sep 2004 21:21:00 +0100 Alan Cox [EMAIL PROTECTED] wrote: On Llu, 2004-09-06 at 21:19, Philipp Klaus Krause wrote: 'Did some more testing and found bugs. Here is the corrected patch. Not having looked at this before - is there a reason for DRI_CONF_DESC not using standard internationalisation functions. We want the description strings in all available languages to be compiled into the 3D drivers. All these macros result in a small XML-document which is looked up via dlopen/dlsym by the configuration tool (or xdriinfo as a helper for script based tools). This way information about available options and some human-readable documentation is always in sync with the drivers actually installed on the system. For more background on this design see http://dri.freedesktop.org/~fxkuehl/driconf/dri_config_design_rev4.html. Further information about DRI configuration issues can be found at http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure. 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 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
Re: vertex programs patch for r200 with configuration options -- corrected
Am Montag, 6. September 2004 22:19 schrieb Philipp Klaus Krause: 'Did some more testing and found bugs. Here is the corrected patch. Works fine. Out for vacation, now. Dieter --- 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: New proposed DRM interface design
On Mon, 06 Sep 2004 21:15:07 +0100, Alan Cox [EMAIL PROTECTED] wrote: In some cases yes. The DRM is happy with the idea of the kernel being a DRM client too. Thats actually a pretty cool idea. For us that need to use the vesa fbcon driver because there is no native driver, it would probably be faster and saner, and no more problems with dri drivers that don't play nice with fbcon drivers (is that even an issue anymore?) -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 --- 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: vertex programs patch for r200 with configuration options -- corrected
Okay if nobody pops up with a problem I'll check it in later on today... Dave. On Mon, 6 Sep 2004, Philipp Klaus Krause wrote: 'Did some more testing and found bugs. Here is the corrected patch. Philipp -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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: Savage DRM problem: multiple framebuffer mappings
Anyway, I suspect the behaviour of DRM(addmap) changed recently. The only addmap-related comment I could find on dri-patches is this: addmap-base-2 patch from Jon Smirl: sets up the DRM to have the ability to have permanent maps while the driver is loaded... Is it really necessary to limit drivers to a single framebuffer-type mapping? Just in case anyone is wondering this is why I can be a bit slow pushing to Linus, finding these issues takes time... this patch looked okay to me but I never knew what the savage was up to ... I don't think there is any reason to limit it to only one mapping, Hopefully Jon can think of a way around it, you should be able to back out that change on your system for now until Jon gets online.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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: vertex programs patch for r200 with configuration options -- corrected
On Llu, 2004-09-06 at 22:50, Felix Khling wrote: We want the description strings in all available languages to be compiled into the 3D drivers. All these macros result in a small XML-document which is looked up via dlopen/dlsym by the configuration tool (or xdriinfo as a helper for script based tools). This way information about available options and some human-readable documentation is always in sync with the drivers actually installed on the system. For more background on this design see The internationalisation system supported by all DRI supporting OS's already deals with this itself, and includes things you don't seem to be dealing with like character sets and the fact locales are multi-component (eg en_GB, en_US) and with fallbacks. It seems strange to be reinventing the wheel --- 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
Re: Savage DRM problem: multiple framebuffer mappings
The plan for the addMap changes is to get rid of the loop where the user space code asks the driver where the resources are and then sets those values back into the driver. Since the driver already knows these values it should just create the maps itself. This removes the possibility of the user space code changing those values before passing them back. This is the code radeon driver uses to create the permanent resource mappings. Adding the corresponding code the the savage driver will fix the problem. initmap won't stop you from making more than one mapping. I can look into fixing addmap, but if you switch to having the driver initmap for REGISTERS/ FRAME_BUFFER you won't need to addmap them from user space and it won't matter if the call fails. + + /* registers */ + /* PCI space is twice the real size, so that you can have a RW and RO mapping */ + if( (retcode = DRM(initmap)( dev, pci_resource_start( dev-pdev, 2 ), + pci_resource_len( dev-pdev, 2 ) / 2, _DRM_REGISTERS, 0 ))) + return retcode; + + /* framebuffer */ + if( (retcode = DRM(initmap)( dev, pci_resource_start( dev-pdev, 0 ), + pci_resource_len( dev-pdev, 0 ), _DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING ))) + return retcode; On Mon, 6 Sep 2004 23:23:27 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: Anyway, I suspect the behaviour of DRM(addmap) changed recently. The only addmap-related comment I could find on dri-patches is this: addmap-base-2 patch from Jon Smirl: sets up the DRM to have the ability to have permanent maps while the driver is loaded... Is it really necessary to limit drivers to a single framebuffer-type mapping? Just in case anyone is wondering this is why I can be a bit slow pushing to Linus, finding these issues takes time... this patch looked okay to me but I never knew what the savage was up to ... I don't think there is any reason to limit it to only one mapping, Hopefully Jon can think of a way around it, you should be able to back out that change on your system for now until Jon gets online.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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 -- Jon Smirl [EMAIL PROTECTED] --- 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: Savage DRM problem: multiple framebuffer mappings
But does the new code deal with multiple mappings.. the radeon doesn't do this at the moment they call multiple addmaps for the framebuffer, A permanently mapped framebuffer, shouldn't stop you adding another mapping for tiling/whatever... or should it.. Dave. On Mon, 6 Sep 2004, Jon Smirl wrote: The plan for the addMap changes is to get rid of the loop where the user space code asks the driver where the resources are and then sets those values back into the driver. Since the driver already knows these values it should just create the maps itself. This removes the possibility of the user space code changing those values before passing them back. This is the code radeon driver uses to create the permanent resource mappings. Adding the corresponding code the the savage driver will fix the problem. initmap won't stop you from making more than one mapping. I can look into fixing addmap, but if you switch to having the driver initmap for REGISTERS/ FRAME_BUFFER you won't need to addmap them from user space and it won't matter if the call fails. + + /* registers */ + /* PCI space is twice the real size, so that you can have a RW and RO mapping */ + if( (retcode = DRM(initmap)( dev, pci_resource_start( dev-pdev, 2 ), + pci_resource_len( dev-pdev, 2 ) / 2, _DRM_REGISTERS, 0 ))) + return retcode; + + /* framebuffer */ + if( (retcode = DRM(initmap)( dev, pci_resource_start( dev-pdev, 0 ), + pci_resource_len( dev-pdev, 0 ), _DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING ))) + return retcode; On Mon, 6 Sep 2004 23:23:27 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: Anyway, I suspect the behaviour of DRM(addmap) changed recently. The only addmap-related comment I could find on dri-patches is this: addmap-base-2 patch from Jon Smirl: sets up the DRM to have the ability to have permanent maps while the driver is loaded... Is it really necessary to limit drivers to a single framebuffer-type mapping? Just in case anyone is wondering this is why I can be a bit slow pushing to Linus, finding these issues takes time... this patch looked okay to me but I never knew what the savage was up to ... I don't think there is any reason to limit it to only one mapping, Hopefully Jon can think of a way around it, you should be able to back out that change on your system for now until Jon gets online.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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 -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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: Savage DRM problem: multiple framebuffer mappings
AddMap has the loop to find the existing mapping and replace it. initmap doesn't have that loop so it allows multiple adds. I wanted to just make AddMap refuse a REG/FB map request but I was trying to be compatible while we changed the drivers over. Can we just switch the drivers over right now and I'll make AddMap ignore requests to change the mappings? It's only a couple of line of code in each driver, but the driver maintainers need to tell us which PCI resource numbers to map. I can switch radeon/r128 right now if we are ready. If not I can complicate the loop more to handle this case. On Tue, 7 Sep 2004 00:45:53 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: But does the new code deal with multiple mappings.. the radeon doesn't do this at the moment they call multiple addmaps for the framebuffer, A permanently mapped framebuffer, shouldn't stop you adding another mapping for tiling/whatever... or should it.. Dave. On Mon, 6 Sep 2004, Jon Smirl wrote: The plan for the addMap changes is to get rid of the loop where the user space code asks the driver where the resources are and then sets those values back into the driver. Since the driver already knows these values it should just create the maps itself. This removes the possibility of the user space code changing those values before passing them back. This is the code radeon driver uses to create the permanent resource mappings. Adding the corresponding code the the savage driver will fix the problem. initmap won't stop you from making more than one mapping. I can look into fixing addmap, but if you switch to having the driver initmap for REGISTERS/ FRAME_BUFFER you won't need to addmap them from user space and it won't matter if the call fails. + + /* registers */ + /* PCI space is twice the real size, so that you can have a RW and RO mapping */ + if( (retcode = DRM(initmap)( dev, pci_resource_start( dev-pdev, 2 ), + pci_resource_len( dev-pdev, 2 ) / 2, _DRM_REGISTERS, 0 ))) + return retcode; + + /* framebuffer */ + if( (retcode = DRM(initmap)( dev, pci_resource_start( dev-pdev, 0 ), + pci_resource_len( dev-pdev, 0 ), _DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING ))) + return retcode; On Mon, 6 Sep 2004 23:23:27 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: Anyway, I suspect the behaviour of DRM(addmap) changed recently. The only addmap-related comment I could find on dri-patches is this: addmap-base-2 patch from Jon Smirl: sets up the DRM to have the ability to have permanent maps while the driver is loaded... Is it really necessary to limit drivers to a single framebuffer-type mapping? Just in case anyone is wondering this is why I can be a bit slow pushing to Linus, finding these issues takes time... this patch looked okay to me but I never knew what the savage was up to ... I don't think there is any reason to limit it to only one mapping, Hopefully Jon can think of a way around it, you should be able to back out that change on your system for now until Jon gets online.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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 -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person -- Jon Smirl [EMAIL PROTECTED] --- 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: Savage DRM problem: multiple framebuffer mappings
I decided my loop was too fancy so I just deleted it and replaced it
with a simple flag. If the driver uses permanent maps the flag gets
set and addmaps from user space have no effect. If the driver doesn't
use permanent maps everything should work the old way.
If this looks good I can check it in.
= linux/drm_bufs.h 1.8 vs edited =
--- 1.8/linux/drm_bufs.h Sun Sep 5 21:22:06 2004
+++ edited/linux/drm_bufs.h Mon Sep 6 20:07:59 2004
@@ -59,6 +59,8 @@
return order;
}
+static int permanent_maps = 0;
+
/**
* Adjusts the memory offset to its absolute value according to the mapping
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
@@ -116,7 +118,8 @@
down(dev-struct_sem);
list_add(list-head, dev-maplist-head);
up(dev-struct_sem);
-
+
+ permanent_maps = 1;
DRM_DEBUG(finished\n);
return 0;
@@ -175,20 +178,10 @@
switch ( map-type ) {
case _DRM_REGISTERS:
case _DRM_FRAME_BUFFER: {
- /* after all the drivers switch to permanent mapping this should just return an error */
- struct list_head *_list;
-
- /* if map already exists, return the existing one instead of creating a new one */
- list_for_each( _list, dev-maplist-head ) {
- drm_map_list_t *_entry = list_entry( _list, drm_map_list_t, head );
- if ( _entry-map _entry-map-type == map-type ) {
-DRM(free)( map, sizeof(*map), DRM_MEM_MAPS );
-map = _entry-map;
-DRM_DEBUG( Found existing: offset = 0x%08lx, size = 0x%08lx, type = %d\n,
- map-offset, map-size, map-type );
-goto found_it;
- }
- }
+ /* When using permanent maps ignore the request */
+ if (permanent_maps)
+ goto ignore_it;
+
#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__)
if ( map-offset + map-size map-offset ||
map-offset virt_to_phys(high_memory) ) {
@@ -264,7 +257,7 @@
down(dev-struct_sem);
list_add(list-head, dev-maplist-head);
up(dev-struct_sem);
-found_it:
+ignore_it:
if ( copy_to_user( argp, map, sizeof(*map) ) )
return -EFAULT;
if ( map-type != _DRM_SHM ) {
Re: Savage DRM problem: multiple framebuffer mappings
On Mon, 6 Sep 2004 16:55:10 +0200, Felix Kühling [EMAIL PROTECTED] wrote: after upgrading the DRM (it has been a while since the last cvs update) the Savage driver stopped working. I tracked it down to the DRM refusing to create multiple framebuffer-type mappings. If it finds an existing mapping it returns it instead of creating a new one. However, the Savage driver needs multiple framebuffer-type mappings. The real frame buffer is supplemented by a so-called aperture where front/back/depth buffers can be accessed at fixed addresses (independent of their actual locations in the frame buffer) linearly even if the framebuffer is physically tiled. This behaviour is controlled by a set of tiled surface registers (IIRC). The HwMC code makes yet another framebuffer-type mapping. :-/ Does the Savage DRM driver know enough to make these extra mappings? Or is computation in user space required? Is it possible for the Savage DRMdriver to create the necessary maps using initmap like I did in the Radeon example? I was unaware of this feature of the Savage chipset when I made the changes and I don't own one to test with. Is there a representative PCI card available for this chipset? -- Jon Smirl [EMAIL PROTECTED] --- 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
