Dingoonity.org

Exactly. The IPU automatically scales whatever screen resolution you throw at it. Of course if you set the screen resolution to 320x240, it wont scale anything for obvious reasons.
Lets say you want to scale a 256x224 screen: Then you simply do:

screen = SDL_SetVideoMode(256, 224, 16, SDL_HWSURFACE | SDL_DOUBLEBUF);
or if you want to use triple buffering (which is actually recommended to do):

screen = SDL_SetVideoMode(256, 224, 16, SDL_HWSURFACE | SDL_TRIPLEBUF);
Aditionally, you can also force the IPU to keep the aspect ratio when scaling, or force it to stretch to full screen.
By default it is set to keep the aspect ratio. You can alternate the modes by pressing power+A, but i found it painful to have to use that every time you start a new game, so you can make 2 different scalers (an "aspect ratio" one, and a "fullscreen" one) selectable from the emulator menu:

if (aspect_ratio_scaling)
{
FILE* aspect_ratio_file = fopen("/sys/devices/platform/jz-lcd.0/keep_aspect_ratio", "w");
if (aspect_ratio_file)
{
fwrite("1", 1, 1, aspect_ratio_file);
fclose(aspect_ratio_file);
}
}
if (fullscreen_scaling)
{
FILE* aspect_ratio_file = fopen("/sys/devices/platform/jz-lcd.0/keep_aspect_ratio", "w");
if (aspect_ratio_file)
{
fwrite("0", 1, 1, aspect_ratio_file);
fclose(aspect_ratio_file);
}
}
Also, if you need the IPU to use downscaling at any point (in the case of MAME, you will need it at least for CPS games), you must reflect that in the .desktop file which comes packed into the OPK, by adding the following line in the .desktop file:

X-OD-NeedsDownscaling=true

Thanks for the quick and comprehensive answer.

Quote from: hi-ban on September 25, 2014, 02:41:41 am

Code: [Select]

screen = SDL_SetVideoMode(256, 224, 16, SDL_HWSURFACE | SDL_DOUBLEBUF);

For a single buffered video mode, can I simply write to screen->pixels or do I need to write to the screen structure using other SDL functions?

Don't use single buffering, it will suck in one way or another:

• SDL_SWSURFACE is slower than SDL_HWSURFACE and will cause tearing.
• SDL_HWSURFACE without SDL_DOUBLEBUF will tear and will flicker on overpainting. Also it will do unnecessary cache flushes if the frame rate is below 60 fps.

If your application has a frame rate that regularly drops below 60 fps, double buffering will give you a constant 30 fps. If that is not what you want, you can use triple buffering. It will increase latency a bit, but it can output glitch-free at for example 50 fps. See this patch for a code example.

In any mode, you can push pixels via screen->pixels. To make the code portable, lock the surface before accessing the pixels pointer and unlock it when you're done, but on the Zero the locking doesn't actually do anything. Make sure you don't cache the screen->pixels pointer between frames, since the pointer changes every frame when double/triple buffering. When your frame is done, call SDL_Flip(), which does the right thing in every mode.

Quote from: hi-ban on September 25, 2014, 02:41:41 am

Code: [Select]

X-OD-NeedsDownscaling=true

What exactly do these settings do? Set environment variables? Most of the time during development I am not running from an .OPK file; how else can this hint be set?

You can set it via sysfs:

echo 1 > /sys/devices/platform/jz-lcd.0/allow_downscaling
Use this only during development, not in production, as this path could change in the future.

Code: [Select]

echo 1 > /sys/devices/platform/jz-lcd.0/allow_downscaling

Thanks for this, I had the same issue whilst testing 640x480 screens.

Are there any plans to allow 800x600 downscaling? I noticed whilst testing it doesn't seem to downscale properly. It would be useful when HDMI is supported.

Are there any plans to allow 800x600 downscaling? I noticed whilst testing it doesn't seem to downscale properly. It would be useful when HDMI is supported.

