Epson13806 performances on Pb1100

Epson13806 performances on Pb1100

[Karl Lessard]

Hi all,

I'm currently developping on a Pb1100 alchemy board, and I use the Epson 
13806 graphic controller connected to the Au1100 static bus. I've written a 
driver for it for kernel 2.6.x, and update the Au1100 code so I can access 
0xE 0000 0000 address range.

Everything works fine, but for the speed. It seems that accessing the chip is 
too slow for having high-graphic performances. The LCLK is set at 49500KHz, 
as the memory clock inside the chip. I know it's a bit overclocked, but a 
lower LCLK freezes my system.

I would like to know if anyone have encountered this performance problem in 
the past with this chip.

Thanks in advance,
Karl

Re: Epson13806 performances on Pb1100

[Dan Malek]

On Dec 8, 2004, at 11:06 AM, Karl Lessard wrote:

> Everything works fine, but for the speed. It seems that accessing the 
> chip is
> too slow for having high-graphic performances.

A couple of things.  First, the Epson controller is obsolete, I don't
know how much time is worth spending on the software.  If you
don't already have a system in production using it, there isn't
much sense spending time working with it.

Second, with the on-chip controller, I have experimented with
some different cache modes for the frame buffer access.  I
don't know if this applicable to the external 13806, but you
could try.  Alchemy has an application note on this, I believe,
but in any case, here is what I put into the au1100fb.c,
au1100fb_mmap() function:

pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK;
pgprot_val(vma->vm_page_prot) |= _CACHE_CACHABLE_CUW;

A similar kind of update is in the current CVS tree.

Fujitsu has a bunch of nice high performance embedded
graphics controllers for many different applications.


	-- Dan

Re: Epson13806 performances on Pb1100

[Pete Popov]

Karl Lessard wrote:
> Hi all,
> 
> I'm currently developping on a Pb1100 alchemy board, and I use the Epson 
> 13806 graphic controller connected to the Au1100 static bus. I've written a 
> driver for it for kernel 2.6.x, and update the Au1100 code so I can access 
> 0xE 0000 0000 address range.
> 
> Everything works fine, but for the speed. It seems that accessing the chip is 
> too slow for having high-graphic performances. The LCLK is set at 49500KHz, 
> as the memory clock inside the chip. I know it's a bit overclocked, but a 
> lower LCLK freezes my system.

I've used the chip with the 2.4 kernel/driver to run X and some 
apps. I'm not sure what you mean by high performance -- does X run 
at reasonable speeds?

Pete

> I would like to know if anyone have encountered this performance problem in 
> the past with this chip.
> 
> Thanks in advance,
> Karl
> 
> 

Re: Epson13806 performances on Pb1100

[Karl Lessard]

>
> I've used the chip with the 2.4 kernel/driver to run X and some
> apps. I'm not sure what you mean by high performance -- does X run
> at reasonable speeds?

I'm not running X, I've just runned a little application that writes a number 
of vertical lines (so pixel per pixel) in a backbuffer and then blit its 
content to the screen. Here's an example of one frame:

__u8 *dest = (__u8*)back_buffer;
memset(dest, 0, back_buffer_size); 	/* clear back buffer */

for (i = 0; i < 500; i++) {			/* 500 lines */
	for (j = 0; j >= 100; j--) {		/* of 100 pixel each */
		dest[(j * fb_width) + i] = 0xFF;
	}				
}

memcpy(front_buffer, dest, back_buffer_size);  /* copy back_buffer to front */


Benching with 500 frames, I obtain a rate of 8 fps with the backbuffer
residing in video memory. The framerate increase to 31 fps when the backbuffer
is in system memory! And if I do the same test using the Au1100 lcd 
controller (which has its front and back buffer in system memory), It goes up 
to 66 fps...

I don't know what's going on when I try to access the 13806 controller, but 
it's really too slow. And using the blit engine don't helps much. The static 
controller seems to be set correctly. By the way, the DRAM is refreshing at 
96Hz, and my CRT display is refreshing at 66Hz.

Any Idea? By the way Dan, I've tried the cache trick, but no luck.

Thanks a lot,
Karl


>
> Pete
>
> > I would like to know if anyone have encountered this performance problem
> > in the past with this chip.
> >
> > Thanks in advance,
> > Karl

Re: Epson13806 performances on Pb1100

[Michael Kelly]

KArl,

There is a bug (they might call it a feature) that causes the Au1100
to perform two accesses when talking to 16-bit peripherals.  The
first access is the real one, while the second access has the byte
enables off.  But, this means every access creates two cycles on
the bus.

I am sure of this bug on the standard peripheral bus, and I am pretty
sure it still exists when talking via the LCD signals, since the same
bus controller is used.

