Hi Guys,

For anyone who's found that 18-bit color mode (consoleLCD-vx, verdex 600mhz) is a complete dog to work with, and is demotivated by the sucky performance, I have some news that may interest you.  I have begun writing my own little graphics engine and through some pretty straightforward optimizations, I've managed to push 36.57 FPS, fullscreen update and using a back buffer. This will be more than adequate to perform nice animations and such.

Focus on tuning your code specifically for the PXA27x architecture if you want to reap the performance benefits. That means don't write across 32-bit boundaries and minimize access to the video memory. Its VERY expensive. :)

That my 2cents anyway.

Kind Regards,
Christian Ruocco.

thaGod wrote:
Chris,

Thanks for the insight.. it makes perfect sense. Hehe... and to think.. 18
bit mode was added because they had 2 free pins on the 60 pin hirose...
Would you have traded 2 extra least significant bits for an odd word length?
Sometimes high-level programmers are comical (myself included).

To be honest I haven't even glanced at this driver in over a month, but I
will need it to work in the end. I am confident that it can be fixed.. it
really isn't a complicated driver as far as these things go.

Aside from those comments... I really don't think I should even try to
answer your main question just yet. I'd just be blowing smoke until I have a
chance to refocus. It's gotta be improper packing. I'm gonna have to leave
it at that until I know more.

Erick


Christian Ruocco wrote:
  
Hi theGod/Guys,

What I did to benchmark it was to simply write a putpixel routine for 
both 18-bit and 16-bit modes and then fill the screen with a color 
gradient over and over again and then time it.

I'm believe the serious performance hit is due to the 3-byte pixels. 
Every odd pixel read would cause the ARM to load two dwords from memory 
instead of one since the one byte is in the first 32-bit word and the 
last 2 are in the next. Any read/write seems to be quite expensive. 
Writing also requires nasty read->AND out bits->OR new bits->write to 
the relevant DWORDS unless you write each byte seperately but that 
should be even slower.  16-bit has few hassles.. every pixel is 
obviously contained in 1 half of a dword, which prevents double reads 
and such and its easier to write fast putpixel, blit routines.

I agree that the performance of the gfx is pretty suck, but 16-bit 
should solve your animation blues..  theGod: whats the problem with the 
16-bit mode exactly. I know the RGB channels are skewed some how.. 
sounds similar to earlier 18-bit problems. Are you confident that you 
can fix this?

About the 600Mhz thing. Is the CPU running at 600Mhz? I see on bootup it 
says turbo mode is 600Mhz. Is it -in- turbo mode or does it have to be 
enabled? If so how?

Xris.


thaGod wrote:
    
Hiyas Chris,

How are you benchmarking? If I remember right... the 16 bit mode is
handled
by most of the same functions as 18 bit mode. I'm not sure where the
performance might be lost.... although I will most definitely check it
out. 

I have noticed that for a 600Mhz processor... performance in graphics is
actually kinda disappointing. Animations are not smooth enough (with
directfb anyways) to put into a production product. Who knows what causes
it
at this point though.

Erick


Christian Ruocco wrote:
  
      
Hi Guys,

Something nobody seems to notice is that the performance of 18bit is 
total suck! My experiments in benchmarking 18-bit vs broken 16-bit is 
that 16 is at least 4 times faster and also requires much less bit 
juggling for putpixel routines and the like...

Steve/theGod: How is that 16-bit mode fix going? :) :) I would offer my 
help but I'm not sure where to start!

Xris.

thaGod wrote:
    
        
These are the exact color swaps I experienced with a color bar pattern
and
the old misaligned pxafb.c driver. Per Steve's suggestion that the
latest
version is up to date and correct you should be sure you're using the
latest
svn revision. If that doesn't work then I would be happy to send you my
version of pxafb.c and pxaregs.h so that you may compare differences or
use
them or whatever you choose.

I did my testing using directfb-1.1 (which is pretty easy to get
compiled
and a very good test foundation) and eventually won.

Erick


Justin Rajewski wrote:
  
      
          
I did find out that for each Pixel you need three app->screen_ptr[i] =
0xFF; here is a picece of the modified  code that cycles through the
colors. 
static FBTErr fbt_clear( App *app ) {
  FBTErr err = FBT_E_NOERR;
  unsigned int i, size,col,r,g,b;

  do {
    if( NULL == app ) {
      err = FBT_E_NULL;
      break;
    }
/*
printf ("Enter the three bytes:");
scanf("%x %x %x",&r,&g,&b);
*/
r=0;
g=0;
b=0;
while (1){
    for( i = 0; i < app->size; i+=3 ) {
	app->screen_ptr[i] = b;
	app->screen_ptr[i+1] = g;
	app->screen_ptr[i+2] = r ;
++b;
if (b>0x3F){
b=0;
g++;
}
if (g>0x3F){
g=0;
r++;
}
if (r>0x3F)break;
}
if (r>0x1F)break;
usleep (1000000);
}
  } while( 0 );

  return( err );
  
}
I still am not sure on the bit arrangement as send 0x0f 0x0f 0x0f
should
make gray it makes yellow. The code above assumes that it is like
XXBBBBBB
XXGGGGGG XXRRRRRR.
Thanks,
Justin

Justin Rajewski wrote:
    
        
            
Steve,
In the program on
http://hbmobile.org/wiki/index.php?title=FBDirectOnConsoleLCD there
is
the line 
app->screen_ptr[i] = 0xFF; 
Does this mean I need to do this three times per pixel? For example
like
xxxxxxRR RRRRGGGG GGBBBBBB? 
Also after about 5 minutes the LCD turns off, the back light is still
on
but the display stops getting updated. Is this normal?
Thanks,
Justin

Steve Sakoman wrote:
      
          
              
Eric,

