Re: 2.4.8.1+P6: radeon, dri & xruns
On Fri, 2004-08-20 at 19:23, Fernando Pablo Lopez-Lezcano wrote: > Here's a new one, this is 2.6.8.1 (NOT 2.4.8.1!, sigh) + voluntary P6, > voluntary+kernel preemption enabled, threaded = 0 for the soundcard. > ALSA > /usr/src/redhat/BUILD/alsa-driver-1.0.6a/alsa-kernel/core/pcm_lib.c:139: > XRUN: pcmC0D0p > [] snd_pcm_period_elapsed+0x36f/0x560 [snd_pcm] > [] scheduler_tick+0x2b7/0x580 > [] ehci_irq+0xe4/0x300 [ehci_hcd] > [] snd_ice1712_interrupt+0x171/0x1e0 [snd_ice1712] > [] generic_handle_IRQ_event+0x30/0x60 > [] do_IRQ+0x146/0x3b0 > [] common_interrupt+0x18/0x20 > [] delay_pmtmr+0x18/0x20 > [] __delay+0x9/0x10 > [] radeon_do_wait_for_fifo+0x43/0x60 [radeon] > [] radeon_do_wait_for_idle+0x12/0x60 [radeon] > [] radeon_ioctl+0xbc/0x150 [radeon] > [] radeon_cp_idle+0x0/0xa0 [radeon] > [] sys_ioctl+0x21e/0x3d0 > [] sysenter_past_esp+0x52/0x71 > It looks like the timeout for many Radeon DRI operations is controlled by the dev_priv->usec_timeout value, which is copied from userspace via ioctl in radeon_cp_init. This value can be as large as 100 MSECS! radeon_drv.h:#define RADEON_MAX_USEC_TIMEOUT 10 /* 100 ms */ The driver does not seem to have a default for this, so you need to find the userspace code that is initializing the DRI and find the value it is being set to. Why is this allowed to be so large? Lee --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
The delay is very large because this routine is waiting for the
graphics coprocessor to finish an operation. Some of the operations can
take many ms to complete; for example telling the chip to copy 64MB of
memory somewhere. I would think the question should be, how do we wait
on the GPU without killing both audio and video latency.
The problem here is that most graphics commands are very short in
duration. Some of these commands can be issued a million of times per
second. A few commands are much longer running. I don't believe there
is an easy way to tell how long the commands will run.
A better solution might be to loop twenty times to pick up the very
short commands. After 20us switch to a loop that allows the kernel to
schedule. You don't want to immediately schedule since that will kill
graphics performance.
What's the right way to write a loop like this that meets the above
requirements and also satisfies the audio needs?
static int radeon_do_wait_for_idle( drm_radeon_private_t *dev_priv )
{
int i, ret;
dev_priv->stats.boxes |= RADEON_BOX_WAIT_IDLE;
ret = radeon_do_wait_for_fifo( dev_priv, 64 );
if ( ret ) return ret;
for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) {
if ( !(RADEON_READ( RADEON_RBBM_STATUS )
& RADEON_RBBM_ACTIVE) ) {
radeon_do_pixcache_flush( dev_priv );
return 0;
}
DRM_UDELAY( 1 );
}
#if RADEON_FIFO_DEBUG
DRM_ERROR( "failed!\n" );
radeon_status( dev_priv );
#endif
return DRM_ERR(EBUSY);
}
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
> > It looks like the timeout for many Radeon DRI operations is controlled > by the dev_priv->usec_timeout value, which is copied from userspace via > ioctl in radeon_cp_init. This value can be as large as 100 MSECS! > > radeon_drv.h:#define RADEON_MAX_USEC_TIMEOUT 10 /* 100 ms */ > > The driver does not seem to have a default for this, so you need to find > the userspace code that is initializing the DRI and find the value it is > being set to. > the current default is 1 usecs from radeon_dri.h in xc/programs/Xserver/hw/xfree86/drivers/ati (Xorg tree) you can use the option CPusecTimeout in your /etc/X11/xorg.conf file to tweak this value .. Previous investigations have found getting the 3D card and soundcard to balance latencies is difficult :-), I think the DRM could do with a bit of profiling on what the average times it takes for the GPU to become idle.. Dave. > Why is this allowed to be so large? > > Lee > > > > --- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
I don't believe the DRM drivers are holding any global kernel locks when they do wait_for_fifo. Any locks held would be internal to DRM and can be changed if needed. --- Lee Revell <[EMAIL PROTECTED]> wrote: > On Sat, 2004-08-21 at 01:29, Jon Smirl wrote: > > > What's the right way to write a loop like this that meets the above > > requirements and also satisfies the audio needs? > > > > I think it depends on which locks you are holding, and what kind of > locks they are. > > Lee > > = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
* Jon Smirl <[EMAIL PROTECTED]> wrote:
> A better solution might be to loop twenty times to pick up the very
> short commands. After 20us switch to a loop that allows the kernel to
> schedule. You don't want to immediately schedule since that will kill
> graphics performance.
You can busy-loop just fine as long as you stay preemptible. Also, if
need_resched() is true then you should get out of your locks ASAP.
the _ability_ to preempt quickly should not affect 3D performance in any
noticeable way: if the only app running is a 3D app, or it has a high
priority (because the user wants good 3D performance) then it will
perform just fine. Conversely, if an audio app has high priority then it
must see low latencies. So this is not an act of balancing, this is an
act of _enabling_ low latencies. Looping in the kernel for even 1 msec
while holding locks is very, very bad and should be avoided at every
cost. In fact you should shoot for as quick preemptability as possible
whenever you are looping for 3D completion, because your code is not
doing anything productive in fact. 'quick preemptability' != scheduling
away, it only means 'scheduling away if need_resched() is set'.
> What's the right way to write a loop like this that meets the above
> requirements and also satisfies the audio needs?
> for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) {
> if ( !(RADEON_READ( RADEON_RBBM_STATUS )
>& RADEON_RBBM_ACTIVE) ) {
> radeon_do_pixcache_flush( dev_priv );
> return 0;
> }
> DRM_UDELAY( 1 );
add:
if (need_resched()) {
break locks ...
cond_resched();
reacquire locks ...
}
and make sure the breaking of the locks is safe at that point (no other
3D application should be able to interfere with your polling, etc.).
this will solve all the audio complaints.
as a bonus, if you want to be 'nice' to lower prio processes as well,
you can also do:
if ((i & 127) == 127) {
drop locks ...
msleep(1);
reqacquire locks ...
}
this will busy-loop up to 127 usecs, and will sleep for 1 msec
afterwards.
the cleanest and highest performing solution would be to have an
interrupt source for 3D completion - do you have such an interrupt
handler handy? If yes then you can sleep precisely up to completion:
if ((i & 127) == 127) {
drop locks ...
wait_event(&driver->wait_queue,
RADEON_READ(RADEON_RBBM_STATUS));
reqacquire locks ...
break;
}
and in the IRQ handler, do a:
wake_up(&driver->wait_queue);
the wakeup doesnt even have to be precise - i.e. you can wake up early
or for all events - wait_event()'s second field, the 'is the wait done'
takes care of it and re-suspends the task if the 3D engine is still
busy.
(to implement a timeout and signal-awareness as well you can use
wait_event_interruptible_timeout().)
Ingo
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Sat, 2004-08-21 at 01:37, Dave Airlie wrote: > > > > It looks like the timeout for many Radeon DRI operations is controlled > > by the dev_priv->usec_timeout value, which is copied from userspace via > > ioctl in radeon_cp_init. This value can be as large as 100 MSECS! > > > > radeon_drv.h:#define RADEON_MAX_USEC_TIMEOUT 10 /* 100 ms */ > > > > The driver does not seem to have a default for this, so you need to find > > the userspace code that is initializing the DRI and find the value it is > > being set to. > > > the current default is 1 usecs from radeon_dri.h in > xc/programs/Xserver/hw/xfree86/drivers/ati (Xorg tree) you can use the > option CPusecTimeout in your /etc/X11/xorg.conf file to tweak this value > .. What happens if it times out? We drop a few frames? > > Previous investigations have found getting the 3D card and soundcard to > balance latencies is difficult :-) We are actually not interested in balancing latencies. What is needed is a way to tell the system that audio latency is important, 3D is not. > , I think the DRM could do with a bit of > profiling on what the average times it takes for the GPU to become idle.. > Indeed. For the radeon driver it looks like you could just measure the number of times you spin in those loops. Or, just keep setting it lower and see if it breaks. Lee --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Fri, 2004-08-20 at 22:59 -0700, Jon Smirl wrote: > I don't believe the DRM drivers are holding any global kernel locks > when they do wait_for_fifo. Any locks held would be internal to DRM and > can be changed if needed. Keep in mind that any ioctl function runs with the Big Kernel Lock held. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Sat, 2004-08-21 at 01:29, Jon Smirl wrote: > What's the right way to write a loop like this that meets the above > requirements and also satisfies the audio needs? > I think it depends on which locks you are holding, and what kind of locks they are. Lee --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
> > Keep in mind that any ioctl function runs with the Big Kernel Lock held. so were screwed? or should we just drop the BKL inside our ioctls? I think the DRM locking should be good enough and if it isn't it should be made good enough.. just in case anyone is wondering nearly all DRI stuff is done via ioctls.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
--- Ingo Molnar <[EMAIL PROTECTED]> wrote: > the cleanest and highest performing solution would be to have an > interrupt source for 3D completion - do you have such an interrupt > handler handy? If yes then you can sleep precisely up to completion: Interrupts are not a good solution. The hardware would generate millions of them per second. This is the same problem network cards have, you can interrupt the machine to death. I would expect the best solution is to make a few passes through the loop delaying a couple usec to catch the common case of quick completion. Then switch to doing need_resched(). I haven't tried tuning this code before, other people like Michel Dänzer may have more experience in this area and know the history of the previous attempts. Someone who knows the details of DRM locking needs to do the changes. BTW, loops like this are in most of the DRM drivers for other cards. They are probably in accelerated framebuffer drivers too. = Jon Smirl [EMAIL PROTECTED] ___ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
Michel pointed out that all IOCTL calls hold the big kernel lock. Releasing this lock is sure to case problems since the DRM code is not designed to be reentrant. I don't know what it will take to fix locking to allow this, maybe one of the original DRM authors will pop in here with the answer. Until locking is adjusted we can't add the schedule call. --- Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > On Fri, 2004-08-20 at 22:59, Jon Smirl wrote: > > I don't believe the DRM drivers are holding any global kernel locks > > when they do wait_for_fifo. Any locks held would be internal to DRM > and > > can be changed if needed. > > There must be a lock. I used to use a patch that I found somewhere > (that > does conditional reschedules), but it triggers the "scheduling while > lock held" kernel oops if you enable that option in the kernel > configuration. > > -- Fernando > > > --- Lee Revell <[EMAIL PROTECTED]> wrote: > > > > > On Sat, 2004-08-21 at 01:29, Jon Smirl wrote: > > > > > > > What's the right way to write a loop like this that meets the > above > > > > requirements and also satisfies the audio needs? > > > > > > > > > > I think it depends on which locks you are holding, and what kind > of > > > locks they are. > > > > > > Lee > > > > > > > > > > > > = > > Jon Smirl > > [EMAIL PROTECTED] > > > > > > > > __ > > Do you Yahoo!? > > Yahoo! Mail Address AutoComplete - You start. We finish. > > http://promotions.yahoo.com/new_mail > > = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Sad, 2004-08-21 at 16:00, Michel DÃnzer wrote: > On Fri, 2004-08-20 at 22:59 -0700, Jon Smirl wrote: > > I don't believe the DRM drivers are holding any global kernel locks > > when they do wait_for_fifo. Any locks held would be internal to DRM and > > can be changed if needed. > > Keep in mind that any ioctl function runs with the Big Kernel Lock held. The BKL is dropped whenever you sleep and retaken on resume anyway. That isn't a problem. Putting a need_resched() test in the loop will get you "fair" behaviour and in the single gaming app case won't generally trigger anyway. Alan --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Sul, 2004-08-22 at 02:51, Jon Smirl wrote: > Michel pointed out that all IOCTL calls hold the big kernel lock. > Releasing this lock is sure to case problems since the DRM code is not > designed to be reentrant. That lock is already released whenever the code sleeps (eg page faults) so if its broken then its already broken and it doesn't matter. If it isnt broken then its still not broken --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Sat, 2004-08-21 at 15:25, Fernando Pablo Lopez-Lezcano wrote: > On Fri, 2004-08-20 at 22:59, Jon Smirl wrote: > > I don't believe the DRM drivers are holding any global kernel locks > > when they do wait_for_fifo. Any locks held would be internal to DRM and > > can be changed if needed. > > There must be a lock. I used to use a patch that I found somewhere (that > does conditional reschedules), but it triggers the "scheduling while > lock held" kernel oops if you enable that option in the kernel > configuration. > There are several, and they undoubtedly interact in subtle ways. Grep for spin_lock in the drm directory and you will see what i mean. These locks are internal to the DRM and not global kernel locks, which makes it possible to fix them, but holding any spinlock will disable preemption. Based on the generalized solution Ingo proposed and the reaction of the DRI developers it seems like this will not be too hard to fix, but a thorough understanding of the locking code will be required. Lee --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Fri, 2004-08-20 at 22:29, Jon Smirl wrote: > The delay is very large because this routine is waiting for the > graphics coprocessor to finish an operation. Some of the operations can > take many ms to complete; for example telling the chip to copy 64MB of > memory somewhere. I would think the question should be, how do we wait > on the GPU without killing both audio and video latency. > > The problem here is that most graphics commands are very short in > duration. Some of these commands can be issued a million of times per > second. A few commands are much longer running. I don't believe there > is an easy way to tell how long the commands will run. > > A better solution might be to loop twenty times to pick up the very > short commands. After 20us switch to a loop that allows the kernel to > schedule. You don't want to immediately schedule since that will kill > graphics performance. As Ingo comments in another email I don't think that is necessarily the case [but then again I'm not an expert in the schedulling code]. You want to test whether a schedule is needed (a conditional reschedule, if I'm correct). If it is not then nothing happens and the code keeps feeding comands to the graphics processor. If one is needed then I don't see why the graphics code should keep holding the processor. Ok, if there is something else that needs the processor graphics performance could be affected, but that is because there is something else that needs the processor (and will suffer a performance problem if ignored). -- Fernando --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
[please cc me, I'm not on the dri list]
On Fri, 2004-08-20 at 22:29, Jon Smirl wrote:
> The delay is very large because this routine is waiting for the
> graphics coprocessor to finish an operation. Some of the operations can
> take many ms to complete; for example telling the chip to copy 64MB of
> memory somewhere.
That corresponds to my experience. I currently use glxgears while
running low latency audio stuff to test whether the problem is there or
not. For small window sizes (of glxgears) everything is fine. If I keep
making the window bigger there is a point where I start triggering xruns
like crazy (7 to 10 msecs or so).
> I would think the question should be, how do we wait
> on the GPU without killing both audio and video latency.
>
> The problem here is that most graphics commands are very short in
> duration. Some of these commands can be issued a million of times per
> second. A few commands are much longer running. I don't believe there
> is an easy way to tell how long the commands will run.
>
> A better solution might be to loop twenty times to pick up the very
> short commands. After 20us switch to a loop that allows the kernel to
> schedule. You don't want to immediately schedule since that will kill
> graphics performance.
What would be a good program that measures graphics performance that I
could run to test this? I could build a kernel with a patch I have that
has conditional reschedules in it (but it is illegal in the sense that
reschedules with a lock held) and see how that impacts performance, or
not. But I need something to test that will reflect some metric that
makes sense to the graphics crowd.
-- Fernando
> What's the right way to write a loop like this that meets the above
> requirements and also satisfies the audio needs?
>
>
> static int radeon_do_wait_for_idle( drm_radeon_private_t *dev_priv )
> {
> int i, ret;
>
>
> dev_priv->stats.boxes |= RADEON_BOX_WAIT_IDLE;
>
>
> ret = radeon_do_wait_for_fifo( dev_priv, 64 );
> if ( ret ) return ret;
>
>
> for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) {
> if ( !(RADEON_READ( RADEON_RBBM_STATUS )
>& RADEON_RBBM_ACTIVE) ) {
> radeon_do_pixcache_flush( dev_priv );
> return 0;
> }
> DRM_UDELAY( 1 );
> }
>
>
> #if RADEON_FIFO_DEBUG
> DRM_ERROR( "failed!\n" );
> radeon_status( dev_priv );
> #endif
> return DRM_ERR(EBUSY);
> }
>
> =
> Jon Smirl
> [EMAIL PROTECTED]
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Fri, 2004-08-20 at 22:59, Jon Smirl wrote: > I don't believe the DRM drivers are holding any global kernel locks > when they do wait_for_fifo. Any locks held would be internal to DRM and > can be changed if needed. There must be a lock. I used to use a patch that I found somewhere (that does conditional reschedules), but it triggers the "scheduling while lock held" kernel oops if you enable that option in the kernel configuration. -- Fernando > --- Lee Revell <[EMAIL PROTECTED]> wrote: > > > On Sat, 2004-08-21 at 01:29, Jon Smirl wrote: > > > > > What's the right way to write a loop like this that meets the above > > > requirements and also satisfies the audio needs? > > > > > > > I think it depends on which locks you are holding, and what kind of > > locks they are. > > > > Lee > > > > > > > = > Jon Smirl > [EMAIL PROTECTED] > > > > __ > Do you Yahoo!? > Yahoo! Mail Address AutoComplete - You start. We finish. > http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Sat, 2004-08-21 at 09:58, Jon Smirl wrote: > BTW, loops like this are in most of the DRM drivers for other cards. > They are probably in accelerated framebuffer drivers too. I know for a fact that the mga driver also has this problem, and I suspect that the r128 is also affected (but have not tested it). When I looked at them a while ago the code base seemed very similar so that most probably a fix for one of them would be usable for the others. -- Fernando --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
* Jon Smirl <[EMAIL PROTECTED]> wrote:
> --- Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > the cleanest and highest performing solution would be to have an
> > interrupt source for 3D completion - do you have such an interrupt
> > handler handy? If yes then you can sleep precisely up to completion:
>
> Interrupts are not a good solution. The hardware would generate
> millions of them per second. This is the same problem network cards
> have, you can interrupt the machine to death.
you'd only have to enable interrupt generation when you are not
busy-polling. In 99.9% of the cases (when !need_resched()) you could
busy poll as much as you want, and keep IRQ generation off. Very likely
IRQ generation can be turned on/off via a single PCI write on most 3D
hardware. Anyway, IRQ generation would just be a 'nice' thing. But the
following property is a must:
> I would expect the best solution is to make a few passes through the
> loop delaying a couple usec to catch the common case of quick
> completion. Then switch to doing need_resched().
no. If need_resched() is set then the code *must* try to schedule ASAP.
There is no excuse for not doing so - 'performance will suffer' is not a
correct argument becase _if_ need_resched() is true then the system (and
the user) doesnt want the 3D app to run right now. There will be no
performance difference to the 3D app, since by having high latencies the
DRI code does not give any extra performance to 3D apps, it only
increases the scheduling latency! The timeslices of the 3D app are used
up depending on how long the 3D app runs - so if it burns cycles
busy-polling it will in fact get less CPU time on average. (if the CPU
is contended.)
Anyway, need_resched() set is not a common condition, and if it happens
then kernel code _must_ react. (In fact most kernel code will be
preempted right away - but the DRI code runs under spinlocks.)
So the correct solution is to add something like this to _at least_ the
busy-polling code:
if (need_resched()) {
... drop locks ...
cond_resched();
... reacquire locks ...
}
or, if there's a single spinlock held (the BKL doesnt count) then:
cond_resched_lock(&driver->lock);
(but the locking obviously has to be correct and safe.)
ok?
Ingo
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
--- Jon Smirl <[EMAIL PROTECTED]> wrote: > Michel pointed out that all IOCTL calls hold the big kernel lock. > Releasing this lock is sure to case problems since the DRM code is not > designed to be reentrant. I don't know what it will take to fix locking > to allow this, maybe one of the original DRM authors will pop in here > with the answer. Until locking is adjusted we can't add the schedule > call. > >From what I'v read, http://lwn.net/Articles/86859/, it's not a global kernel lock (I.E. it dosen't stop non-locked kernel code from running). So the only reason it effects audio performace is that well, read the article :) Also DRI allready runes with it off in ioctls, every time there is a sleep. This is why DRI has spinlocks, right? Now if we turn BKL off for our ioctls we defeat the pupose it was turned on for, what is that? Would it be posible to use differed execution instead of blindly droping the BKL? As for the other DRI-spinlocks the code presented by Ingo Molnar lookes correct, no arguments here. I just don't see why DRI needs to drop the BKL any sooner then any other part of the kernel? After all DRI dosen't request it, it's just one of many victums of the ioctl BKL. So I think it would be best to let upstream fix the DRI BKL problem. > --- Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > > On Fri, 2004-08-20 at 22:59, Jon Smirl wrote: > > > I don't believe the DRM drivers are holding any global kernel locks > > > when they do wait_for_fifo. Any locks held would be internal to DRM > > and > > > can be changed if needed. > > > > There must be a lock. I used to use a patch that I found somewhere > > (that > > does conditional reschedules), but it triggers the "scheduling while > > lock held" kernel oops if you enable that option in the kernel > > configuration. > > > > -- Fernando > > > > > --- Lee Revell <[EMAIL PROTECTED]> wrote: > > > > > > > On Sat, 2004-08-21 at 01:29, Jon Smirl wrote: > > > > > > > > > What's the right way to write a loop like this that meets the > > above > > > > > requirements and also satisfies the audio needs? > > > > > > > > > > > > > I think it depends on which locks you are holding, and what kind > > of > > > > locks they are. > > > > > > > > Lee > > > > > > > > > > > > > > > > > = > > > Jon Smirl > > > [EMAIL PROTECTED] > > > > > > > > > > > > __ > > > Do you Yahoo!? > > > Yahoo! Mail Address AutoComplete - You start. We finish. > > > http://promotions.yahoo.com/new_mail > > > > > > > = > Jon Smirl > [EMAIL PROTECTED] > > > > __ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail > > > --- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
--- Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> > --- Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > > the cleanest and highest performing solution would be to have an
> > > interrupt source for 3D completion - do you have such an interrupt
> > > handler handy? If yes then you can sleep precisely up to completion:
> >
> > Interrupts are not a good solution. The hardware would generate
> > millions of them per second. This is the same problem network cards
> > have, you can interrupt the machine to death.
>
> you'd only have to enable interrupt generation when you are not
> busy-polling. In 99.9% of the cases (when !need_resched()) you could
> busy poll as much as you want, and keep IRQ generation off. Very likely
> IRQ generation can be turned on/off via a single PCI write on most 3D
> hardware. Anyway, IRQ generation would just be a 'nice' thing. But the
> following property is a must:
>
This lookes like a great idea. We turn on interrupt generation just after
we drop our spinlock(in the if need_resched() block). This would greatly
improve system proformance as IRQs would only be used when we wait for
long periods.
> > I would expect the best solution is to make a few passes through the
> > loop delaying a couple usec to catch the common case of quick
> > completion. Then switch to doing need_resched().
>
> no. If need_resched() is set then the code *must* try to schedule ASAP.
> There is no excuse for not doing so - 'performance will suffer' is not a
> correct argument becase _if_ need_resched() is true then the system (and
> the user) doesnt want the 3D app to run right now. There will be no
> performance difference to the 3D app, since by having high latencies the
> DRI code does not give any extra performance to 3D apps, it only
> increases the scheduling latency! The timeslices of the 3D app are used
> up depending on how long the 3D app runs - so if it burns cycles
> busy-polling it will in fact get less CPU time on average. (if the CPU
> is contended.)
>
I see jerky ness alot with Q3, where frame rate spikes for one frame.
This lookes like a good explination, as the frame b4 and after would have
many of the same GL calls.
End Of Line.
> Anyway, need_resched() set is not a common condition, and if it happens
> then kernel code _must_ react. (In fact most kernel code will be
> preempted right away - but the DRI code runs under spinlocks.)
>
> So the correct solution is to add something like this to _at least_ the
> busy-polling code:
>
> if (need_resched()) {
> ... drop locks ...
> cond_resched();
> ... reacquire locks ...
> }
>
> or, if there's a single spinlock held (the BKL doesnt count) then:
>
> cond_resched_lock(&driver->lock);
>
> (but the locking obviously has to be correct and safe.)
>
> ok?
>
> Ingo
>
>
> ---
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> --
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
> > There must be a lock. I used to use a patch that I found somewhere (that > does conditional reschedules), but it triggers the "scheduling while > lock held" kernel oops if you enable that option in the kernel > configuration. I can't find the lock from a quick code inspection.. I'll add the reschedule to a test drm and I'll build my kernel with all the debugging on... Dave. > > > --- Lee Revell <[EMAIL PROTECTED]> wrote: > > > > > On Sat, 2004-08-21 at 01:29, Jon Smirl wrote: > > > > > > > What's the right way to write a loop like this that meets the above > > > > requirements and also satisfies the audio needs? > > > > > > > > > > I think it depends on which locks you are holding, and what kind of > > > locks they are. > > > > > > Lee > > > > > > > > > > > > = > > Jon Smirl > > [EMAIL PROTECTED] > > > > > > > > __ > > Do you Yahoo!? > > Yahoo! Mail Address AutoComplete - You start. We finish. > > http://promotions.yahoo.com/new_mail > > > > --- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
>
> I can't find the lock from a quick code inspection.. I'll add the
> reschedule to a test drm and I'll build my kernel with all the debugging
> on...
>
I'm running the attached patch to the DRM in CVS on 2.6.8.1 and I'm not
seeing any drm related xruns.. there are other places that can do with
fixing up (and of coures the other drivers..)
I'm also not seeing any sleep inside locks.. (I'm just playing neverwinter
nights with lots of graphics on ..)
Dave.
Index: radeon_cp.c
===
RCS file: /cvs/dri/drm/shared/radeon_cp.c,v
retrieving revision 1.37
diff -u -r1.37 radeon_cp.c
--- radeon_cp.c 23 Aug 2004 10:05:01 - 1.37
+++ radeon_cp.c 23 Aug 2004 11:09:08 -
@@ -631,7 +631,15 @@
int slots = ( RADEON_READ( RADEON_RBBM_STATUS )
& RADEON_RBBM_FIFOCNT_MASK );
if ( slots >= entries ) return 0;
- DRM_UDELAY( 1 );
+
+ if (need_resched()) {
+ cond_resched();
+ }
+
+ if (( i & 127 ) == 127 ) {
+ msleep(1);
+ }
+ // DRM_UDELAY( 1 );
}
#if RADEON_FIFO_DEBUG
@@ -656,7 +664,14 @@
radeon_do_pixcache_flush( dev_priv );
return 0;
}
- DRM_UDELAY( 1 );
+
+ if (need_resched()) {
+ cond_resched();
+ }
+
+ if (( i & 127 ) == 127 ) {
+ msleep(1);
+ }
}
#if RADEON_FIFO_DEBUG
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Mon, Aug 23, 2004 at 12:15:34PM +0100, Dave Airlie wrote:
> @@ -631,7 +631,15 @@
> int slots = ( RADEON_READ( RADEON_RBBM_STATUS )
>& RADEON_RBBM_FIFOCNT_MASK );
> if ( slots >= entries ) return 0;
> -DRM_UDELAY( 1 );
> +
> +if (need_resched()) {
> +cond_resched();
> +}
> +
> +if (( i & 127 ) == 127 ) {
> +msleep(1);
> +}
> +// DRM_UDELAY( 1 );
> }
>
> #if RADEON_FIFO_DEBUG
> @@ -656,7 +664,14 @@
> radeon_do_pixcache_flush( dev_priv );
> return 0;
> }
> -DRM_UDELAY( 1 );
> +
> +if (need_resched()) {
> +cond_resched();
> +}
> +
> +if (( i & 127 ) == 127 ) {
> +msleep(1);
> +}
> }
The cond_resched() already does a need_resched() check for you, so you could
do away with the conditionals here.
Dave
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
* Dave Airlie <[EMAIL PROTECTED]> wrote:
> int slots = ( RADEON_READ( RADEON_RBBM_STATUS )
> & RADEON_RBBM_FIFOCNT_MASK );
> if ( slots >= entries ) return 0;
> - DRM_UDELAY( 1 );
> +
> + if (need_resched()) {
> + cond_resched();
> + }
> +
> + if (( i & 127 ) == 127 ) {
> + msleep(1);
> + }
> + // DRM_UDELAY( 1 );
do you have CONFIG_PREEMPT or CONFIG_SMP & CONFIG_DEBUG_SPINLOCK_SLEEP
turned on? You will get the atomicity asserts from schedule() only in a
preempt (or smp+debug) kernel, not in a normal UP kernel.
if it's indeed safe to reschedule then i'd suggest to do it like this:
cond_resched()
if (i > 100)
msleep(1);
else
DRM_UDELAY(1);
this way the polling limit is ~100 usecs, and reschedules are done
immediately. I dont think there's any point in continuing to poll for
127 iterations after the first 1 msec sleep.
btw., do you see any performance impact from the msleep(1)? Also, can
you see any CPU overhead reduction in games?
To test this easier you can do the following hack:
extern int panic_timeout;
if (!panic_timeout) {
cond_resched()
if (i > 100)
msleep(1);
else
DRM_UDELAY(1);
} else
DRM_UDELAY(1);
and you can trigger the original polling code via:
echo 1 > /proc/sys/kernel/panic
and trigger your new code via:
echo 0 > /proc/sys/kernel/panic
and watch how FPS and CPU utilization changes. It is easier to test the
change this way than to recompile & reboot the kernel. (it also makes
testing more reliable.)
Ingo
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
* Dave Airlie <[EMAIL PROTECTED]> wrote: > I can't find the lock from a quick code inspection.. I'll add the > reschedule to a test drm and I'll build my kernel with all the > debugging on... there doesnt seem to be any further lock other than the BKL: 0001 0.558ms (+0.000ms): delay_tsc (__delay) 0001 0.560ms (+0.001ms): __const_udelay (radeon_do_wait_for_fifo) 0001 0.560ms (+0.000ms): __delay (radeon_do_wait_for_fifo) 0001 0.560ms (+0.000ms): delay_tsc (__delay) 0001 0.561ms (+0.001ms): __const_udelay (radeon_do_wait_for_fifo) 0001 0.561ms (+0.000ms): __delay (radeon_do_wait_for_fifo) 0001 0.561ms (+0.000ms): delay_tsc (__delay) so unless the BKL is being relied on, it's safe to add the conditional reschedule. Ingo --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
--- Lee Revell <[EMAIL PROTECTED]> wrote: > On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote: > > --- Jon Smirl <[EMAIL PROTECTED]> wrote: > > > > > Michel pointed out that all IOCTL calls hold the big kernel lock. > > > Releasing this lock is sure to case problems since the DRM code is > not > > > designed to be reentrant. I don't know what it will take to fix > locking > > > to allow this, maybe one of the original DRM authors will pop in > here > > > with the answer. Until locking is adjusted we can't add the schedule > > > call. > > > > > >From what I'v read, http://lwn.net/Articles/86859/, it's not a global > > kernel lock (I.E. it dosen't stop non-locked kernel code from > running). > > So the only reason it effects audio performace is that well, read the > > article :) > > > > The reason the BKL affects audio performance is that taking the BKL > disables preemption. > But ONLY while your not sleeping. > Lee > > __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
i'll put the patch below into the -P8 patch. (change voluntary_resched()
to cond_resched() if you apply this to a vanilla kernel.)
Ingo
--- linux/drivers/char/drm/drm_os_linux.h.orig
+++ linux/drivers/char/drm/drm_os_linux.h
@@ -14,7 +14,7 @@
#define DRM_ERR(d) -(d)
/** Current process ID */
#define DRM_CURRENTPID current->pid
-#define DRM_UDELAY(d) udelay(d)
+#define DRM_UDELAY(d) do { voluntary_resched(); udelay(d); } while
(0)
/** Read a byte from a MMIO region */
#define DRM_READ8(map, offset) readb(((unsigned long)(map)->handle) +
(offset))
/** Read a dword from a MMIO region */
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
Previously all of the IOCTL calls were protected by the Big Kernel
Lock. If we break that aren't we allowing multiple callers into the
IOCTL code on SMP machines that weren't allowed in before? Doesn't that
mean that we have to check everything to make sure it is SMP safe?
--- Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> i'll put the patch below into the -P8 patch. (change
> voluntary_resched()
> to cond_resched() if you apply this to a vanilla kernel.)
>
> Ingo
>
> --- linux/drivers/char/drm/drm_os_linux.h.orig
> +++ linux/drivers/char/drm/drm_os_linux.h
> @@ -14,7 +14,7 @@
> #define DRM_ERR(d) -(d)
> /** Current process ID */
> #define DRM_CURRENTPID current->pid
> -#define DRM_UDELAY(d)udelay(d)
> +#define DRM_UDELAY(d)do { voluntary_resched(); udelay(d); }
> while
> (0)
> /** Read a byte from a MMIO region */
> #define DRM_READ8(map, offset) readb(((unsigned long)(map)->handle)
> + (offset))
> /** Read a dword from a MMIO region */
>
>
> ---
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank
> Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> --
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
* Jon Smirl <[EMAIL PROTECTED]> wrote: > Previously all of the IOCTL calls were protected by the Big Kernel > Lock. If we break that aren't we allowing multiple callers into the > IOCTL code on SMP machines that weren't allowed in before? Doesn't > that mean that we have to check everything to make sure it is SMP > safe? as Alan mentioned it before, the BKL did not protect much, since the DRM code was freely doing copying from and to userspace, and hence dropping the BKL at those places. but yes, best would be to drop the BKL as soon as possible and check everything. Ingo --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
--- Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Jon Smirl <[EMAIL PROTECTED]> wrote: > > > Previously all of the IOCTL calls were protected by the Big Kernel > > Lock. If we break that aren't we allowing multiple callers into the > > IOCTL code on SMP machines that weren't allowed in before? Doesn't > > that mean that we have to check everything to make sure it is SMP > > safe? > > as Alan mentioned it before, the BKL did not protect much, since the DRM > code was freely doing copying from and to userspace, and hence dropping > the BKL at those places. > Add sleeping(usleep) to this list, no? The big Q I have is why are IOCTL's protected by the BKL if it gets droped so easily? > but yes, best would be to drop the BKL as soon as possible and check > everything. > By check everything, you mean make sure shared resources(memory) are used safely? > Ingo > > > --- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
* Mike Mestnik <[EMAIL PROTECTED]> wrote: > > as Alan mentioned it before, the BKL did not protect much, since the DRM > > code was freely doing copying from and to userspace, and hence dropping > > the BKL at those places. > > > Add sleeping(usleep) to this list, no? The big Q I have is why are > IOCTL's protected by the BKL if it gets droped so easily? usleep is for short delays, it uses busy-looping. msleep is the one that schedules away. > > but yes, best would be to drop the BKL as soon as possible and check > > everything. > > > By check everything, you mean make sure shared resources(memory) are used > safely? yes. This means some sort of locking has to be added (if it's not present already). The easiest solution would be to add a semaphore (mutex) to each device and use that to serialize multiple users and API calls. A mutex doesnt get dropped when you schedule away. Ingo --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
> > > Previously all of the IOCTL calls were protected by the Big Kernel > > Lock. If we break that aren't we allowing multiple callers into the > > IOCTL code on SMP machines that weren't allowed in before? Doesn't > > that mean that we have to check everything to make sure it is SMP > > safe? > > as Alan mentioned it before, the BKL did not protect much, since the DRM > code was freely doing copying from and to userspace, and hence dropping > the BKL at those places. > I'm not sure that the main DRM heavyweight lock doesn't stop all this from happening.. a process has to take the lock before doing anything else... it also not as if you can have two threads using the same context (correct me if I'm wrong)... granted it uses the ioctl to take the lock, but I don't think we should ever get two processes down in the driver core at the same time .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
Dave Airlie wrote: Previously all of the IOCTL calls were protected by the Big Kernel Lock. If we break that aren't we allowing multiple callers into the IOCTL code on SMP machines that weren't allowed in before? Doesn't that mean that we have to check everything to make sure it is SMP safe? as Alan mentioned it before, the BKL did not protect much, since the DRM code was freely doing copying from and to userspace, and hence dropping the BKL at those places. I'm not sure that the main DRM heavyweight lock doesn't stop all this from happening.. a process has to take the lock before doing anything else... The lock doesn't quite do this - it is intended to serialize access to hardware, so ioctls which don't touch hardware are historically not required to be called with the lock held. That distinction has been lost somewhat over time, and nowadays most drivers ensure they hold the lock before calling any DRM ioctl, and most DRM ioctls check that the lock is held early in their execution. This could use an audit, though. Keith --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote: > --- Jon Smirl <[EMAIL PROTECTED]> wrote: > > > Michel pointed out that all IOCTL calls hold the big kernel lock. > > Releasing this lock is sure to case problems since the DRM code is not > > designed to be reentrant. I don't know what it will take to fix locking > > to allow this, maybe one of the original DRM authors will pop in here > > with the answer. Until locking is adjusted we can't add the schedule > > call. > > > >From what I'v read, http://lwn.net/Articles/86859/, it's not a global > kernel lock (I.E. it dosen't stop non-locked kernel code from running). > So the only reason it effects audio performace is that well, read the > article :) > The reason the BKL affects audio performance is that taking the BKL disables preemption. Lee --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Mon, 2004-08-23 at 11:43, Fernando Pablo Lopez-Lezcano wrote:
> On Mon, 2004-08-23 at 11:30, Ingo Molnar wrote:
> > i'll put the patch below into the -P8 patch. (change voluntary_resched()
> > to cond_resched() if you apply this to a vanilla kernel.)
>
> I'll start a kernel build to test this on top of P7...
A quick test confirms that no video related xruns happen with this patch
in place (Radeon Mobidity, running jack with 128x2 buffers and glxgears
to blast stuff to the screen). No ill effects so far either. Any more
comprehensive test I could run?
-- Fernando
> > --- linux/drivers/char/drm/drm_os_linux.h.orig
> > +++ linux/drivers/char/drm/drm_os_linux.h
> > @@ -14,7 +14,7 @@
> > #define DRM_ERR(d) -(d)
> > /** Current process ID */
> > #define DRM_CURRENTPID current->pid
> > -#define DRM_UDELAY(d) udelay(d)
> > +#define DRM_UDELAY(d) do { voluntary_resched(); udelay(d); }
> > while (0)
> > /** Read a byte from a MMIO region */
> > #define DRM_READ8(map, offset) readb(((unsigned long)(map)->handle) +
> > (offset))
> > /** Read a dword from a MMIO region */
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Mon, 2004-08-23 at 11:30, Ingo Molnar wrote:
> i'll put the patch below into the -P8 patch. (change voluntary_resched()
> to cond_resched() if you apply this to a vanilla kernel.)
I'll start a kernel build to test this on top of P7... (I was about to
ask "what about the other places in radeon_cp.c that can spin for up to
the full timeout"? :-) This should fix r128 and mga as well...
beautiful.
-- Fernando
> Ingo
>
> --- linux/drivers/char/drm/drm_os_linux.h.orig
> +++ linux/drivers/char/drm/drm_os_linux.h
> @@ -14,7 +14,7 @@
> #define DRM_ERR(d) -(d)
> /** Current process ID */
> #define DRM_CURRENTPID current->pid
> -#define DRM_UDELAY(d)udelay(d)
> +#define DRM_UDELAY(d)do { voluntary_resched(); udelay(d); }
> while (0)
> /** Read a byte from a MMIO region */
> #define DRM_READ8(map, offset) readb(((unsigned long)(map)->handle) +
> (offset))
> /** Read a dword from a MMIO region */
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
--- Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > On Mon, 2004-08-23 at 11:43, Fernando Pablo Lopez-Lezcano wrote: > > On Mon, 2004-08-23 at 11:30, Ingo Molnar wrote: > > > i'll put the patch below into the -P8 patch. (change > voluntary_resched() > > > to cond_resched() if you apply this to a vanilla kernel.) > > > > I'll start a kernel build to test this on top of P7... > > A quick test confirms that no video related xruns happen with this > patch > in place (Radeon Mobidity, running jack with 128x2 buffers and > glxgears > to blast stuff to the screen). No ill effects so far either. Any more > comprehensive test I could run? Can you run everything on an SMP machine? Dual processor would be better than HT. The exposure is on SMP here, the patch should not effect a single CPU. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Tue, 2004-08-24 at 22:51, Jon Smirl wrote: > --- Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > On Mon, 2004-08-23 at 11:43, Fernando Pablo Lopez-Lezcano wrote: > > > On Mon, 2004-08-23 at 11:30, Ingo Molnar wrote: > > > > i'll put the patch below into the -P8 patch. (change voluntary_resched() > > > > to cond_resched() if you apply this to a vanilla kernel.) > > > > > > I'll start a kernel build to test this on top of P7... > > > > A quick test confirms that no video related xruns happen with this patch > > in place (Radeon Mobidity, running jack with 128x2 buffers and glxgears > > to blast stuff to the screen). No ill effects so far either. Any more > > comprehensive test I could run? > > Can you run everything on an SMP machine? Dual processor would be > better than HT. The exposure is on SMP here, the patch should not > effect a single CPU. I will (hopefully) tomorrow, I was having trouble today booting an SMP kernel on a UP machine. I don't run 2.6.x capable machines in production (yet :-), so I have to grab one, replace the hard disk and install FC2 so I can test. I'll test on a dual athlon MP and report back. -- Fernando --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
I guess I don't understand, the article said the sound(OSS) took the BKL? It didn't say that ALSA's OSS is effected, I'm assuming that it is not. In any case ALSA still uses ioctls. So no mater what sound takes the BKL and disables preemption? I don't think that preemption could work at all, unless when the BKL is [1]droped you preemptate. I think you have something wrong, as DRI dose these things alot so it might not block preemption. 1. msleep, usercpy, ect. --- Lee Revell <[EMAIL PROTECTED]> wrote: > On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote: > > --- Jon Smirl <[EMAIL PROTECTED]> wrote: > > > > > Michel pointed out that all IOCTL calls hold the big kernel lock. > > > Releasing this lock is sure to case problems since the DRM code is > not > > > designed to be reentrant. I don't know what it will take to fix > locking > > > to allow this, maybe one of the original DRM authors will pop in > here > > > with the answer. Until locking is adjusted we can't add the schedule > > > call. > > > > > >From what I'v read, http://lwn.net/Articles/86859/, it's not a global > > kernel lock (I.E. it dosen't stop non-locked kernel code from > running). > > So the only reason it effects audio performace is that well, read the > > article :) > > > > The reason the BKL affects audio performance is that taking the BKL > disables preemption. > > Lee > > > > --- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
On Fri, 2004-08-27 at 13:23, Mike Mestnik wrote: > I guess I don't understand, the article said the sound(OSS) took the BKL? > It didn't say that ALSA's OSS is effected, I'm assuming that it is not. > In any case ALSA still uses ioctls. So no mater what sound takes the BKL > and disables preemption? > > I don't think that preemption could work at all, unless when the BKL is > [1]droped you preemptate. I think you have something wrong, as DRI dose > these things alot so it might not block preemption. > > 1. msleep, usercpy, ect. > The article actually didn't say much about why the BKL affects audio performance. Sound (meaning ALSA) does not take the BKL. When another process takes the BKL, however, preemption is disabled until that process either drops the BKL or goes to sleep. So to minimize audio latency (which is just the amount of time between when a SCHED_FIFO process is made runnable and when it gets the processor), other parts of the kernel need to minimize the amount of time they spend non-preemptible (holding the BKL or a spinlock, or having explicityly disabled preemption). Therefore ioctl is bad and should be avoided wherever possible. It's not a big deal for ALSA, because the ioctls complete very quickly, and they only happen when starting or stopping the audio device anyway. But if we are recording audio and the DRI comes along and spends more than a few hundred usecs in an ioctl(), we are screwed. Like Ingo said, the real fix is to replace the DRM's use of the BKL with fine grained locking. Also please don't top post! Lee --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri & xruns
* Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > Once I boot I can get, for example, two instances of glxgears happily > going on at once. But if I start jack with realtime priority from > within qjackctl I get a hard lock very soon, the machine does not even > react to the sysrq magic key. _But_, you can see the two glxgears > instances still drawing to the screen... but they seem to take turns, > first one, then the other and so on and so forth (frequency of switch > not perfectly regular, between 0.5 and 1 second, I'd say). Sorry the > description is not very precise. if you want them to timeslice more finegrained, try to run them with nice +19 - does that make them smoother? Ingo --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
