Some questions regarding locks

2004-05-22 Thread Nicolai Haehnle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking whether the caller actually holds the global lock. There is no LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has no check in it either. Did I miss

Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM

2004-05-22 Thread Keith Whitwell
Michel Dnzer wrote: On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: There are two types of VTs - text and graphical. It is only practical to have a single graphical VT because of the complexity of state swapping a graphical VT at VT swap. Right now we can

Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM

2004-05-22 Thread Mike Mestnik
Can the GART apperture be moved physicaly? I don't think a logical move would be much help. --- Keith Whitwell [EMAIL PROTECTED] wrote: Michel Dänzer wrote: On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: There are two types of VTs - text and

Re: Some questions regarding locks

2004-05-22 Thread Keith Whitwell
Nicolai Haehnle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking whether the caller actually holds the global lock. There is no LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has no check in it

Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM

2004-05-22 Thread Mike Mestnik
Yes the GART swap, if it needs to be done with memcpys, should be posponed untill the user has SOME type of interface. Thats the important thing, allowing the user to interact is above hardware based rendering. I never liked the way GLapps froze when they where not on the current VT. I think the

Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM

2004-05-22 Thread Mike Mestnik
Yes the GART swap, if it needs to be done with memcpys, should be posponed untill the user has SOME type of interface. Thats the important thing, allowing the user to interact is above hardware based rendering. I never liked the way GLapps froze when they where not on the current VT. I think the

Re: Some questions regarding locks

2004-05-22 Thread Mike Mestnik
Lets just say that this is good fault tolorance. What ever can go wrong will, all drivers are faulty. This sounds like a good idea and should be implemented for ordinary use or something like it. Unless you thing we should KP on a lock being held for more then a given time(30 seconds)? ---

Re: Some questions regarding locks

2004-05-22 Thread Keith Whitwell
Mike Mestnik wrote: Lets just say that this is good fault tolorance. What ever can go wrong will, all drivers are faulty. This sounds like a good idea and should be implemented for ordinary use or something like it. Unless you thing we should KP on a lock being held for more then a given time(30

Re: Some questions regarding locks

2004-05-22 Thread Mike Mestnik
--- Keith Whitwell [EMAIL PROTECTED] wrote: Mike Mestnik wrote: Lets just say that this is good fault tolorance. What ever can go wrong will, all drivers are faulty. This sounds like a good idea and should be implemented for ordinary use or something like it. Unless you thing we

Re: texture units

2004-05-22 Thread Felix Kühling
On Fri, 21 May 2004 15:20:27 -0700 Mark Cass [EMAIL PROTECTED] wrote: guys, after reading documentation and looking in the code i noticed that the savage chip has two texture units. when does the second texture unit do its thing? i placed printfs in both sections of code (tex0 and tex1)

Re: Some questions regarding locks

2004-05-22 Thread Keith Whitwell
Also, when the VT is switched away from the X server, I believe that the hardware lock remains grabbed - for minutes or hours at a time. This is a multi-user OS bug. I'l not even pretend it's a feature that we should keep. Just making you aware of the issues. Keith

Re: drm 830 problem

2004-05-22 Thread Keith Whitwell
André Ventura Lemos wrote: Not at all... This only happens with 2.6 kernels. Prior do the lockup, everything works (I can see it through ssh), but the display gets blank, and never comes back. On Fri, 2004-05-21 at 18:07, Keith Whitwell wrote: Do you mind if I take this to dri-devel? What happens

Development setup

2004-05-22 Thread Maurice van der Pot
Hello, I have just started looking into DRI development and I have been experiencing some difficulties using gdb. For example, I cannot currently step into functions of libGL (it was compiled with debug info and LD_LIBRARY_PATH is set correctly). Another thing is that the symbols from

Re: Some questions regarding locks

2004-05-22 Thread Michel Dänzer
On Sat, 2004-05-22 at 14:04, Nicolai Haehnle wrote: It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking whether the caller actually holds the global lock. There is no LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has no check in it either. Did

MergedFrameBuffer: New meta-mode syntax needed.

2004-05-22 Thread Mike Mestnik
I'm currently unable to define a clone mode where one screen is smaller then the other. My thoughts are 1024x768_1024x768 == 1024x768 vs 1024x768-1024x768. The problem I have is that my settup is lopsided, one monitor has better modes than the other. The *larger* monitor is on the right, thus

Re: Some questions regarding locks

2004-05-22 Thread Ian Romanick
Nicolai Haehnle wrote: I think the simplest solution would look something like this: Whenever DRM(lock) is called by a privileged client (i.e. the X server), and it needs to sleep because the lock is held by an unprivileged client, a watchdog timer is started before we schedule. DRM(unlock)

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-22 Thread Alex Deucher
--- Mike Mestnik [EMAIL PROTECTED] wrote: I'm currently unable to define a clone mode where one screen is smaller then the other. My thoughts are 1024x768_1024x768 == 1024x768 vs 1024x768-1024x768. You can, but you can't mix and match multi-sized clone modes with multi-sized dualhead modes.

Slides from WinHEC on Microsoft Avalon

2004-05-22 Thread Jon Smirl
The slides contain some pretty detailed information on composition and text formatting. You probably need to boot windows to see these... http://www.eightypercent.net/Archive/2004/05/18.html#a185 Greg Schecter: Avalon Graphics Stack Overview [682 KB] Joe Beda (me): Avalon Graphics - 2D, 3D,