On Iau, 2005-11-24 at 05:49 -0500, Lee Revell wrote:
BTW can you point me to a good explanation of DRM locking? There's so
much indirection in the DRM code I can't even tell whether there's one
DRM lock or several, what kind of lock it is or what it's protecting
(beyond access to the
http://bugzilla.kernel.org/show_bug.cgi?id=5641
--- Additional Comments From [EMAIL PROTECTED] 2005-11-25 07:34 ---
Exactly the same problem in 2.6.14.3.
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
On Gwe, 2005-11-25 at 14:23 -0500, Lee Revell wrote:
On Fri, 2005-11-25 at 20:13 +0100, Arjan van de Ven wrote:
of course sometimes having less but more coarse locks is actually
faster. Taking/dropping a lock is not free. far from it.
True but couldn't it be a problem for devices like
On Thu, 2005-11-24 at 07:31 -0800, Jesse Barnes wrote:
Sounds interesting, but that would be card specific, right? I mean,
on some cards the 2d and 3d locks would have to be the same because of
shared state or whatever, for example.
Not especially, that's how most Linux drivers work. The
On Fri, 2005-11-25 at 14:05 -0500, Lee Revell wrote:
On Thu, 2005-11-24 at 07:31 -0800, Jesse Barnes wrote:
Sounds interesting, but that would be card specific, right? I mean,
on some cards the 2d and 3d locks would have to be the same because of
shared state or whatever, for example.
On Fri, 2005-11-25 at 16:24 +, Alan Cox wrote:
On Iau, 2005-11-24 at 05:49 -0500, Lee Revell wrote:
what kind of lock it is or what it's protecting
It co-ordinates access between the X server and various 3D clients so
that they don't step on each others drawing. A shared memory area is
On Fri, 2005-11-25 at 20:13 +0100, Arjan van de Ven wrote:
of course sometimes having less but more coarse locks is actually
faster. Taking/dropping a lock is not free. far from it.
True but couldn't it be a problem for devices like unichrome where you
have 3D and MPEG acceleration and they
I've been poking around in the DRM code a bit. One thing I've noticed
is that the xf86drm.h file in the DRI/drm tree is a bit out of sync
with the xf86drm.h file in the X.org tree. In particular, the use of
unsigned long vs. drm_handle_t. It looks like the later (drm_handle_t
in the X.org
I've been playing around with the EGL r200 driver. Digging through
the framebuffer allocation code I've found a few problems.
In order to support pbuffers and framebuffer objects we need to be
able to work with color/depth/stencil buffers are various locations in
video memory.
The
