Philip Brown wrote:
I've been reading
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
and the code, obviously... so I've seen references to the "lightweight"
lock. ButI have yet to figure out why there is one.
The url document mentions that one supposedly exists, and that
"the lightweight lock will not be designed to be shared between GLXContexts"
and that
"The lightweight lock will be stored in a user-space shared memory segment
that is available to all locking entities."
But it doesnt seem to spell out exactly what the lightweight lock
should be used for, or what the kernel's role in it should be.
Can I basically just ignore the "lightweight lock" at kernel level, and
let the userspace code sort itself out?
I believe so, though in the linux drm, the kernel does make sure that when you
grab the heavyweight lock, the lightweight lock reflects this.
Also, as far as the heavyweight lock goes... It has been described as,
"The hardware lock is obtained whenever the hardware is touched, and
holding the lock implies that no other entity in the system will touch the
hardware. "
[http://dri.sourceforge.net/doc/drm_low_level.html]
That being the case, I'm thinking of just
having the heart of ioctl(DRM_IOCTL_LOCK) be a straight kernel mutex,
since solaris supposedly handles mutex queueing fairly well, rather
than implementating a whole separate queue mechanism.
Any comments on this?
I think that's reasonable.
Keith
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