As far as I can tell, the current source base is correct for RGB18.

These 18 bits of color info are aligned on 24 bit boundaries (ie
with
6 wasted bits per pixel).  Not optimal, but that's what it is.

I'm not sure why you say it doesn't work.  There are certainly
issues
with a lack of support for RGB18 in the open source world, but that
is
another problem.

Steve

On Jan 13, 2008 12:32 PM, thaGod <thagod@gmail.com> wrote:
        
            
                
Well the good news is that all the hardware is right as far as the
LCD
bits
are concerned. It is 18bit color. It is a software issue. You are
going
to
have to implement those changes in the LDD_16 and LDD_17 thread
somehow..
although I haven't run the problem down again since Craig put
together
patches for the source. It appears as though the problem still
exists?

The other color bits are supposed to be aranged in 666 format, but
it
doesn't work because they are not aligned properly in pxafb.c. In
my
workaround I returned it to 565 format and threw away the least
significant
bits of red and blue.

If you fix it this way be sure you leave your framebuffer in 18bpp
mode
even
though there are only 16 bits being used. It's an ugly fix, but it
works for
the time being.

Erick



Justin Rajewski wrote:
          
              
                  
One last question, is there some way to wait for the vblank, so
the
changes are smooth?

Justin Rajewski wrote:
            
                
                    
My LCD only showed green and blue. The red was very low and you
              
                  
                      
could
          
              
                  
almost not see it. I would try updating to the newest SVN. I used
              
                  
                      
the
          
              
                  
ConsoleLCD-Vx so I did not have to wire anything.


Justin Rajewski wrote:
              
                  
                      
One more thing, is not the color 18bpp? When I use 0xFF it is
white
                
                    
                        
and
          
              
                  
0x00 is black, that makes 8bpp. Also how are the color bits
                
                    
                        
arranged?
          
              
                  
Like BBBGGGGRRR?
Thanks,
Justin

Demetris Zavorotnichenko wrote:
                
                    
                        
Have I understood this post correctly ?

I have a problem with my LCD as well.

My problem is that I have all the connections for the LCD
correct
                  
                      
                          
but
          
              
                  
when I
want to view something then the Green and Blue are inverted so
I
                  
                      
                          
see
          
              
                  
green
where is blue and blue where is green.

Was this a problem and now is fixed ?

-----Original Message-----
From: gumstix-users-bounces@lists.sourceforge.net
[mailto:gumstix-users-bounces@lists.sourceforge.net] On Behalf
Of
Justin
Rajewski
Sent: Sunday, January 13, 2008 8:33 PM
To: gumstix-users@lists.sourceforge.net
Subject: Re: [Gumstix-users] LCD only blue and green?


I updated the SVN to the newest and now it works great.
Thanks,
Justin

thaGod wrote:
                  
                      
                          
I'm not exactly sure where the code revisions were introduced,
                    
                        
                            
but the
          
              
                  
pxafb.c and pxaregs.h files appear to still be wrong on your
                    
                        
                            
setup. I
          
              
                  
think to a certain extent these problems have been fixed in
the
                    
                        
                            
latest
          
              
                  
code revisions... most likely the open embedded images that
Steve
                    
                        
                            
has
          
              
                  
been
working on. I can say for sure though that there is an older
                    
                        
                            
thread on
          
              
                  
this mailing list regarding LDD_16 and LDD_17 missing from
                    
                        
                            
pxaregs.h.
          
              
                  
There is instruction documented there on how to realign the
bits
                    
                        
                            
to
          
              
                  
display colors properly.

The jist of it is as follows. LDD_16 and LDD_17 used to be
                    
                        
                            
missing
          
              
                  
from
pxaregs.h. These are the two most significant red bits. The
bit
alignment
shift occurs partially as a result of this, and partially
because
                    
                        
                            
the
          
              
                  
pxafb.c driver was written wrong. There are instructions for
re-offsetting
the bits in that thread. I believe the pxaregs.h patchwork is
                    
                        
                            
fixed
          
              
                  
already.. you might check anyways. You might also try updating
to
                    
                        
                            
the
          
              
                  
latest SVN if you haven't already. Another option is to try
the
                    
                        
                            
open
          
              
                  
embedded images that Steve has prepared.

Search for and read through those threads and hit me back...
I'll
                    
                        
                            
be
          
              
                  
happy
to help if you have any problems figuring it out.

Erick


Justin Rajewski wrote:
                    
                        
                            
Also I tried the LCD demo code on the wiki. I get
segmentation
                      
                          
                              
fault
          
              
                  
but
it does make a box on the LCD. Does anyone have a code that
will
                      
                          
                              
show
          
              
                  
red and works with the LCD gumstix sells?

Thanks,
Justin



                      
                          
                              
-------------------------------------------------------------------------
          
              
                  
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.

                      
                          
                              
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
          
              
                  
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users


                      
                          
                              
                    
                        
                            
--
View this message in context:

                  
                      
                          
http://www.nabble.com/LCD-only-blue-and-green--tp14779923p14789259.html
          
              
                  
Sent from the Gumstix mailing list archive at Nabble.com.



                  
                      
                          
-------------------------------------------------------------------------
          
              
                  
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.

                  
                      
                          
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
          
              
                  
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users




                  
                      
                          
-------------------------------------------------------------------------
          
              
                  
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.

                  
                      
                          
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
          
              
                  
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users


                  
                      
                          
                
                    
                        
              
                  
                      
            
                
                    
--
View this message in context:
http://www.nabble.com/LCD-only-blue-and-green--tp14779923p14790640.html

Sent from the Gumstix mailing list archive at Nabble.com.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users

          
              
                  
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users


        
            
                
      
          
              
    
        
            
  
      
          
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users


    
        
  
      
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users