MIchael

At 02:38 PM 12/8/2004, Karl Lessard wrote:
> >
> > I've used the chip with the 2.4 kernel/driver to run X and some
> > apps. I'm not sure what you mean by high performance -- does X run
> > at reasonable speeds?
>
>I'm not running X, I've just runned a little application that writes a number
>of vertical lines (so pixel per pixel) in a backbuffer and then blit its
>content to the screen. Here's an example of one frame:
>
>__u8 *dest = (__u8*)back_buffer;
>memset(dest, 0, back_buffer_size);      /* clear back buffer */
>
>for (i = 0; i < 500; i++) {                     /* 500 lines */
>         for (j = 0; j >= 100; j--) {            /* of 100 pixel each */
>                 dest[(j * fb_width) + i] = 0xFF;
>         }
>}
>
>memcpy(front_buffer, dest, back_buffer_size);  /* copy back_buffer to front */
>
>
>Benching with 500 frames, I obtain a rate of 8 fps with the backbuffer
>residing in video memory. The framerate increase to 31 fps when the backbuffer
>is in system memory! And if I do the same test using the Au1100 lcd
>controller (which has its front and back buffer in system memory), It goes up
>to 66 fps...
>
>I don't know what's going on when I try to access the 13806 controller, but
>it's really too slow. And using the blit engine don't helps much. The static
>controller seems to be set correctly. By the way, the DRAM is refreshing at
>96Hz, and my CRT display is refreshing at 66Hz.
>
>Any Idea? By the way Dan, I've tried the cache trick, but no luck.
>
>Thanks a lot,
>Karl
>
>
> >
> > Pete
> >
> > > I would like to know if anyone have encountered this performance problem
> > > in the past with this chip.
> > >
> > > Thanks in advance,
> > > Karl

Michael J. Kelly
VP Engineering/Marketing
Cogent Computer Systems, Inc.
1130 Ten Rod Road
Suite A-201
North Kingstown, RI 02852
tel:401-295-6505 fax:401-295-6507
www.cogcomp.com
alternate email: mkelly6505@hotmail.com

Re: Epson13806 performances on Pb1100

[Karl Lessard]

On December 8, 2004 03:37 pm, Michael Kelly wrote:
> KArl,
>
> There is a bug (they might call it a feature) that causes the Au1100
> to perform two accesses when talking to 16-bit peripherals.  The
> first access is the real one, while the second access has the byte
> enables off.  But, this means every access creates two cycles on
> the bus.
>
> I am sure of this bug on the standard peripheral bus, and I am pretty
> sure it still exists when talking via the LCD signals, since the same
> bus controller is used.
>
> MIchael

Well, that may cause a problem of course. Do you mean that writing 8-bit or 
16-bits data through a chip select configured for 16-bit data bus will send 
in fact two write signals? 

If it is the case, then I obviously need to send 32-bit data for every 
access, since the second write will be used to send the second word (I 
suppose). Do I understand well?

>
> At 02:38 PM 12/8/2004, Karl Lessard wrote:
> > > I've used the chip with the 2.4 kernel/driver to run X and some
> > > apps. I'm not sure what you mean by high performance -- does X run
> > > at reasonable speeds?
> >
> >I'm not running X, I've just runned a little application that writes a
> > number of vertical lines (so pixel per pixel) in a backbuffer and then
> > blit its content to the screen. Here's an example of one frame:
> >
> >__u8 *dest = (__u8*)back_buffer;
> >memset(dest, 0, back_buffer_size);      /* clear back buffer */
> >
> >for (i = 0; i < 500; i++) {                     /* 500 lines */
> >         for (j = 0; j >= 100; j--) {            /* of 100 pixel each */
> >                 dest[(j * fb_width) + i] = 0xFF;
> >         }
> >}
> >
> >memcpy(front_buffer, dest, back_buffer_size);  /* copy back_buffer to
> > front */
> >
> >
> >Benching with 500 frames, I obtain a rate of 8 fps with the backbuffer
> >residing in video memory. The framerate increase to 31 fps when the
> > backbuffer is in system memory! And if I do the same test using the
> > Au1100 lcd controller (which has its front and back buffer in system
> > memory), It goes up to 66 fps...
> >
> >I don't know what's going on when I try to access the 13806 controller,
> > but it's really too slow. And using the blit engine don't helps much. The
> > static controller seems to be set correctly. By the way, the DRAM is
> > refreshing at 96Hz, and my CRT display is refreshing at 66Hz.
> >
> >Any Idea? By the way Dan, I've tried the cache trick, but no luck.
> >
> >Thanks a lot,
> >Karl
> >
> > > Pete
> > >
> > > > I would like to know if anyone have encountered this performance
> > > > problem in the past with this chip.
> > > >
> > > > Thanks in advance,
> > > > Karl
>
> Michael J. Kelly
> VP Engineering/Marketing
> Cogent Computer Systems, Inc.
> 1130 Ten Rod Road
> Suite A-201
> North Kingstown, RI 02852
> tel:401-295-6505 fax:401-295-6507
> www.cogcomp.com
> alternate email: mkelly6505@hotmail.com

