specific optimizations for unaccelerated framebuffers

specific optimizations for unaccelerated framebuffers

[Etienne Lorrain]

  Just a question:

 Has anybody ever tried to have a copy of the video memory in the main
 memory. All the software would access the copy in main memory, and
 the standart DMA is used (permanently) to update the real video memory.
 Maybe a 32 bit int could be used to skip unmodified 64K pages (1 bit
 per page).
 The main processor would never have to wait for PCI read/writes.

  In fact the question is: what kind of bandwidth can we have from a
 standart PC DMA (memory to memory copy)?
  The other problem could be the addresses limits, but using the VESA1
 interface (window switching at 0xA0000), the video memory image
 below 16 Mb and known I/O ports (see Gujin) would solve that.

  Someone has bandwidth measures?
  Etienne.

___________________________________________________________
Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr !
Yahoo! Courrier : http://fr.mail.yahoo.com

Re: specific optimizations for unaccelerated framebuffers

[Etienne Lorrain]

 --- Paul [private mail] wrote:
> You might like to do some performance measurements on
> X with a shadow framebuffer - see
> 
> http://www.xfree86.org/4.1.0/apm5.html

  This seems to still use the processor to copy the shadow buffer
 to the video memory, you will still have the PCI write stall...

> I have a machine with an SiS 630 where the video memory _is_
> main memory - the impact of the graphics processor continually
> DMAing data for display is huge.

  I am not speaking of DMA'ing at the refresh frequency (approx 70 times
 per second the complete video memory), just the modified 64Kb blocks,
 "once upon a while": if a single pixel is written twice, you will just
 see the latter written value on the screen - but who cares.
  Been able to DMA the complete video memory image around 5-10 times/second
 should be over the human eye sensitivity.
  Moreover this pixel will stay on the processor memory cache a lot
 longer, even without MTRR processors.

  Etienne.



___________________________________________________________
Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr !
Yahoo! Courrier : http://fr.mail.yahoo.com

Re: specific optimizations for unaccelerated framebuffers

[Christopher Friesen]

Etienne Lorrain wrote:

>   Been able to DMA the complete video memory image around 5-10 times/second
>  should be over the human eye sensitivity.

Since anything less than 75Hz gives me headaches, how do you propose to make
this work?

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: specific optimizations for unaccelerated framebuffers

[Etienne Lorrain]

 --- Christopher Friesen <cfriesen@nortelnetworks.com> wrote:
> >   Been able to DMA the complete video memory image around 5-10
> > times/second should be over the human eye sensitivity.
> 
> Since anything less than 75Hz gives me headaches, how do you propose to
> make this work?

  Because there is still memory on the video board, the display stay
 at whatever refresh the video board is set up, 80 Hz if you want.

 That is updating the video memory from main memory which is at 10 Hz,
 if a dot is displayed in another color for a duration of 0.01 second
 (100 Hz), the human eye will not see it, so there is no need to
 display it.

 I am _not_ a specialist of the eye, but if something is displayed for
 less than 1/10 of a second, I am not sure to see it. So I can probably
 accept to have a 100 ms delay in between a click and the associated
 window appearing.

  Etienne.


___________________________________________________________
Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr !
Yahoo! Courrier : http://fr.mail.yahoo.com

Re: specific optimizations for unaccelerated framebuffers

[Alex Bligh - linux-kernel]

--On Thursday, 04 October, 2001 4:28 PM +0200 Etienne Lorrain 
<etienne_lorrain@yahoo.fr> wrote:

>> Since anything less than 75Hz gives me headaches, how do you propose to
>> make this work?
>
>   Because there is still memory on the video board, the display stay
>  at whatever refresh the video board is set up, 80 Hz if you want.

A long time ago (tm) I used this approach successfully. It
involved using an (onboard) display controller with a limited
dotclock doing large resolution high bpp displays (but at
10 to 20 Hz), capturing the digital output in offboard Video
RAM, and displaying it at 90Hz. You get some slight artefacts
but in general worked well. And here I was copying the
whole screen each time. If you only copy changed areas,
you'd ge much better results.

--
Alex Bligh

Re: specific optimizations for unaccelerated framebuffers

[Pavel Machek]

Hi!

>   I am not speaking of DMA'ing at the refresh frequency (approx 70 times
>  per second the complete video memory), just the modified 64Kb blocks,
>  "once upon a while": if a single pixel is written twice, you will just
>  see the latter written value on the screen - but who cares.
>   Been able to DMA the complete video memory image around 5-10 times/second
>  should be over the human eye sensitivity.
>   Moreover this pixel will stay on the processor memory cache a lot
>  longer, even without MTRR processors.

Yep, that should work. Same trick as xterm uses.
								Pavel
[Of course, user *will* see you are only updating at 5fps... But it will
be way beter than current slowness.] Are you going to create a patch?
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: specific optimizations for unaccelerated framebuffers

[Etienne Lorrain]

> >   I am not speaking of DMA'ing at the refresh frequency (approx 70 times
> >  per second the complete video memory), just the modified 64Kb blocks,
> >  "once upon a while": if a single pixel is written twice, you will just
> >  see the latter written value on the screen - but who cares.
> >   Been able to DMA the complete video memory image around 5-10
> >  times/second should be over the human eye sensitivity.
> 
> Yep, that should work. Same trick as xterm uses.
> 								Pavel

  Will be a bit more complex than xterm/curses. One of the problem
 is that using the VESA1 interface is needed (DMA restrictions), so
 you need to get back the array given by the Gujin bootloader, describing
 which I/O port to use to switch the 32/64K window at 0xA0000. You do not
 want to go back to real-mode at every VESA1 page change.
 (This array is already available with the current Gujin, using it is
 Gujin native mode for VESA1 cards)

> [Of course, user *will* see you are only updating at 5fps... But it will
> be way beter than current slowness.]

  And the only usual "fast changing" thing is the mouse, so either use a
 hardware extension of the video card or direct PCI write for it only.

 My main question was which bandwidth the standard DMA is able to do
 for memory to memory copy, if it is too slow, do not even start
 to code anything... got no answer. The PC DMA can only copy memory by
 16 bit units - and I am not sure it will behave correctly with
 PCI stalls.

> Are you going to create a patch?

  Lets say, I start just after I finish Gujin; i.e. if you want to see
 something before Linux 3.1, find someone else... I can still help a bit.

  Etienne.

___________________________________________________________
Un nouveau Nokia Game commence. 
Allez sur http://fr.yahoo.com/nokiagame avant le 3 novembre
pour participer à cette aventure tous médias.