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 current
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
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 h
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
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 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 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 li
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 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 hard