For now, the max resolution is set to 640x480, like Nebuleon said. We are planning to migrate the video driver from the old Linux framebuffer interface to the modern KMS/DRM interface. After that migration, we might add more resolutions.

Note that in the Linux kernel, DRM means Direct Rendering Manager; it has nothing to do with restricting your access

By the way, to all those involved with the IPU scaling code, it's pretty awesome.

I've started implementing in my project and the results are brilliant.

Just from a technical point of view, does the GCW-Zero need to convert this to something like YUV420 or is it doing RGB scaling? The A320 has IPU scaling but required the source video be in YUV which isn't super awesome for most applications.

By the way, to all those involved with the IPU scaling code, it's pretty awesome.

I'm glad you like it It took 6 months of work.

Basically the hardware can convert everything to everything 
We only support RGB565 / RGB888 for now, but we will eventually support more (YUV, RBG/BRG/BGR/GRB/GBR and RGB555 to RGB).
Also, currently we only have bilinear filtering implemented, while the hardware can do bicubic (bilinear is better for downscaling, bicubic is better for upscaling).

Note that the IPU uploads the converted image directly to the LCD converter: the converted image is not written to RAM, which means that scaling is absolutely free performance-wise.

I don't think it does, at least as a transformation you can request inline with resizing. And you couldn't implement it with hacks either, because the IPU's memory accesses are pretty dumb.

The framebuffer is stored a certain way (all pixels in a line, stored packed; repeat for all rows); the IPU reads from the memory in that way (32-byte bursts read from RAM, which reads 16 RGB 565 or 8 RGB 888 pixels from the same row); the IPU also stores that same way to the LCD (await the next horizontal refresh, write a line, repeat for all lines).

So rotation is done in software, and it's rather efficient, I'd say!

Simply read rows (from your intermediate buffer) one at a time and write the pixels as a column (to the framebuffer). Reading a source row in RGB 888 (240x320) will be 960 bytes, so 30 cache lines filled for one row. Writing the pixels as a column (320x240) will load a cache line from each target row for the purpose of modifying them with one pixel each, so 240 cache lines filled for the next 8 columns.

That turns out to be 270 * 32 = 8640 cache bytes used concurrently at any point, out of 16384 for the L1 data cache, so you don't thrash the L1 cache or access L2 while rotating (OK).
Reading each row will be 1800 cycles RAM access, then writing the columns will be 14400 cycles RAM access for every 8 columns, then 240 cycles for the next 7 due to the 7 next columns being in the same cache lines that were already loaded.
So you get a rotation time of 1,058,400 cycles per frame, which is 6% CPU usage (63.5 MHz).

[Divide by 2 if you want RGB 565, so 3% CPU usage (31.75 MHz).]

The IPU might do palette conversions, but I don't know if it can read 8-bit input and use lookup tables to map them to colors.

As for the technical information, it's under NDA, so I'm not sure if I can discuss it more than what I've observed of its behavior that was not in documentation. Of course, you can look at the source for our Linux repository

I'm not sure what INS/EXT would be useful for, that ANDI/SRL wouldn't also be useful for...
; register assignments:
; $4: input pixel pointer
; $5: output pixel pointer
; $6: input line pitch in bytes
; $7: output line pitch in bytes
; $8-$15: free to use by the algorithm
  LW    $8,  0($4)        ; read two pixels at once, first pixel = LSB because little-endian
  ANDI  $9,  $8,  0xFFFF  ; extract LSB pixel
  SRL   $10, $8,  16      ; extract MSB pixel
  SH    $9,  0($5)        ; write LSB pixel to the current row
  ADDU  $5,  $5,  $7
  SH    $10, 0($5)        ; write MSB pixel to the next row
But I was just thinking straight LH/SH (or LW/SW for RGB 888), maybe with some overlapping to read 8 pixels into registers then write the 8 registers to 8 rows.

Yeah, so you'll need to do rotation and palette lookups in software, but you don't need to deal with including a generic bilinear scaler among all that.

I'm glad we could help

Oh, you could also use a shader for the rotation and palette lookup.