Re: Epson13806 performances on Pb1100

[Eric DeVolder]

[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]

The SED13506 device is horribly slow (it stalls the processor an 
enormous amount of time) while it accesses external DRAM for screen 
updates. The SED13806 has integrated SDRAM and performs better than the 
SED13506, but not nearly as well as a PCI graphics card. If you were to 
place a scope on the EWAIT# signal, you'll see it asserted a significant 
amount of time during Au accesses to the SED13806; simply put, this is 
the single largest factor in the poor performace you are observing. Your 
empirical tests verify this.

As for the bug/feature, the controller always performs two beats for 
16-bit chip-selects, so it is best to utilize both beats by performing 
32-bit accesses rather than 8 or 16 (in which case one beat is not 
utilized).

Karl Lessard wrote:

>On December 8, 2004 03:37 pm, Michael Kelly wrote:
>  
>
>>KArl,
>>
>>There is a bug (they might call it a feature) that causes the Au1100
>>to perform two accesses when talking to 16-bit peripherals.  The
>>first access is the real one, while the second access has the byte
>>enables off.  But, this means every access creates two cycles on
>>the bus.
>>
>>I am sure of this bug on the standard peripheral bus, and I am pretty
>>sure it still exists when talking via the LCD signals, since the same
>>bus controller is used.
>>
>>MIchael
>>    
>>
>
>Well, that may cause a problem of course. Do you mean that writing 8-bit or 
>16-bits data through a chip select configured for 16-bit data bus will send 
>in fact two write signals? 
>
>If it is the case, then I obviously need to send 32-bit data for every 
>access, since the second write will be used to send the second word (I 
>suppose). Do I understand well?
>
>  
>
>>At 02:38 PM 12/8/2004, Karl Lessard wrote:
>>    
>>
>>>>I've used the chip with the 2.4 kernel/driver to run X and some
>>>>apps. I'm not sure what you mean by high performance -- does X run
>>>>at reasonable speeds?
>>>>        
>>>>
>>>I'm not running X, I've just runned a little application that writes a
>>>number of vertical lines (so pixel per pixel) in a backbuffer and then
>>>blit its content to the screen. Here's an example of one frame:
>>>
>>>__u8 *dest = (__u8*)back_buffer;
>>>memset(dest, 0, back_buffer_size);      /* clear back buffer */
>>>
>>>for (i = 0; i < 500; i++) {                     /* 500 lines */
>>>        for (j = 0; j >= 100; j--) {            /* of 100 pixel each */
>>>                dest[(j * fb_width) + i] = 0xFF;
>>>        }
>>>}
>>>
>>>memcpy(front_buffer, dest, back_buffer_size);  /* copy back_buffer to
>>>front */
>>>
>>>
>>>Benching with 500 frames, I obtain a rate of 8 fps with the backbuffer
>>>residing in video memory. The framerate increase to 31 fps when the
>>>backbuffer is in system memory! And if I do the same test using the
>>>Au1100 lcd controller (which has its front and back buffer in system
>>>memory), It goes up to 66 fps...
>>>
>>>I don't know what's going on when I try to access the 13806 controller,
>>>but it's really too slow. And using the blit engine don't helps much. The
>>>static controller seems to be set correctly. By the way, the DRAM is
>>>refreshing at 96Hz, and my CRT display is refreshing at 66Hz.
>>>
>>>Any Idea? By the way Dan, I've tried the cache trick, but no luck.
>>>
>>>Thanks a lot,
>>>Karl
>>>
>>>      
>>>
>>>>Pete
>>>>
>>>>        
>>>>
>>>>>I would like to know if anyone have encountered this performance
>>>>>problem in the past with this chip.
>>>>>
>>>>>Thanks in advance,
>>>>>Karl
>>>>>          
>>>>>
>>Michael J. Kelly
>>VP Engineering/Marketing
>>Cogent Computer Systems, Inc.
>>1130 Ten Rod Road
>>Suite A-201
>>North Kingstown, RI 02852
>>tel:401-295-6505 fax:401-295-6507
>>www.cogcomp.com
>>alternate email: mkelly6505@hotmail.com
>>    
>>
>
>
>  
>

[-- Attachment #2: Type: text/html, Size: 4558 bytes --]