> --- Thomas Hellström <[EMAIL PROTECTED]> wrote:
>
>>
>> You are probably right, and it would be quite easy to implement such
>> checks in the via command verifier as long as each lock is associated
>> with
>> a certain hardware address range.
>>
>> However, I don't quite see the point in plugging
Michel DÃnzer wrote:
On Mon, 2004-11-01 at 14:21 +0100, Thomas HellstrÃm wrote:
Hmm, correct me If I'm wrong, but after a brief check in the code, it
seems like the current _DRM_LOCK_IS_HELD() used in dma buffer
submission IOCTLS just checks that the lock is indeed held, but not i
On Mon, 2004-11-01 at 14:21 +0100, Thomas HellstrÃm wrote:
>
> Hmm, correct me If I'm wrong, but after a brief check in the code, it
> seems like the current _DRM_LOCK_IS_HELD() used in dma buffer
> submission IOCTLS just checks that the lock is indeed held, but not if
> it is held by the current
--- Nicolai Haehnle <[EMAIL PROTECTED]> wrote:
> On Monday 01 November 2004 07:01, Thomas Hellström wrote:
> > You are probably right, and it would be quite easy to implement such
> > checks in the via command verifier as long as each lock is associated
> with
> > a certain hardware address range
--- Thomas Hellström <[EMAIL PROTECTED]> wrote:
>
> You are probably right, and it would be quite easy to implement such
> checks in the via command verifier as long as each lock is associated
> with
> a certain hardware address range.
>
> However, I don't quite see the point in plugging such a
Thomas Hellström wrote:
I want a DRI client to flip a video frame to screen, using a hardware
entity called the HQV. This is a rather time critical operation. To do
this I have to take the hardware lock.
While this is happening, another thread is waiting for the mpeg decoder
to complete a frame
Nicolai Haehnle wrote:
On Monday 01 November 2004 07:01, Thomas Hellström wrote:
You are probably right, and it would be quite easy to implement such
checks in the via command verifier as long as each lock is associated with
a certain hardware address range.
However, I don't quite
On Monday 01 November 2004 07:01, Thomas Hellström wrote:
> You are probably right, and it would be quite easy to implement such
> checks in the via command verifier as long as each lock is associated with
> a certain hardware address range.
>
> However, I don't quite see the point in plugging suc
Thomas Hellström wrote:
On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote:
Keith Whitwell wrote:
Thomas Hellström wrote:
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engi
> On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote:
>> Keith Whitwell wrote:
>>
>> > Thomas Hellström wrote:
>> >
>> >> Hi, list!
>> >>
>> >> With display cards that have more and more hardware on them,
>> >> (TV-capture, mpeg decoders) etc. that can work independently of
>> >> oneanother, but s
> --- Thomas Hellström <[EMAIL PROTECTED]> wrote:
>
>> Keith Whitwell wrote:
>>
>> The typical case here:
>>
>> I want a DRI client to flip a video frame to screen, using a hardware
>> entity called the HQV. This is a rather time critical operation. To do
>> this I have to take the hardware lock.
>
--- Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Keith Whitwell wrote:
>
> The typical case here:
>
> I want a DRI client to flip a video frame to screen, using a hardware
> entity called the HQV. This is a rather time critical operation. To do
> this I have to take the hardware lock.
>
> W
On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote:
> Keith Whitwell wrote:
>
> > Thomas Hellström wrote:
> >
> >> Hi, list!
> >>
> >> With display cards that have more and more hardware on them,
> >> (TV-capture, mpeg decoders) etc. that can work independently of
> >> oneanother, but share the
Jon Smirl wrote:
On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
Wouldn't this severely break backwards binary compatibility with dri clients
compiled with the old size of drm_sarea_t?
You can't put them in drm_sarea_t. There is definitel
On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> Wouldn't this severely break backwards binary compatibility with dri clients
> compiled with the old size of drm_sarea_t?
You can't put them in drm_sarea_t. There is definitely code that will
break if you do. I don'
Jon Smirl wrote:
On Sun, 31 Oct 2004 19:41:03 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
/* For now the mapping works by using a fixed size defined
* in the SAREA header
*/
if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) > SAREA_MAX) {
xf86DrvMsg
--- Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Such a case would be a client submitting 2D engine commands while the X
> server waits for 2D engine idle. Either this has to be implemented in
> the command verifier or considered acceptable behaviour. Today any dri
> client can continously cl
Mike Mestnik wrote:
--- Thomas Hellström <[EMAIL PROTECTED]> wrote:
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than
Keith Whitwell wrote:
Thomas Hellström wrote:
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than one hardware lock.
The first question
--- Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Hi, list!
>
> With display cards that have more and more hardware on them,
> (TV-capture, mpeg decoders) etc. that can work independently of
> oneanother, but share the same DMA engine I've find the need for more
> than one hardware lock. I've
Thomas Hellström wrote:
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than one hardware lock.
The first question is - have you found tha
On Sun, 31 Oct 2004 19:41:03 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
>
> /* For now the mapping works by using a fixed size defined
> * in the SAREA header
> */
> if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) > SAREA_MAX) {
> xf86DrvMsg(pScrn->scrnIndex, X_E
Jon Smirl wrote:
On Sun, 31 Oct 2004 18:41:42 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
The idea of using a separate sarea is that it would be easy to extend the
number of locks and more suitable for more drivers than via. Otherwise one
idea would be to
fill the private
On Sun, 31 Oct 2004 18:41:42 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> The idea of using a separate sarea is that it would be easy to extend the
> number of locks and more suitable for more drivers than via. Otherwise one
> idea would be to
> fill the private sarea from the back, but
Jon Smirl wrote:
On Sun, 31 Oct 2004 16:52:35 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
1. A separate sarea to contain these locks, to avoid messing up the
current sarea with binary incompatibilities as a consequence.
It would probably be better to extend the cu
On Sun, 31 Oct 2004 16:52:35 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
> 1. A separate sarea to contain these locks, to avoid messing up the
> current sarea with binary incompatibilities as a consequence.
It would probably be better to extend the current driver specific
sarea. You can neg
Hi, list!
With display cards that have more and more hardware on them,
(TV-capture, mpeg decoders) etc. that can work independently of
oneanother, but share the same DMA engine I've find the need for more
than one hardware lock. I've done a simple implementation for the mpeg
decoder of the via
27 matches
Mail list logo
