Re: [Unichrome-devel] Dragging window in X causes soundcard interrupts to be lost

Re: [Unichrome-devel] Dragging window in X causes soundcard interrupts to be lost

[Alan Cox]

On Sul, 2004-08-01 at 01:25, Lee Revell wrote:
> Do you have the original driver source from VIA handy?  This is looking
> more and more like a hardware bug - 2D acceleration engine activity
> causes interrupts from the PCI slot to be disabled for long periods. 

I do. There is no code in the 2D engine that touches interrupt control
at all. 

> Maybe it disables interrupts to prevent other processes writing to the
> shared video/system RAM as it DMAs.  I would like to verify that the
> problem still occurs with their driver, before I try to convince them
> there's a hardware issue with the EPIA boards.

A similar problem occurs with some other chips when you write enough
data to the chip that the FIFO fills and the PCI bus locks until the
write can complete. Various vendors implemented this at one point for
benchmarketing reasons and that would have a similar effect if so.

The 2D driver source is essentially the same as the source in Xorg CVS
barring cleanups and the accelerator code has not changed at all. You
might want to take a look at the fifo management side of things in that
code.

> On that note, assuming I verify the bug, does anyone have any
> recommendations for getting VIA to take me seriously?  The problem is
> very easy to reproduce.

I have some contact with VIA however you need to understand that the
graphics world moves rapidly. I would be suprised if the CLE266 saw any
more development given the CN400 has been demoed, although I certainly
can't speak for VIA on this matter.

Alan

Re: [Unichrome-devel] Dragging window in X causes soundcard interrupts to be lost

[Lee Revell]

On Sun, 2004-07-18 at 18:58, Thomas Hellstrom wrote:
> Hi, Lee. 
> 
> Most of the code is inherited from VIA, but as far as I know, there
> are no locks held except the DRM lock when DRI is used, which it isn't
> in your case. 
> 

Thomas,

Do you have the original driver source from VIA handy?  This is looking
more and more like a hardware bug - 2D acceleration engine activity
causes interrupts from the PCI slot to be disabled for long periods. 
Maybe it disables interrupts to prevent other processes writing to the
shared video/system RAM as it DMAs.  I would like to verify that the
problem still occurs with their driver, before I try to convince them
there's a hardware issue with the EPIA boards.

On that note, assuming I verify the bug, does anyone have any
recommendations for getting VIA to take me seriously?  The problem is
very easy to reproduce.

Lee

Re: [Unichrome-devel] Dragging window in X causes soundcard interrupts to be lost

[Lee Revell]

On Sat, 2004-07-31 at 19:37, Alan Cox wrote:
> On Sul, 2004-08-01 at 01:25, Lee Revell wrote:
> > Do you have the original driver source from VIA handy?  This is looking
> > more and more like a hardware bug - 2D acceleration engine activity
> > causes interrupts from the PCI slot to be disabled for long periods. 
> 
> I do. There is no code in the 2D engine that touches interrupt control
> at all. 
> 

Yes, I saw that.  This basically means it has to be a hardware bug,
correct?

> > Maybe it disables interrupts to prevent other processes writing to the
> > shared video/system RAM as it DMAs.  I would like to verify that the
> > problem still occurs with their driver, before I try to convince them
> > there's a hardware issue with the EPIA boards.
> 
> A similar problem occurs with some other chips when you write enough
> data to the chip that the FIFO fills and the PCI bus locks until the
> write can complete. Various vendors implemented this at one point for
> benchmarketing reasons and that would have a similar effect if so.
> 

This was the first thing that occurred to me, but I am not really a
video driver expert, and looking at the code it's just banging bits.  I
have hacked device drivers, just not video, and I don't have the
bandwidth to learn right now.

> The 2D driver source is essentially the same as the source in Xorg CVS
> barring cleanups and the accelerator code has not changed at all. You
> might want to take a look at the fifo management side of things in that
> code.
> 
> > On that note, assuming I verify the bug, does anyone have any
> > recommendations for getting VIA to take me seriously?  The problem is
> > very easy to reproduce.
> 
> I have some contact with VIA however you need to understand that the
> graphics world moves rapidly. I would be suprised if the CLE266 saw any
> more development given the CN400 has been demoed, although I certainly
> can't speak for VIA on this matter.
> 

Yes, I would be happy to just get an acknowledgement of the issue. 
Actually I don't even need that, I just want to know if it's fixed in
the newer ones.  I have a perfectly acceptable workaround.  The 2D
acceleration is pretty shoddy anyway, many things seem to work better
with NoAccel.   I still love the EPIA board.

Maybe you could forward this on to them?  Off the record is fine.

Lee

Re: [Unichrome-devel] Dragging window in X causes soundcard interrupts to be lost

[Lee Revell]

On Sat, 2004-07-31 at 19:37, Alan Cox wrote:
> On Sul, 2004-08-01 at 01:25, Lee Revell wrote:
> > Do you have the original driver source from VIA handy?  This is looking
> > more and more like a hardware bug - 2D acceleration engine activity
> > causes interrupts from the PCI slot to be disabled for long periods. 
> 
> I do. There is no code in the 2D engine that touches interrupt control
> at all. 
> 
> > Maybe it disables interrupts to prevent other processes writing to the
> > shared video/system RAM as it DMAs.  I would like to verify that the
> > problem still occurs with their driver, before I try to convince them
> > there's a hardware issue with the EPIA boards.
> 
> A similar problem occurs with some other chips when you write enough
> data to the chip that the FIFO fills and the PCI bus locks until the
> write can complete. Various vendors implemented this at one point for
> benchmarketing reasons and that would have a similar effect if so.
> 
> The 2D driver source is essentially the same as the source in Xorg CVS
> barring cleanups and the accelerator code has not changed at all. You
> might want to take a look at the fifo management side of things in that
> code.

OK, turns out that my (and your, and Thomas Hellstrom, the Unichrome
maintainer's) theory was correct - this is exactly what is happening:

On Wed, 2004-09-01 at 03:53, Thomas Hellström wrote: 
> 
> I've think I've found an answer to this, and it seems to be related to
> what I mentioned earlier, namely that any attemt to write over PCI to a
> busy video engine will halt the processor until the video accepts new
> data.
> 
> The wait-for-idle loop seems only to be used as a flush-and-sync, to make
> sure that accelerated rendering has completed. There is probably no check
> for ongoing engine activity before writing to the 2d engine. Same as for
> VIA's own mpeg2 code. Such a check will be implemented and will cause a
> very slight overhead compared to today's code.
> 
> I'm starting to fix this as part of compatibility with the new drm with
> AGP DMA transfers, when available. This will not go into "production" for
> about least two or three weeks, but if you are interested, I could send
> you an updated via_accel.c sooner to see if it cures your problem.
> 
> Regards
> Thomas
> 

So, it looks like vendors are still up to the same tricks...

Lee