Re: [Dri-devel] Problems with the radeon 1.9.0 driver in 2.6.0-test9-mm2
In message <[EMAIL PROTECTED]> you write: > On Fri, 2003-11-07 at 23:05, Andrew Morton wrote: > > > > Has anyone actually tested the functionality which this patch is supposed > > to provide? That loading the DRM module magically triggers a load of AGP? > > Haven't tried it, but I doubt it does looking at the code for symbol_get > and friends... try_then_request_module() might do the trick instead? symbol_request() is what you want here. Sorry, was away. Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] the state of Parhelia on FreeBSD
Jan Eidtmann wrote: So, support for three new cards in one mtx driver sounds just great, isnt it? *looks at DRI developers* PLEASE DO IT I can't (and don't) speak for all the DRI developers, but supporting a kernel modules for a closed-source client-side driver is so low on the priority list that all other potential DRI related projects would have to cease to exist before it would it even be considered. (It's run-on sentance Monday!) On the flip side, I believe that all the Parhelia related chips are programmable-pipeline only (i.e., no fixed function hardware). Even if Matrox did release all the required documentation, the Mesa infrastructure isn't far enough along to /properly/ support it. --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fedora + DRI R200 binary snapshots - libGL problem
Sergey V. Oudaltsov wrote: I just took the R200 snapshot and trying to run in on Radeon R250 Lf (Mobility). First, I encountered the problem with ABI version (6 vs 7) but after taking XFree86 executable from some well-known place (mentioned in FAQ) XFree finally took off (first question - would it be possible to include this binary into R200 snapshots - it is necessary anyway). Now I am trying to run glxinfo - and it says there is no DRI. What could this be? I even tried to say explicitly LD_PRELOAD=... (pointing to libGL.so.1.2 shipped with the snapshot). Still no direct rendering. What could this be? XFree86.0.log says I _do_ have dri enabled. (funny enough, the main reason to try DRI snapshots was broken dynamic access to GL in Fedora's libGL - no way to play Half-Life:). I don't remember the exact details, but I believe Fedora has separate TLS enabled libraries. You may be picking that up instead of the new non-TLS libGL. Could you be more specific what you mean by "problem with ABI version"? --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] the state of Parhelia on FreeBSD
Ian Romanick wrote: Jan Eidtmann wrote: So, support for three new cards in one mtx driver sounds just great, isnt it? *looks at DRI developers* PLEASE DO IT I can't (and don't) speak for all the DRI developers, but supporting a kernel modules for a closed-source client-side driver is so low on the priority list that all other potential DRI related projects would have to cease to exist before it would it even be considered. (It's run-on sentance Monday!) On the flip side, I believe that all the Parhelia related chips are programmable-pipeline only (i.e., no fixed function hardware). Even if Matrox did release all the required documentation, the Mesa infrastructure isn't far enough along to /properly/ support it. Actually I don't agree with the last bit. There's not much missing from mesa in that regard. Keith --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 4:00PM EST or 1:00PM PST, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Programmable-pipeline hardware (was Re: [Dri-devel] the state of Parhelia on FreeBSD)
Keith Whitwell wrote: Ian Romanick wrote: sentance Monday!) On the flip side, I believe that all the Parhelia related chips are programmable-pipeline only (i.e., no fixed function hardware). Even if Matrox did release all the required documentation, the Mesa infrastructure isn't far enough along to /properly/ support it. Actually I don't agree with the last bit. There's not much missing from mesa in that regard. There's two ways to handle this sort of hardware. You can either have a ton of pre-compiled bits of code (for the GPU) to implement various parts of the pipeline. Those pre-compiled bits get pulled together depending on the state-vector. The other way is to pull together code depending on the state-vector and compile it at run-time. Right now Mesa can do the first method. IMO, that doesn't /properly/ support the hardware. One of the nice things about the way Mesa is architected is that the burden of implementing new functionality falls on Mesa. Going the first route shifts that burden to the device-specific code. The current situation with Mesa and programmable-pipeline only hardware is a lot like the situation was with Mesa 4.x and TCL hardware. It's doable, but it's not idea. That's all I was trying to say before. --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Quake3 w/ r_primitives != 0
Has anyone tried Quake3 with r_primitives != 0 on non mga cards? There's something very wrong with texture coordinates on mga. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
