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
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 noticed these in dmesg after running glxgears:
[drm:via_cmdbuffer] *ERROR* via_cmdbuffer called without lock held
[drm:via_cmdbuffer] *ERROR* via_cmdbuffer called without lock held
[drm:via_cmdbuffer] *ERROR* via_cmdbuffer called without lock held
[drm:via_cmdbuffer] *ERROR* via_cmdbuffer
Hi
I noticed these in dmesg after running glxgears:
[drm:via_cmdbuffer] *ERROR* via_cmdbuffer called without lock held
[drm:via_cmdbuffer] *ERROR* via_cmdbuffer called without lock held
[drm:via_cmdbuffer] *ERROR* via_cmdbuffer called without lock held
[drm:via_cmdbuffer] *ERROR*
I made a fix to the locking code in main drm a couple of months ago.
The X server tries to get the DRM_QUIESCENT lock, but when the wait was
interrupted by a signal (like when you move a window around), the locking
function returned without error. This made the X server release other
On Thu, 2005-11-24 at 10:52 +0100, Thomas Hellström wrote:
I made a fix to the locking code in main drm a couple of months ago.
The X server tries to get the DRM_QUIESCENT lock, but when the wait
was interrupted by a signal (like when you move a window around), the
locking function returned
On Thu, 2005-11-24 at 10:52 +0100, Thomas Hellström wrote:
I made a fix to the locking code in main drm a couple of months ago.
The X server tries to get the DRM_QUIESCENT lock, but when the wait
was interrupted by a signal (like when you move a window around), the
locking function returned
On Thursday, November 24, 2005 4:50 am, Thomas Hellström wrote:
There is some info in the old precision insight documentation about
the DRI infrastructure, (can't seem to find a link right now) But
generally there is only one global lock and something called the
drawable spinlock that is
At one point I was about to implement a scheme for via with a number
of similar locks, one for each independent function on the video
chip, Like 2D, 3D, Mpeg decoder, Video scaler 1 and 2, so that they
didn't have to wait for eachother. The global lock would then only
be taken to make sure
13 matches
Mail list logo
