Re: Improve state emitting for ipers
On Mon, 2004-09-20 at 15:00, Roland Scheidegger wrote: > Eric Anholt wrote: > > The attached patch removes the mandatory emits of all state which were > > happening after each cmdbuf flush. Instead, we set a flag after a > > cmdbuf flush saying "save the state at the next unlock," which means > > memcpying the state atoms off. When we actually see the context get > > lost, then we "back up" and restore state -- make a new cmdbuf, dirty > > all state, emit it, flush it, then put the old cmdbuf back. > I like it ;-). I thought the locking really to be inefficient (but never > did anything against it...). It was that state emit to ensure lost-context recovery that was the real killer. While working on it, I thought, "Man, all of this lock/unlocking going on has to have bad effects on performance." So I made (UN)LOCK_HARDWARE into inlines, and they were only around .01% of CPU time according to oprofile. So I'm not too worried about locking. One thing that I had talked about with Keith when working on the race fixes was the possibility of making the DRI locks recursive. This would let us be lazier about coding sometimes, but would also make DRI modules integration into the server (for hardware indirect) easier. While recursive acquires are more expensive, it looks like the locking costs aren't really an issue. > > I also > > removed the dirty/clean state lists and made a single one. The > > reasoning was that we have to walk the entire list on emit (and twice > > when the all-dirty is set) anyway, and I felt that this was cleaner. > It was not always that inefficient in r200EmitState, only since the > fixed emit order was introduced (and still no one understands why the > fixed order is needed). Didn't seem to make a performance difference > though (profiling showed it really didn't use much cpu time). Yeah, it was clear that we used to emit in whatever order, and that would have been nicer. At this point I'm seeing about 5% CPU time in EmitState for ipers, which seems pretty hefty for such a small bit of code, but I didn't see much obvious for improvement. Fixed order (at least within limits) being required certainly makes sense to me. I've found that docs sometimes say things like, "Writes to this register take no effect if bits X of register Y are not set to Z." It may be that those dependencies were just not recorded. > > This gets about a 5% speedup for me in ipers (which I wish was more > > accurate in its reporting), and doesn't touch glxgears. I didn't have > > any interesting apps besides glxgears handy to benchmark with. Any > > thoughts on this? If people think it's a good idea, I'll do it for > > radeon as well. > I certainly think it's a good idea. > However, I still think it should be possible to lock across multiple > buffers, to make it possible to emit larger numbers of vertices at once > (for instance for things like glDrawElements), which, as far as I > understand, just cannot work if you're restricted to one buffer. Multiples of which buffers are you talking about here? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [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
Re: Savage DRI merged to xorg
On Tue, 21 Sep 2004 00:56:38 +0100, Sérgio Monteiro Basto <[EMAIL PROTECTED]> wrote: > Hi > On Thu, 2004-09-16 at 14:17, Alex Deucher wrote: > > regarding mergedfb, Sergio, what chip do you have? > > 86C387 TwisterK (8D02) > S3 Inc. VT8636A [ProSavage KN133] AGP4X VGA Controller (TwisterK) AFAIK, twisters only have one crtc. > > > Is it working for > > you? I've had some reports of problems with supersavages. > > Follow a tip for xorg ML, I test run: > > Xvfb :30 -ac -screen 0 1024x768x24 -fbdir /usr/tmp > mozilla --display :30.0 > xwud -in /usr/tmp/Xvfb_screen0 > > and I see one window with mozilla correctly, so look like fb it is > working ! I think you are mixing things up. mergedfb has nothing to do with framebuffer devices. it's a special dualhead mode where both crtcs point into a shared, "merged," framebuffer, so things like the dri work in dualhead mode. Alex > > thanks, > -- > Sérgio M. B. > > --- 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: DRM radeon i2c support and GPL
On Tue, 21 Sep 2004 00:10:31 +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > On Llu, 2004-09-20 at 18:38, Adam Jackson wrote: > > Inclusion is not conversion, in this case. All the copyright statements in > > the DRM source (excluding your recent commit) specify BSD licenses. If the > > bug-fixers wanted their changes to apply under the GPL they should have > > indicated that by changing the copyright statement at the top of the file. > > Some of the pure Linux code is clearly derivative of existing GPL code. > I personally don't see the issue for platform specific code that isn't > meant to be and won't be portable. Providing that code is also clearly > marked. Is there a reason however for not starting from the X code for > doing this management ? I picked a very simple piece of code to start out with as a test case. The I2C code is only a hundred lines and could be rewritten. But what's the point, BSD doesn't have Linux's I2C driver system. This code has no value anywhere but on Linux. There are more complicated files that I am looking at. For example sysfs support, it is much easier to just copy class_simple.c into the project and start editing on it that it is to write it all over again. GregKH even recommends doing this when you need a class that is more complex than simple. -- 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
Re: DRM radeon i2c support and GPL
On Llu, 2004-09-20 at 18:38, Adam Jackson wrote: > Inclusion is not conversion, in this case. All the copyright statements in > the DRM source (excluding your recent commit) specify BSD licenses. If the > bug-fixers wanted their changes to apply under the GPL they should have > indicated that by changing the copyright statement at the top of the file. Some of the pure Linux code is clearly derivative of existing GPL code. I personally don't see the issue for platform specific code that isn't meant to be and won't be portable. Providing that code is also clearly marked. Is there a reason however for not starting from the X code for doing this management ? --- 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: Redirect GL to off-screen or pixmap
On Monday 20 September 2004 17:54, Amir Bukhari wrote: > On Mon, 2004-09-20 at 23:44, Ian Romanick wrote: > > Direct rendering: > > > > APP -> libGL -> DRI driver (*_dri.so) -> DRM (kernel module) -> hardware > > > > Indirect rendering: > > > > APP -> libGL -> GLX protocol to X-server -> ? > > > > In the current implementation "?" is software Mesa. However, in the > > future it will likely be " -> DRI driver -> DRM -> hardware". "Direct" > > just means that access to the framebuffer and graphics hardware happens > > in the address space of the application (i.e., the application directly > > accesses the graphics hardware). > > that mean all applications, which linked with libglx, will be only > software rendered at this moment, when DRI is used. I don't want to talk > when using GLX module from nvidia. Nvidia is outside our scope. Just to clarify, libglx is not a client-side library. libglx is a server module that implements the server side of the GLX protocol. Apps are not linked against libglx. - ajax --- 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: Redirect GL to off-screen or pixmap
Amir Bukhari wrote: that mean all applications, which linked with libglx, will be only software rendered at this moment, when DRI is used. I don't want to talk when using GLX module from nvidia. Nvidia is outside our scope. Applications don't link with libglx. libglx is a module loaded by the X-server. Applications only link with libGL.so. At run-time libGL determines whether or not direct rendering is available, and applications select whether or not they want to use it. Right now, if direct rendering is not used, everything is done in software. --- 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: Improve state emitting for ipers
Eric Anholt wrote: The attached patch removes the mandatory emits of all state which were happening after each cmdbuf flush. Instead, we set a flag after a cmdbuf flush saying "save the state at the next unlock," which means memcpying the state atoms off. When we actually see the context get lost, then we "back up" and restore state -- make a new cmdbuf, dirty all state, emit it, flush it, then put the old cmdbuf back. I like it ;-). I thought the locking really to be inefficient (but never did anything against it...). I also removed the dirty/clean state lists and made a single one. The reasoning was that we have to walk the entire list on emit (and twice when the all-dirty is set) anyway, and I felt that this was cleaner. It was not always that inefficient in r200EmitState, only since the fixed emit order was introduced (and still no one understands why the fixed order is needed). Didn't seem to make a performance difference though (profiling showed it really didn't use much cpu time). This gets about a 5% speedup for me in ipers (which I wish was more accurate in its reporting), and doesn't touch glxgears. I didn't have any interesting apps besides glxgears handy to benchmark with. Any thoughts on this? If people think it's a good idea, I'll do it for radeon as well. I certainly think it's a good idea. However, I still think it should be possible to lock across multiple buffers, to make it possible to emit larger numbers of vertices at once (for instance for things like glDrawElements), which, as far as I understand, just cannot work if you're restricted to one buffer. Roland --- 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: Redirect GL to off-screen or pixmap
On Mon, 2004-09-20 at 23:44, Ian Romanick wrote: > Amir Bukhari wrote: > > > I will start on it from now on, but I have a small question. is indirect > > rendering use 3D accelarator for 3D operation or it is all software? > > > > for example glxgear use GLX, is that mean it use indirect rendering? > > > > APP ---> GLX (libglx) > DRI ---> Hardware. (indirect rendering) > > APP ---> DRI (libGL) > Hardware. (direct rendering) > > > > is this schema correct? > > Not 100% > > Direct rendering: > > APP -> libGL -> DRI driver (*_dri.so) -> DRM (kernel module) -> hardware > > Indirect rendering: > > APP -> libGL -> GLX protocol to X-server -> ? > > In the current implementation "?" is software Mesa. However, in the > future it will likely be " -> DRI driver -> DRM -> hardware". "Direct" > just means that access to the framebuffer and graphics hardware happens > in the address space of the application (i.e., the application directly > accesses the graphics hardware). that mean all applications, which linked with libglx, will be only software rendered at this moment, when DRI is used. I don't want to talk when using GLX module from nvidia. Nvidia is outside our scope. --- 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: Redirect GL to off-screen or pixmap
Amir Bukhari wrote: I will start on it from now on, but I have a small question. is indirect rendering use 3D accelarator for 3D operation or it is all software? for example glxgear use GLX, is that mean it use indirect rendering? APP ---> GLX (libglx) > DRI ---> Hardware. (indirect rendering) APP ---> DRI (libGL) > Hardware. (direct rendering) is this schema correct? Not 100% Direct rendering: APP -> libGL -> DRI driver (*_dri.so) -> DRM (kernel module) -> hardware Indirect rendering: APP -> libGL -> GLX protocol to X-server -> ? In the current implementation "?" is software Mesa. However, in the future it will likely be " -> DRI driver -> DRM -> hardware". "Direct" just means that access to the framebuffer and graphics hardware happens in the address space of the application (i.e., the application directly accesses the graphics hardware). --- 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: Redirect GL to off-screen or pixmap
> > A pbuffer is the GL analog of an offscreen pixmap. The spec is at > http://oss.sgi.com/projects/ogl-sample/registry/SGIX/pbuffer.txt > > Currently we have support for pbuffers in indirect contexts only, which are > contexts where the server does the rendering (in our case, in software). > Direct contexts under DRI do not yet support pbuffers. > > Composite enables the compmgr to redirect drawing of a window from the screen > to an offscreen pixmap, for normal X windows. GL windows would have to be > redirected to a pbuffer in a similar fashion. > > > I know how Composite is implemented and I use it in our Project Looking > > Glass, but my knowledge on GL and DRI is basicly as User not a developer > > in DRI. as I will work in this issue I will get slowly inside DRI. > > > > I will start on it from now on, but I have a small question. is indirect rendering use 3D accelarator for 3D operation or it is all software? for example glxgear use GLX, is that mean it use indirect rendering? APP ---> GLX (libglx) > DRI ---> Hardware. (indirect rendering) APP ---> DRI (libGL) > Hardware. (direct rendering) is this schema correct? -- Amir Bukhari <[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
Re: Redirect GL to off-screen or pixmap
On Monday 20 September 2004 15:36, Amir Bukhari wrote: > On Mon, 2004-09-20 at 19:47, Adam Jackson wrote: > > You still want pbuffers. Composite should enable the compmgr to redirect > > GL contexts to pbuffers without the GL app knowing about it. This > > requires more pbuffer support than currently exists in DRI, and also > > requires extending the Composite code to handle this case. > > > > You might start by extending Composite to work with the pbuffer support > > we have in software, which would enable composition for indirect > > rendering contexts. It wouldn't be fast, but it'd be a working demo at > > least. > > I am a new to DRI structure and GL. could you explain what pbuffer is > and where it be used? A pbuffer is the GL analog of an offscreen pixmap. The spec is at http://oss.sgi.com/projects/ogl-sample/registry/SGIX/pbuffer.txt Currently we have support for pbuffers in indirect contexts only, which are contexts where the server does the rendering (in our case, in software). Direct contexts under DRI do not yet support pbuffers. Composite enables the compmgr to redirect drawing of a window from the screen to an offscreen pixmap, for normal X windows. GL windows would have to be redirected to a pbuffer in a similar fashion. > I know how Composite is implemented and I use it in our Project Looking > Glass, but my knowledge on GL and DRI is basicly as User not a developer > in DRI. as I will work in this issue I will get slowly inside DRI. > > > > --- > 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 --- 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: Improve state emitting for ipers
Eric Anholt wrote: This gets about a 5% speedup for me in ipers (which I wish was more accurate in its reporting), and doesn't touch glxgears. I didn't have any interesting apps besides glxgears handy to benchmark with. I should be able to give it a spin on viewperf sometime this week... --- 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: Improve state emitting for ipers
Am Montag, 20. September 2004 21:52 schrieb Dieter Nützel: > Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt: > > The attached patch removes the mandatory emits of all state which were > > happening after each cmdbuf flush. Instead, we set a flag after a > > cmdbuf flush saying "save the state at the next unlock," which means > > memcpying the state atoms off. When we actually see the context get > > lost, then we "back up" and restore state -- make a new cmdbuf, dirty > > all state, emit it, flush it, then put the old cmdbuf back. I also > > removed the dirty/clean state lists and made a single one. The > > reasoning was that we have to walk the entire list on emit (and twice > > when the all-dirty is set) anyway, and I felt that this was cleaner. It > > also fixed some bad cmdbufs that were happening for me (drmCommandWrite: > > -22) with the CVS code. > > > > This gets about a 5% speedup for me in ipers (which I wish was more > > accurate in its reporting), > > Do you think it's only 5% for you? > > It is GREAT. > > Ipers is back when not faster ever on my system ;-) > > 31 fps, 825.000 from ~25, ~660.000 > > => 24% But got progs/demos> IperS V1.0 Written by David Bucciarelli ([EMAIL PROTECTED]) Mesa: software DXTn compression/decompression available drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) [1]Exitcode 234 ./ipers when I cycle through the drawing modes (t/b/n) during wire frame (p). -Dieter --- 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: Improve state emitting for ipers
Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt: > The attached patch removes the mandatory emits of all state which were > happening after each cmdbuf flush. Instead, we set a flag after a > cmdbuf flush saying "save the state at the next unlock," which means > memcpying the state atoms off. When we actually see the context get > lost, then we "back up" and restore state -- make a new cmdbuf, dirty > all state, emit it, flush it, then put the old cmdbuf back. I also > removed the dirty/clean state lists and made a single one. The > reasoning was that we have to walk the entire list on emit (and twice > when the all-dirty is set) anyway, and I felt that this was cleaner. It > also fixed some bad cmdbufs that were happening for me (drmCommandWrite: > -22) with the CVS code. > > This gets about a 5% speedup for me in ipers (which I wish was more > accurate in its reporting), Do you think it's only 5% for you? It is GREAT. Ipers is back when not faster ever on my system ;-) 31 fps, 825.000 from ~25, ~660.000 => 24% > and doesn't touch glxgears. dito > I didn't have > any interesting apps besides glxgears handy to benchmark with. Any > thoughts on this? VTK (sphere-bench.tcl-2.1) We get much faster "full speed" and top-speed is little better. Benching for sphere resolutions : 32, 64, 128, 256, 512 Setting(s) : window is 400 x 400, sphere radius is 0.9 Option(s) : [wireframe] 32x32 : 803.1 kpolys/s 64x64 : 2002.2 kpolys/s 128x128 : 2654.4 kpolys/s 256x256 : 2743.9 kpolys/s 512x512 : 2797.4 kpolys/s quake3-smp is NOT on pair (before slow down) ~163 fps (was ~174 fps) > If people think it's a good idea, I'll do it for > radeon as well. It IS ;-) Thanks, Dieter --- 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: Redirect GL to off-screen or pixmap
On Mon, 2004-09-20 at 19:47, Adam Jackson wrote: > On Monday 20 September 2004 13:17, Amir Bukhari wrote: > > On Mon, 2004-09-20 at 18:47, Ian Romanick wrote: > > > I just want to clarify things. Do you want to write a new application > > > that renders to off-screen or do you want to redirect the output of an > > > arbitrary existing appliation to off-screen? If you want to write a new > > > application that renders to off-screen, Keith is right. You want to use > > > pbuffers. > > > > Nope. I don't want to write a new application which rendered to > > offscreen. > > All GL application are rendered inside a window (x window), I want to > > redirect this window, which is associated to GL to offscreen. I need > > this because I work on 3D Desktop, which use XComposite extension to > > redirect requested windows to offscreen. so I can manage then in 3D > > Desktop. GL Applications can't currently be redirect to offscreen by > > XComposite, because DRI write directly to screen, it didn't use X Server > > BitBlit operations, which access the framebuffer of the video card. > > You still want pbuffers. Composite should enable the compmgr to redirect GL > contexts to pbuffers without the GL app knowing about it. This requires more > pbuffer support than currently exists in DRI, and also requires extending the > Composite code to handle this case. > > You might start by extending Composite to work with the pbuffer support we > have in software, which would enable composition for indirect rendering > contexts. It wouldn't be fast, but it'd be a working demo at least. I am a new to DRI structure and GL. could you explain what pbuffer is and where it be used? I know how Composite is implemented and I use it in our Project Looking Glass, but my knowledge on GL and DRI is basicly as User not a developer in DRI. as I will work in this issue I will get slowly inside DRI. --- 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 M6 (r200) - [drm] drmAddMap failed
Felix, I'm removing the size check from addmap with a permanent map. I've now encountered X asking for maps both smaller and larger that what the hardware allows. This is why we need to get this code out of X an into the driver. I'll fix the code to map the legal value for the hardware (from the permanent map) and return that info to X. -- 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
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 5:00PM EDT or 2:00PM PDT, 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: 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
[Bug 1428] drmAddMap failed with latest drm CVS
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=1428 --- Additional Comments From [EMAIL PROTECTED] 2004-09-20 11:07 --- Yes, just noticed a similar problem mentioned on the mailing list, and the new commits to cvs. Tried again, similar result as the person on the list: (==) RADEON(0): Write-combining range (0xd000,0x800) (II) RADEON(0): Dynamic Clock Scaling Disabled drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci::02:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::02:00.0 (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created "radeon" driver at busid "pci::02:00.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe09c (II) RADEON(0): [drm] mapped SAREA 0xe09c to 0x498aa000 (II) RADEON(0): [drm] framebuffer handle = 0xd000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000207 [AGP 0x10de/0x01e0; Card 0x1002/0x514c] (II) RADEON(0): [agp] 65536 kB allocated with handle 0x0001 (II) RADEON(0): [agp] ring handle = 0xe000 (II) RADEON(0): [agp] Ring mapped at 0x498ac000 (II) RADEON(0): [agp] ring read ptr handle = 0xe0101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x499ad000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xe0102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x499ae000 (II) RADEON(0): [agp] GART texture map handle = 0xe0302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x49bae000 (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe09c at 0x498aa000 (II) RADEON(0): Memory manager initialized to (0,0) (1024,8191) (II) RADEON(0): Reserved area from (0,768) to (1024,770) (II) RADEON(0): Largest offscreen area available: 1024 x 7421 (II) RADEON(0): Render acceleration enabled (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0): Acceleration enabled (==) RADEON(0): Backing store disabled (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Using hardware cursor (scanline 770) (II) RADEON(0): Largest offscreen area available: 1024 x 7417 (**) Option "dpms" (**) RADEON(0): DPMS enabled (II) RADEON(0): Direct rendering disabled ... and in the kernel messages: [drm:radeon_ioctl] pid=8708, cmd=0xc0106434, nr=0x34, dev 0xe200, auth=1 [drm:radeon_ioctl] pid=8708, cmd=0x40086436, nr=0x36, dev 0xe200, auth=1 [drm:radeon_agp_bind] base = 0xe000 entry->bound = 0xe000 [drm:radeon_ioctl] pid=8708, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:radeon_addmap] offset = 0x, size = 0x00101000, type = 3 [drm:radeon_mmap] start = 0x498ac000, end = 0x499ad000, offset = 0xe000 [drm:radeon_mmap]Type = 3; start = 0x498ac000, end = 0x499ad000, offset = 0xe 000 [drm:radeon_vm_open] 0x498ac000,0x00101000 [drm:radeon_ioctl] pid=8708, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:radeon_addmap] offset = 0x00101000, size = 0x1000, type = 3 [drm:radeon_mmap] start = 0x499ad000, end = 0x499ae000, offset = 0xe0101000 [drm:radeon_mmap]Type = 3; start = 0x499ad000, end = 0x499ae000, offset = 0xe 0101000 [drm:radeon_vm_open] 0x499ad000,0x1000 [drm:radeon_ioctl] pid=8708, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:radeon_addmap] offset = 0x00102000, size = 0x0020, type = 3 [drm:radeon_mmap] start = 0x499ae000, end = 0x49bae000, offset = 0xe0102000 [drm:radeon_mmap]Type = 3; start = 0x499ae000, end = 0x49bae000, offset = 0xe 0102000 [drm:radeon_vm_open] 0x499ae000,0x0020 [drm:radeon_ioctl] pid=8708, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:radeon_addmap] offset = 0x00302000, size = 0x03c0, type = 3 [drm:radeon_mmap] start = 0x49bae000, end = 0x4d7ae000, offset = 0xe0302000 [drm:radeon_mmap]Type = 3; start = 0x49bae000, end = 0x4d7ae000, offset = 0xe 0302000 [drm:radeon_vm_open] 0x49bae000,0x03c0 [drm:radeon_ioctl] pid=8708, cmd=0x80206433, nr=0x33, dev 0xe200, auth=1 [drm:radeon_ioctl] pid=8708, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:radeon_addmap] offset = 0xe500, size = 0x0008, type = 1 [drm:radeon_ioctl] pid=8708, cmd=0x40546440, nr=0x40, dev 0xe200, auth=1 [drm:radeon_cp_init] *ERROR* radeon_cp_init called with
[Bug 1428] drmAddMap failed with latest drm CVS
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=1428 --- Additional Comments From [EMAIL PROTECTED] 2004-09-20 11:02 --- I checked in the fix for this a few minutes ago. This bug is still in the radeon driver, i haven't located the problem yet. [drm:radeon_ioctl] pid=10687, cmd=0x6430, nr=0x30, dev 0xe200, auth=1 [drm:radeon_ioctl] pid=10687, cmd=0x40546440, nr=0x40, dev 0xe200, auth=1 [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held [drm:radeon_ioctl] pid=10687, cmd=0xc0086426, nr=0x26, dev 0xe200, auth=1 [drm:radeon_ioctl] pid=10687, cmd=0xc0086426, nr=0x26, dev 0xe200, auth=1 [drm:radeon_ioctl] pid=10687, cmd=0x4008642b, nr=0x2b, dev 0xe200, auth=1 [drm:radeon_unlock] *ERROR* Process 10687 using kernel context 0 [drm:radeon_vm_shm_close] 0xb3f0e000,0x2000 -- 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: 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: Redirect GL to off-screen or pixmap
On Monday 20 September 2004 13:17, Amir Bukhari wrote: > On Mon, 2004-09-20 at 18:47, Ian Romanick wrote: > > I just want to clarify things. Do you want to write a new application > > that renders to off-screen or do you want to redirect the output of an > > arbitrary existing appliation to off-screen? If you want to write a new > > application that renders to off-screen, Keith is right. You want to use > > pbuffers. > > Nope. I don't want to write a new application which rendered to > offscreen. > All GL application are rendered inside a window (x window), I want to > redirect this window, which is associated to GL to offscreen. I need > this because I work on 3D Desktop, which use XComposite extension to > redirect requested windows to offscreen. so I can manage then in 3D > Desktop. GL Applications can't currently be redirect to offscreen by > XComposite, because DRI write directly to screen, it didn't use X Server > BitBlit operations, which access the framebuffer of the video card. You still want pbuffers. Composite should enable the compmgr to redirect GL contexts to pbuffers without the GL app knowing about it. This requires more pbuffer support than currently exists in DRI, and also requires extending the Composite code to handle this case. You might start by extending Composite to work with the pbuffer support we have in software, which would enable composition for indirect rendering contexts. It wouldn't be fast, but it'd be a working demo at least. - ajax pgpEN1GFO08QW.pgp Description: PGP signature
[Bug 1428] New: drmAddMap failed with latest drm CVS
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=1428 Summary: drmAddMap failed with latest drm CVS Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DRM modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] With a drm module from CVS from today (and Xorg CVS + Mesa CVS), direct rendering isn't enabled. The following is in the Xorg log file: (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created "radeon" driver at busid "pci::02:00.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0985000 (II) RADEON(0): [drm] mapped SAREA 0xe0985000 to 0x498aa000 (II) RADEON(0): [drm] drmAddMap failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. ... Reverting back to drm CVS from 16 Sept (before dyn-minor patch was re-applied), makes everything work as normal again. -- 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: 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: DRM radeon i2c support and GPL
On Monday 20 September 2004 12:59, Jon Smirl wrote: > On Mon, 20 Sep 2004 12:29:30 -0400, Adam Jackson <[EMAIL PROTECTED]> wrote: > > License compatibility != OS compatibility, please don't conflate the two. > > X runs on more than just Linux, and source is distributed as an > > aggregate. If > > The Linux DRM driver does not run anywhere but on Linux. The GPL code > is isolated to the Linux DRM driver. > > I wonder if DRM isn't GPL already by accident. DRM has been included > in the Linux kernel under the GPL license. DRM has also accepted many > bug patches back from the kernel people. If a fork had occurred > between kernel and DRM it would be clear than one fork is GPL and one > BSD. But the code never forked. Since there is only one code base and > that code base has been released GPL via the kernel, so we may have > inadvertently made DRM GPL. I would read it as "since the code never forked, we're still BSD". Inclusion is not conversion, in this case. All the copyright statements in the DRM source (excluding your recent commit) specify BSD licenses. If the bug-fixers wanted their changes to apply under the GPL they should have indicated that by changing the copyright statement at the top of the file. The aggregate kernel is GPL, yes, but that doesn't mean all the components are. ppp_deflate.c has gotten fixes from kernel people too, but it's still BSD-licensed. > I'd feel a whole lot better about the licensing if BSD and Linux DRM > were split into two repositories. That still wouldn't address the issue of inclusion in Xorg, unless Xorg were to only ship with the BSD DRM. And it would probably demote the BSD OSes to fifth-class citizen status. Can't say as I'm a fan of that idea. > > it's really that big of a deal, ask the author of the GPL code to allow > > you to add it to DRM under an X-friendly license. > > This is a waste of time. I know that some of the authors have a GPL or > die attitude towards device driver code. Reimplementing code that the original author doesn't want to relicense is nothing new under the sun (freeglut). I believe that splintering the code base into universal and GPL versions is a bad idea, because it means any code in the GPL version that someone wants to use in the universal version has to be written twice - inevitably diverging the two trees and creating the sort of cross-merge hell we're trying to get away from. If we're going to "waste time" like this, we might as well do it once, up front, and be done with it. - ajax pgpyxgKSdXzjn.pgp Description: PGP signature
Re: Strawman licensing policy (was: DRM radeon i2c support and GPL)
Also note the embedded issue raised during the Cairo relicencing discussion, however. We have a lot of embedded X use both historically and going forward; I know that hasn't occurred much in the DRI part of the world, but it is commonplace for X itself, and can be expected to be common in the future for DRI as well. We need to understand that issue better, as my strawman states. - Jim On Mon, 2004-09-20 at 13:25, Jon Smirl wrote: > This policy prevents code reuse from other parts of Linux. It is > counter productive to take working GPL code that is specific to Linux, > rewrite it for the MIT license, and then resubmit it to Linux under > the GPL again. The policy is fine for the cross platform code but it > doesn't make sense for the platform specific code. --- 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: Strawman licensing policy (was: DRM radeon i2c support and GPL)
I think if you read it again more carefully, it doesn't say that. Of course, it is a strawman I just put together, so I may not have said what I meant - Jim On Mon, 2004-09-20 at 13:25, Jon Smirl wrote: > This policy prevents code reuse from other parts of Linux. It is > counter productive to take working GPL code that is specific to Linux, > rewrite it for the MIT license, and then resubmit it to Linux under > the GPL again. The policy is fine for the cross platform code but it > doesn't make sense for the platform specific code. --- 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: Strawman licensing policy (was: DRM radeon i2c support and GPL)
This policy prevents code reuse from other parts of Linux. It is counter productive to take working GPL code that is specific to Linux, rewrite it for the MIT license, and then resubmit it to Linux under the GPL again. The policy is fine for the cross platform code but it doesn't make sense for the platform specific code. -- 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
Re: Redirect GL to off-screen or pixmap
On Mon, 2004-09-20 at 18:47, Ian Romanick wrote: > Amir Bukhari wrote: > > > that is correct if the client use DRI, but what if the applications use > > GLX extension like "glxgeer". I think getting GLX is simpler than > > getting DRI. for examlpe by catcing attaching GL to window and let GLX > > assume this just a pixmap not a window, thus it will render it to a > > pixmap. > > I just want to clarify things. Do you want to write a new application > that renders to off-screen or do you want to redirect the output of an > arbitrary existing appliation to off-screen? If you want to write a new > application that renders to off-screen, Keith is right. You want to use > pbuffers. Nope. I don't want to write a new application which rendered to offscreen. All GL application are rendered inside a window (x window), I want to redirect this window, which is associated to GL to offscreen. I need this because I work on 3D Desktop, which use XComposite extension to redirect requested windows to offscreen. so I can manage then in 3D Desktop. GL Applications can't currently be redirect to offscreen by XComposite, because DRI write directly to screen, it didn't use X Server BitBlit operations, which access the framebuffer of the video card. -- Amir Bukhari <[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
Strawman licensing policy (was: DRM radeon i2c support and GPL)
Keith, We haven't managed to write such a policy down yet, and demonstrate full consensus of the community. So far, I'd describe the policy today as "first, do no harm". It is certainly on the board's radar screen to try help the community generate a policy with full feedback from the membership. Also note that with the intention of modularizing the distribution, new parts of the system may in the future be available under different terms than has been true under the past. I'll take a crack at enunciating a policy now, however, to help get the discussion going. I've stated this position informally in a number of forums and have had encouraging feedback, but as there has not been public review and comment and it has not been written down and accepted, it must be regarded as a strawman. Strawman policy on X.org licensing == Jim Gettys 9/20/2004 version .1 Preamble Many people, organizations and companies, have contributed to the corpus of code distributed by X.org, which has been built over 20 years. An *implicit* unwritten understanding of their contributions to the X Window System code base has been that the code would remain available to them under the same terms that it was made available to the community into the future, though, in fact, there has been no legal terms in the licenses used in X code to enforce this. Violating this trust would be to the long term detriment of X.org, the contributors and organizations that have funded X development. The current body of code is primarily under the "MIT License", which is considered fully acceptable software by the entire community, whether they call themselves open source or free.(*) A description of what it means to be free software may have best been stated by the Debian project, in the Debian Free Software Guidelines (which can be found at: http://www.debian.org/social_contract). Certainly licenses that qualify by these guidelines are the only licenses the full community finds acceptable. Detailed Consequences - a) adding more restrictive copyrights on modifications to existing code bases is not allowed. For example, if a patch or file is added to a library, it may not have copyrights any more restrictive than that of the module which it is a part of, and the usual expectation will be that it be the MIT license or the license used by that module. The most complicated situations come up as software is "aggregated" into larger programs or systems. Interactions among copyrights easily become very complicated, and in fact, contradictions among licenses can occur that prevent aggregates being distributed at all. "Compatibility" between common licenses is a real issue we must continue to be sensitive to, and licenses cannot be arbitrarily mixed *in a system as a result. b) The consequences of a new module that becomes part of a larger program (e.g. a graphics driver in the X server) must be very carefully analyzed before they can be accepted (there can be situations that would make it illegal for the aggregate to be shipped), or it could be that previous contributors contributions might become effectively useless to them, violating the implicit trust given by previous contributors that the terms would not change in the future. c) Similarly, requiring a new dependency on a module may present serious issues. An example might be the required dependency on a GPL only library (note GPL rather than LGPL) for which there is no BSD/MIT licensed equivalent that is required generally for the software to be useful, which might disenfranchise those who may be unwilling to accept such libraries on other platforms. Note that dependencies that are specific to a single platform might or might not generate problems of this class, depending upon the precise circumstances. Note that during the recent Cairo licensing discussion that even the LGPL by itself could be problematic, due to concerns of use in embedded systems, in which X has been and continues to be used. Further understanding of the issues raised during that discussion are needed to understand if those concerns are valid, even though a solution for that particular situation has been found. d) consequences b) and c) argue toward simplicity of licensing; X.org desires to keep the overall aggregate licensing simple and may discourage/forbid the use of licenses that complicate licensing or make aggregate programs or systems difficult or impossible. The board of directors will decide on whether a license not already in use in the module or program in the system is allowed after full public discussion, if consensus during that discussion is not reached. e) new contributions under other DFSG compliant licenses will be considered, so long as conditions a-d are met. I hope this strawman starts a productive discussion.
Re: DRM radeon i2c support and GPL
On Mon, 20 Sep 2004 12:29:30 -0400, Adam Jackson <[EMAIL PROTECTED]> wrote: > License compatibility != OS compatibility, please don't conflate the two. X > runs on more than just Linux, and source is distributed as an aggregate. If The Linux DRM driver does not run anywhere but on Linux. The GPL code is isolated to the Linux DRM driver. I wonder if DRM isn't GPL already by accident. DRM has been included in the Linux kernel under the GPL license. DRM has also accepted many bug patches back from the kernel people. If a fork had occurred between kernel and DRM it would be clear than one fork is GPL and one BSD. But the code never forked. Since there is only one code base and that code base has been released GPL via the kernel, so we may have inadvertently made DRM GPL. I'd feel a whole lot better about the licensing if BSD and Linux DRM were split into two repositories. > it's really that big of a deal, ask the author of the GPL code to allow you > to add it to DRM under an X-friendly license. This is a waste of time. I know that some of the authors have a GPL or die attitude towards device driver code. > > Yes, I think it's silly too. > > - ajax > > > > -- 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
Re: Radeon M6 (r200) - [drm] drmAddMap failed
Hi Jon! Monday 20, at 02:15:26 AM you wrote: > Do you have this fix? > Yes, I have the 20040919 snapshot and drm from cvs, so this patch is applyed here. -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov,speak to ==>JID: [EMAIL PROTECTED] aka L.A. Kostis write to ==>mailto:[EMAIL PROTECTED] ...The information is like the bank...(c) EC8OR --- 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: Redirect GL to off-screen or pixmap
Amir Bukhari wrote: that is correct if the client use DRI, but what if the applications use GLX extension like "glxgeer". I think getting GLX is simpler than getting DRI. for examlpe by catcing attaching GL to window and let GLX assume this just a pixmap not a window, thus it will render it to a pixmap. I just want to clarify things. Do you want to write a new application that renders to off-screen or do you want to redirect the output of an arbitrary existing appliation to off-screen? If you want to write a new application that renders to off-screen, Keith is right. You want to use pbuffers. --- 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: DRM radeon i2c support and GPL
On Monday 20 September 2004 12:08, Jon Smirl wrote: > No GPL code doesn't make sense for the Linux drivers. The only place > Linux drivers can be used is in a GPL environment. For example there > is a 600 line sysfs support skeleton file I want to include. This file > is intended to be brought into a driver and then edited. It is a > complete waste of time recoding and redebugging that file just to make > it BSD compatible when the code won't even run on BSD. License compatibility != OS compatibility, please don't conflate the two. X runs on more than just Linux, and source is distributed as an aggregate. If it's really that big of a deal, ask the author of the GPL code to allow you to add it to DRM under an X-friendly license. Yes, I think it's silly too. - ajax pgpU4ErFqDpAz.pgp Description: PGP signature
Re: DRM radeon i2c support and GPL
No GPL code doesn't make sense for the Linux drivers. The only place Linux drivers can be used is in a GPL environment. For example there is a 600 line sysfs support skeleton file I want to include. This file is intended to be brought into a driver and then edited. It is a complete waste of time recoding and redebugging that file just to make it BSD compatible when the code won't even run on BSD. On Mon, 20 Sep 2004 10:26:45 -0400, Adam Jackson <[EMAIL PROTECTED]> wrote: > > > On Monday 20 September 2004 05:57, Keith Whitwell wrote: > > Jon Smirl wrote: > > > I just checked a small change into DRM CVS that adds sysfs i2c support > > > to the linux radeon driver. The patch includes some GPL licensed code > > > extracted from the Linux kernel. The GPL files are only in the > > > drm/linux directory. No GPL code was added to drm/shared or drm/bsd so > > > the BSD build does not include the GPL code. The two GPL licensed > > > files are clearly marked including warnings not to copy them into the > > > BSD build. > > > > The issue with GPL and drm is as I have stated several times now that we've > > wanted XFree, and now Xorg, to be able to distribute this code as part of > > their tree. > > > > XFree86 had a strong policy against allowing GPL into their tree, I don't > > know what Xorg's stand is. Maybe someone can comment from there? > > I've not heard any discussion to the contrary, so I would assume this is still > the case. > > xc/extras/README claims: > "Packages included here must be redistributable under conditions compatible > with the XFree86 redistribution conditions (see > xc/programs/Xserver/hw/xfree86/doc/COPYRIGHT for examples of compatible > licences)." > > Of course that file no longer exists, and hasn't since before XFree86 4.0. > When it did exist, it only made reference to BSD-style licenses: > http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/doc/Attic/COPYRIGHT > > So this may be an open policy question still, but I suspect the answer is > still "No GPL code". > > --- > > To be honest, I'd just as soon see Mesa removed from extras/ entirely, but - > besides libGLcore - we can't do that until one of Mesa's build targets > (linux-dri probably) is capable of generating a libGL that acts as a GLX > client. This would involve moving the GLX client code from xc/lib/GL/glx > into Mesa; I understand there's been some resistance to that idea in the > past. > > - ajax > -- 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
Re: DRM radeon i2c support and GPL
On Monday 20 September 2004 05:57, Keith Whitwell wrote: > Jon Smirl wrote: > > I just checked a small change into DRM CVS that adds sysfs i2c support > > to the linux radeon driver. The patch includes some GPL licensed code > > extracted from the Linux kernel. The GPL files are only in the > > drm/linux directory. No GPL code was added to drm/shared or drm/bsd so > > the BSD build does not include the GPL code. The two GPL licensed > > files are clearly marked including warnings not to copy them into the > > BSD build. > > The issue with GPL and drm is as I have stated several times now that we've > wanted XFree, and now Xorg, to be able to distribute this code as part of > their tree. > > XFree86 had a strong policy against allowing GPL into their tree, I don't > know what Xorg's stand is. Maybe someone can comment from there? I've not heard any discussion to the contrary, so I would assume this is still the case. xc/extras/README claims: "Packages included here must be redistributable under conditions compatible with the XFree86 redistribution conditions (see xc/programs/Xserver/hw/xfree86/doc/COPYRIGHT for examples of compatible licences)." Of course that file no longer exists, and hasn't since before XFree86 4.0. When it did exist, it only made reference to BSD-style licenses: http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/doc/Attic/COPYRIGHT So this may be an open policy question still, but I suspect the answer is still "No GPL code". --- To be honest, I'd just as soon see Mesa removed from extras/ entirely, but - besides libGLcore - we can't do that until one of Mesa's build targets (linux-dri probably) is capable of generating a libGL that acts as a GLX client. This would involve moving the GLX client code from xc/lib/GL/glx into Mesa; I understand there's been some resistance to that idea in the past. - ajax --- 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
On Sul, 2004-09-19 at 21:40, Keith Packard wrote: > I just need to know where the frame buffer lives; it can move or change > pitch at any time. I can even deal with the frame buffer moving without > warning if necessary. What I can't handle is off-screen memory suddenly > disappearing on me; I need to be able to pull any off-screen data back to > main memory before things get shuffled around. The last one of these you can't get in the hotplug case but thats currently a pretty unusual situation compared to the others --- 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
include linux/cdev.h in drmP.h
As a heads up, in this commit, revision 1.116 date: 2004-09-05 10:54:58 +; author: airlied; state: Exp; lines: +9 -9 merge back bunch of whitespace and misc changes from kernel drmP.h was changed to include , which unfortunately doesn't exist in 2.4 kernels. 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: removed counter related macros..
Dave Airlie wrote: Okay I've just gotten rid of the __HAVE_COUNTER* macros, drivers can now just add their counters in their driver_register_fns routines... I don't know how useful the counters ever were - have you considered just chopping them out altogether? 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Redirect GL to off-screen or pixmap
Amir Bukhari wrote: On Mon, 2004-09-20 at 14:07, Keith Whitwell wrote: Amir Bukhari wrote: On Mon, 2004-09-20 at 13:24, Keith Whitwell wrote: Amir Bukhari wrote: All GL application are displayed at the end on a Window. this window are traditional X Server window, which could be clipped, moved, etc. I would like to add support to redirect the image, which should be displayed at the end of rendering in a window to an off-screen or a pixmap. I want to add this to XComposite extension. is that theoritical could be done? or there technical problem on the current implementation in X server or DRI? Actually, GLX supports rendering to Pixmaps & PBuffers, which seems to be what you're asking for, so no new extensions are required. Have a look at the GLX spec from opengl.org. I will take a look to GLX specification. what I want is not write an application which rendered to offscreen, I want to redirect all GL applications to offscreen, like Composite extension do for normal x window, but this not work for GL. the application didn't know if it rendered to offscreen or directly to screen. I want to get GL applications to be rendered all the time - when I request - to offscreen, that mean the FRONT_BUFFER should be an memory other than the framebuffer on display card. This only done with an extension and Composite extension is created to do this work but the current implementation does not support GL redirection, therefore I want to implement this. This is just a matter of telling the driver where you want it to believe the front buffer is... There are probably complications - eg. if the buffer moves around, but this should all be able to be handled by extending the existing DRI code and drivers. You might need to add some new protocol to the DRI extension, and you lose things like page flipping of course. that is correct if the client use DRI, but what if the applications use GLX extension like "glxgeer". I think getting GLX is simpler than getting DRI. for examlpe by catcing attaching GL to window and let GLX assume this just a pixmap not a window, thus it will render it to a pixmap. DRI is hidden from clients, libGL.so and the drivers use it behind the scenes to talk to code in the X server. 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Redirect GL to off-screen or pixmap
On Mon, 2004-09-20 at 14:07, Keith Whitwell wrote: > Amir Bukhari wrote: > > On Mon, 2004-09-20 at 13:24, Keith Whitwell wrote: > > > >>Amir Bukhari wrote: > >> > >>>All GL application are displayed at the end on a Window. this window are > >>>traditional X Server window, which could be clipped, moved, etc. > >>>I would like to add support to redirect the image, which should be > >>>displayed at the end of rendering in a window to an off-screen or a > >>>pixmap. I want to add this to XComposite extension. > >>> > >>>is that theoritical could be done? or there technical problem on the > >>>current implementation in X server or DRI? > >> > >>Actually, GLX supports rendering to Pixmaps & PBuffers, which seems to be what > >>you're asking for, so no new extensions are required. Have a look at the GLX > >>spec from opengl.org. > >> > > > > I will take a look to GLX specification. > > what I want is not write an application which rendered to offscreen, I > > want to redirect all GL applications to offscreen, like Composite > > extension do for normal x window, but this not work for GL. the > > application didn't know if it rendered to offscreen or directly to > > screen. I want to get GL applications to be rendered all the time - when > > I request - to offscreen, that mean the FRONT_BUFFER should be an memory > > other than the framebuffer on display card. This only done with an > > extension and Composite extension is created to do this work but the > > current implementation does not support GL redirection, therefore I want > > to implement this. > > This is just a matter of telling the driver where you want it to believe the > front buffer is... There are probably complications - eg. if the buffer moves > around, but this should all be able to be handled by extending the existing > DRI code and drivers. You might need to add some new protocol to the DRI > extension, and you lose things like page flipping of course. > that is correct if the client use DRI, but what if the applications use GLX extension like "glxgeer". I think getting GLX is simpler than getting DRI. for examlpe by catcing attaching GL to window and let GLX assume this just a pixmap not a window, thus it will render it to a pixmap. --- 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
drm: removed counter related macros..
Okay I've just gotten rid of the __HAVE_COUNTER* macros, drivers can now just add their counters in their driver_register_fns routines... The only major macro left are the ioctls, I have an inkling of a plan on how to get rid of them.. 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: 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: Redirect GL to off-screen or pixmap
Amir Bukhari wrote: All GL application are displayed at the end on a Window. this window are traditional X Server window, which could be clipped, moved, etc. I would like to add support to redirect the image, which should be displayed at the end of rendering in a window to an off-screen or a pixmap. I want to add this to XComposite extension. is that theoritical could be done? or there technical problem on the current implementation in X server or DRI? Actually, GLX supports rendering to Pixmaps & PBuffers, which seems to be what you're asking for, so no new extensions are required. Have a look at the GLX spec from opengl.org. There is quite a bit of work to get this working with the DRI though. 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Redirect GL to off-screen or pixmap
All GL application are displayed at the end on a Window. this window are traditional X Server window, which could be clipped, moved, etc. I would like to add support to redirect the image, which should be displayed at the end of rendering in a window to an off-screen or a pixmap. I want to add this to XComposite extension. is that theoritical could be done? or there technical problem on the current implementation in X server or DRI? -Amir --- 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: Improve state emitting for ipers
Eric Anholt wrote: The attached patch removes the mandatory emits of all state which were happening after each cmdbuf flush. Instead, we set a flag after a cmdbuf flush saying "save the state at the next unlock," which means memcpying the state atoms off. When we actually see the context get lost, then we "back up" and restore state -- make a new cmdbuf, dirty all state, emit it, flush it, then put the old cmdbuf back. I also removed the dirty/clean state lists and made a single one. The reasoning was that we have to walk the entire list on emit (and twice when the all-dirty is set) anyway, and I felt that this was cleaner. It also fixed some bad cmdbufs that were happening for me (drmCommandWrite: -22) with the CVS code. This gets about a 5% speedup for me in ipers (which I wish was more accurate in its reporting), and doesn't touch glxgears. I didn't have any interesting apps besides glxgears handy to benchmark with. Any thoughts on this? If people think it's a good idea, I'll do it for radeon as well. I like the approach. As there's nothing special about cmdbuf's - they're just regular memory, there's no reason not to be more dynamic about how we deal with them. 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM radeon i2c support and GPL
Jon Smirl wrote: I just checked a small change into DRM CVS that adds sysfs i2c support to the linux radeon driver. The patch includes some GPL licensed code extracted from the Linux kernel. The GPL files are only in the drm/linux directory. No GPL code was added to drm/shared or drm/bsd so the BSD build does not include the GPL code. The two GPL licensed files are clearly marked including warnings not to copy them into the BSD build. The issue with GPL and drm is as I have stated several times now that we've wanted XFree, and now Xorg, to be able to distribute this code as part of their tree. XFree86 had a strong policy against allowing GPL into their tree, I don't know what Xorg's stand is. Maybe someone can comment from there? 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. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
