Hardware Blitter, Cache And Uglyness.

[Daid]

I'm having some problems with the hardware blitter. When the source is just drawn with direct pixel acces some pixels remain in the CPU cache and thus are not drawn by the blitter. Is there any way to force the CPU cache to be writen to memory?

This is my hardware blitter code btw:

int inline BoundBlits(SDL_Surface* Source, SDL_Rect* Src, SDL_Surface* Target, SDL_Rect* Trg)
{
  
  return 0;
}

int HardwareBlit(SDL_Surface* Source, SDL_Rect* Src, SDL_Surface* Target, SDL_Rect* Trg)
{
  int SMem = (int)Source->pixels - (int)UpperMem;
  int DMem = (int)Target->pixels - (int)UpperMem;
  if (SMem < 0 || SMem > 0x2000000)
	return 1;
  if (DMem < 0 || DMem > 0x2000000)
	return 2;
  
  if (BoundBlits(Source, Src, Target, Trg))
	return 0;
  
  while(blitter32[MESGSTATUS] & 1);
  blitter32[MESGDSTCTRL] = (0 << 5) | (1 << 6) | (Trg->x % 4) * 8;//8BIT destination and enable ROP on destination
  blitter32[MESGDSTADDR] = 0x2000000 + DMem + Trg->x + Trg->y * Target->pitch;//Address of destination
  blitter32[MESGDSTSTRIDE] = Target->pitch;//Pitch of destination
  blitter32[MESGSRCCTRL] = (1 << 8) | (1 << 7) | (0 << 5) | (Src->x % 4) * 8;//8BIT source and enable ROP on source, source in framebuffer
  blitter32[MESGSRCADDR] = 0x2000000 + SMem + Src->x + Src->y * Source->pitch;//Address of source
  blitter32[MESGSRCSTRIDE] = Source->pitch;//Pitch of source
  blitter32[MESGPATCTRL] = 0;//Nothing with patern
  blitter32[MESGSIZE] = (Src->h << 16) | (Src->w << 0);//Size
  blitter32[MESGCTRL] = (1 << 10) | (1 << 9) | (1 << 8) | 0xCC;//Clear source input FIFO, possitive X,Y, copy ROP
  mb();//Make sure the run is done last
  blitter32[MESGSTATUS] = 0x1;//Run
  return 0;
}

int HardwareBlitTrans(SDL_Surface* Source, SDL_Rect* Src, SDL_Surface* Target, SDL_Rect* Trg)
{
  int SMem = (int)Source->pixels - (int)UpperMem;
  int DMem = (int)Target->pixels - (int)UpperMem;
  if (SMem < 0 || SMem > 0x2000000)
	return 1;
  if (DMem < 0 || DMem > 0x2000000)
	return 2;
  if (BoundBlits(Source, Src, Target, Trg))
	return 0;
  
  while(blitter32[MESGSTATUS] & 1);
  blitter32[MESGDSTCTRL] = (0 << 5) | (1 << 6) | (Trg->x % 4) * 8;//8BIT destination and enable ROP on destination
  blitter32[MESGDSTADDR] = 0x2000000 + DMem + Trg->x + Trg->y * Target->pitch;//Address of destination
  blitter32[MESGDSTSTRIDE] = Target->pitch;//Pitch of destination
  blitter32[MESGSRCCTRL] = (1 << 8) | (1 << 7) | (0 << 5) | (Src->x % 4) * 8;//8BIT source and enable ROP on source, source in framebuffer
  blitter32[MESGSRCADDR] = 0x2000000 + SMem + Src->x + Src->y * Source->pitch;//Address of source
  blitter32[MESGSRCSTRIDE] = Source->pitch;//Pitch of source
  blitter32[MESGPATCTRL] = 0;//Nothing with patern
  blitter32[MESGSIZE] = (Src->h << 16) | (Src->w << 0);//Size
  blitter32[MESGCTRL] = (1 << 11) | (1 << 10) | (1 << 9) | (1 << 8) | 0xCC;//Transparency, Clear source input FIFO, possitive X,Y, copy ROP
  mb();//Make sure the run is done last
  blitter32[MESGSTATUS] = 0x1;//Run
  return 0;
}

 

[Daid]

Never mind, blitter doesn't like it when a pitch is not aligned to 4. Pretty logical actualy. Was not a cache issue.

Maybe a wiki page about the hardware blitter wouldn't hurt?

 

[Squidge]

When blitter pitch is not aligned on 32-bit boundary, you should use fraction parameter.

This is clearly stated in the datasheet. why do we need to repeat it on the wiki?

 

[Daid]

This is clearly stated in the datasheet. why do we need to repeat it on the wiki?

The datasheet doesn't say you need to activate fastio and enable at the same place at it discribes the registers. I don't mean repeating the datasheet. Just some stuff to get people started with it. Details are in the datasheet. Not to mention the datasheet is 577 pages.

Fraction Control
2D Graphic Accelerator performs 32 bit pixel processing internally regardless color format of Source / Destination /
Pattern Image. Maximum performance can be maintained regardless color format through this function.
If image is not aligned as WORD (32 bit), Fraction parameter should be set. Fraction parameter defines offset value of
image by 32 bit units.
Fraction parameter consists of 5 bits and unit is bit.
For example,
When color format of destination image is 16-bpp. Fraction parameter according to X coordinates of destination:
Fraction Parameter = (x%2)*16
When color format of source image is 1-bpp. Fraction parameter according to X coordinates of source:
Fraction Parameter = (x%32)*1

(from the datasheet)
It speaks of X, and the image alignment. Not about pitch (or stride as they call it)

When blitter pitch is not aligned on 32-bit boundary, you should use fraction parameter.

And the blitter didn't act right when I had a fixed pitch of 320 pixels but the X over the source images moved from the left to right with 1 pixel at a time. Without the fraction bits set like I do in the above code it jumped 4 pixels at a time. (8bpp)

I mean these 2 lines of code that took alot of searching to find. Would be nice to mention those.

// enable all video and graphic devices
memregs16[0x090a >> 1] = 0xFFFF;
// enable fastio
memregs16[0x0904 >> 1] |= (1 << 10);

 

[Franxis]

I have taken a look to DrMD source code and i have seen the solution:

flushcache.s

.global flushcache

flushcache:	
	swi #0x9f0002
	mov pc, lr

void flushcache(void);

Call to flushcache() before changing the video buffer and it will run ok.

 

[Feeg]

Maybe a wiki page about the hardware blitter wouldn't hurt?

Doesn't even require discussion really.

If you've found something useful I'm sure plenty of people (including me) would benefit from you adding a page on the wiki.

 

[Daid]

Maybe a wiki page about the hardware blitter wouldn't hurt?

Doesn't even require discussion really.

If you've found something useful I'm sure plenty of people (including me) would benefit from you adding a page on the wiki.

I'm actualy punching at Squidge and a few othere there, who found out shitloads of stuff, but now think it's common knowlage because the posted it on the forum at some time.

I know it isn't always easy to update the wiki. I've been part of the Unreal wiki crowd for quite some time, but slowly it started to become the main source of Unreal development information for almost everyone.