RFC: bitmap line alignment

RFC: bitmap line alignment

[Knut Petersen]

Hi everybody

I learned the hard way that image->width*image->height is not equal to the
number of bits consumed by the image bitmap. Every single line of bits is
aligned to a byte boundary.

Wouldn´t it be much more efficient to align every line to an u32 boundary?
Despite the obvious advantages of aligned cpu access to large arrays it
would also help to simplify the code for at least the cyberblade 
acceleration
engine.

The cyberblade always requires 32 bit quantities, so if the width of the 
image
is eg. 33, I have to feed _two_ u32 to it for every pixel line. Is the 
same true
for other acceleration engines?

I have not read the code of most of the framebuffer drivers, but I know 
that
a lot of them do not use accelerated imageblits. Those that do provide 
their own
functions would need to be adapted, as well as the cfb_imageblit 
function ...

Comments, please.

cu,
 Knut


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: RFC: bitmap line alignment

[Antonino A. Daplas]

Knut Petersen wrote:
> Hi everybody
> 
> I learned the hard way that image->width*image->height is not equal to the
> number of bits consumed by the image bitmap. Every single line of bits is
> aligned to a byte boundary.
> 
> Wouldn´t it be much more efficient to align every line to an u32 boundary?
> Despite the obvious advantages of aligned cpu access to large arrays it
> would also help to simplify the code for at least the cyberblade
> acceleration
> engine.

If you create your own info->pixmap and an info->pixmap.scan_align = 4, the
driver will be fed a bitmap that have a scanline that is 32-bit aligned.
The default if you don't specify anything, of course, will be an 8-bit
aligned bitmap which, for the sake of code efficiency, is the alignment
assumed by the cfb_* drawing functions.

(An example usage is in the patch I attached just a few days ago when
I commented how the cyberblade should be intelligent enough to handle
bitmaps with variable widths.)
> 
> The cyberblade always requires 32 bit quantities, so if the width of the
> image
> is eg. 33, I have to feed _two_ u32 to it for every pixel line. Is the
> same true
> for other acceleration engines?

Yes, nvidiafb, rivafb and savagefb all require a scan_align of 4, the
i810fb needs u16 (scan_align = 2).

Tony


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: RFC: bitmap line alignment

[Knut Petersen]

Hi Tony,

>If you create your own info->pixmap and an info->pixmap.scan_align = 4, the
>driver will be fed a bitmap that have a scanline that is 32-bit aligned.
>The default if you don't specify anything, of course, will be an 8-bit
>aligned bitmap which, for the sake of code efficiency, is the alignment
>assumed by the cfb_* drawing functions.
>
>(An example usage is in the patch I attached just a few days ago when
>I commented how the cyberblade should be intelligent enough to handle
>bitmaps with variable widths.)
>  
>
Well, here is what I did:  A quick look at the changes in 
cyblafb_imageblit made
it very clear to me that the code could not work as I assumed a totaly 
wrong format
for the image data. To me it was obvious from a look at skeletonfb that 
the data was
a continous bit field without anything like alignment gaps. Anyway, I 
was already
in the process of repeatedly locking up my PC with an accel function 
that was based
on that wrong assumption (I sent data until I reached the erroneously 
calculated end
of the data buffer, the accel engine waited for more data, got a new 
command in
between and locked everything). Yesterday I even attached an old VT 220 for
debugging, and that showed me that the data is byte aligned. Then it was 
easy to write
a much too complicated bitblit for that data with 8 bit pixelline alignment.

I assume by now you are ROTFL ;-)

I think a comment in skeletonfb would be a good idea.

cu,
 Knut




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click