Need advice on blitting to dword alignment

Hi There

I am in the final stages of developing a framebufferdriver for 
the Silicon Motion Lynx series chip, but ran into troubles
during development of accelerated host blits (mono font expansion to
arbitrary bpp depths)

The Lynx chip expects data in dwords no matter what. If
the image is a multiple of 32 bits wide this is just fine, 
but if it is not I have to pad in zeros in the last dword _for 
each line_

eg. an 24bit by 16 bit mono image would consist of 1 dword for each line
taking 16 dwords to transfer.

Is there _any_ way I can force the framebuffer console system to give
images aligned to dwords? It is ofcourse possible to transfer data
using a for loop taking the padding into account, but that seems
overly complex and in-efficient compared to a memcpy_toio(src,dst,size)

Any hints or suggestions?

Regards Thomas, Denmark


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Hi There

I am in the final stages of developing a framebufferdriver for 
the Silicon Motion Lynx series chip, but ran into troubles
during development of accelerated host blits (mono font expansion to
arbitrary bpp depths)

The Lynx chip expects data in dwords no matter what. If
the image is a multiple of 32 bits wide this is just fine, 
but if it is not I have to pad in zeros in the last dword _for 
each line_

eg. an 24bit by 16 bit mono image would consist of 1 dword for each line
taking 16 dwords to transfer.

Is there _any_ way I can force the framebuffer console system to give
images aligned to dwords? It is ofcourse possible to transfer data
using a for loop taking the padding into account, but that seems
overly complex and in-efficient compared to a memcpy_toio(src,dst,size)

Yes!!!!

The NVIDIA fbdev driver had the same problems. That is what struct 
fb_pixmap is for. Since you need 32 bit padded images you would need to 
fill in your own pixmap when you initalize the driver. Something like 
this.

	info->pixmap.addr = kmalloc(64*1024, GFP_KERNEL);
	info->pixmap.size = 64 * 1024;
        info->pixmap.buf_align = 4;
        info->pixmap.scan_align = 4;
        info->pixmap.flags = FB_PIXMAP_SYSTEM;
 
    Okay now what each field means. First is the addr field. This is 
scratch drawing area. In the above example I used normal system ram and tell 
ths system you are using normal ram with the FB_PIXMAP_SYSTEM flag. The 
size is of course the size of the drawing buffer. 
    Now some systems have a drawing buffer in hardware. A good example is the 
Geode graphics chipset. It has a bitblit buffer on chip. In this case you 
would point addr to that hardware address and set the flag to FB_PIXMAP_IO. 
Then just fill in the data. I just finished the cursor api and have a few 
examples of the hardware cursor using something similiar. For the Mach64 
cursor I did something like this at initialization.

P.S I didn't not remove the Big endian code or sparc code. I only cleaned 
it up to show a easy example. 

int __init aty_init_cursor(struct fb_info *info)
{
	unsigned long addr;

	info->fix.smem_len -= PAGE_SIZE;

	addr = (unsigned long) info->screen_base + info->fix.smem_len;
	info->sprite.addr = (u8 *) addr;	

	if (!info->sprite.addr)
		return -ENXIO;
	info->sprite.size = PAGE_SIZE;
	info->sprite.scan_align = 8;	// Cursor pad is 64 bits wide	
	info->sprite.buf_align = 8;	// and 64 bits tall.
	info->sprite.write_access = 2;	// Each pixel is represented by 2 bits
	info->sprite.flags = FB_PIXMAP_IO;	
	info->sprite.outbuf = aty_set_cursor_shape;
}

Here we grab the last page in framebuffer memory and use it as a drawing 
pad. Note the flag. Then we provide our our outbuf function. This function 
writes data to the buffer. With hardware we might need special magic to 
write the data. Also we have a inbuf function for taking data out of a 
hardware buffer and placing it into system memory.
	This can also be used with DMA memory regions. You can point addr 
to the dma region and set the flag to FB_PIXMAP_IO | FB_PIXMAP_SYNC. The 
reason is with dma you have to sync the memory region when it is "full".
No async support yet. Again you have to supply your own outbuf and inbuf
functions. Usually with dma you have to place headers at the front the 
padded image data and sometimes at the end of it as well. There is a 
function to grab a chunck of this memory called fb_get_buffer_offset. 
Usually the upper memory layers handle it only but in the case of DMA you 
might want to grab you own memory size. I haven't resolved that issue yet.

	Scan_align paddes the image data for each scanline. Buf_align pads 
the whole chuck of data. 


        Hope that helps.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

On Fri, Sep 12, 2003 at 06:09:56PM +0100, James Simmons wrote:

Hi Again

The NVIDIA fbdev driver had the same problems. That is what struct 
fb_pixmap is for. Since you need 32 bit padded images you would need to 
fill in your own pixmap when you initalize the driver. Something like 
this.

	info->pixmap.addr = kmalloc(64*1024, GFP_KERNEL);
	info->pixmap.size = 64 * 1024;
        info->pixmap.buf_align = 4;
        info->pixmap.scan_align = 4;
        info->pixmap.flags = FB_PIXMAP_SYSTEM;

[snip]

Thanks a million --- you guys truely rocks! The good part is, that
now my mono/font expansion blit actually works and I can actually feel
the improvement when scrolling around in emacs ;-) .... but it came at a cost it
seems:

* My software cursor became messed up/flashing. I suspect that the software cursor
  does not work with alignment>1, but is that right??
* Tux, which was nicely drawn using the software fallback before I changed the pixmap 
  alignment, became messed up.

It made me suspect that the software imageblit does not work when alignment>1,
and further tests seemed to support this. Can I fix it somehow? Or
is it fixed in later kernel versions? (I use 2.5.73 for development at the moment)

Regards Thomas


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

On Fri, Sep 12, 2003 at 09:13:41PM +0200, Thomas S. Iversen wrote:

Hi 

* Tux, which was nicely drawn using the software fallback before I changed the pixmap 
  alignment, became messed up.

I'll find the brown paper bag myself for this one. My code read:

	if(image->depth!=1)
		cfb_imageblit(info,image);

	.... accelerated depth==1 code

instead of 

	if(image->depth!=1)
		return cfb_imageblit(info,image);

	.... accelerated depth==1 code

That gave me my tux back. My curser however is still broken. I have also
tried to do a software blitt with both the alignemnt options set to 4 and
it does not appear to work :-/

Regards Thomas


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Thanks a million --- you guys truely rocks! The good part is, that
now my mono/font expansion blit actually works and I can actually feel
the improvement when scrolling around in emacs ;-) .... but it came at a cost it
seems:

Cool.

* My software cursor became messed up/flashing. I suspect that the software cursor
  does not work with alignment>1, but is that right??

This is fixed in later kernels. A few issues remain tho with the software 
cursor in the latest kernels. 

* Tux, which was nicely drawn using the software fallback before I changed the pixmap 
  alignment, became messed up.

I seen the other email.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

instead of 

	if(image->depth!=1)
		return cfb_imageblit(info,image);

	.... accelerated depth==1 code

No hardware support to draw color images :-(
 

That gave me my tux back. My curser however is still broken. 

Cursor broken in 2.5.73.

I have also
tried to do a software blitt with both the alignemnt options set to 4 and
it does not appear to work :-/

You mean a cfb_copyarea call? 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

On Fri, Sep 12, 2003 at 10:26:33PM +0100, James Simmons wrote:

No hardware support to draw color images :-(

No, not at the moment, will look into that later; my
time is, like everybody else, limited :-(

Cursor broken in 2.5.73.

Ahh, I will try some of the later kernels. Or add support
for hardware cursor when time permits :-)

You mean a cfb_copyarea call? 

No a cfb_imageblit(info,image) call. My code looked roughly like
during development:

void lynxfb_imageblit(info, image) {
	if(image->depth!=1)
	 	return cfb_imageblit(info,image);
	
	hardware accelerated font blit of
 	the requested image, but 
	_hardwired_ to start at 0,0

	cfb_imageblit(info,image); //At the right position
}

When I set alignment to 1 the code above does produce a normal
console except for the top line which are blitted wrong by
the hardware.

If I change alignment to 4, the hardware blits correctly, but
the rest of screen become garbage (sort of, one get a staircase effect,
probably because of the alignment)

It is not a problem anymore, now that the hardware blitting
works for me, but I will see if I get the same effect in 2.6.0pre 
kernels at the same time as I hope for the cursor to turn up all
normal again ;-)

Thanks for your help

Regards Thomas


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf