Dingoonity.org

GCW Zero => Development => Topic started by: slaanesh on September 25, 2014, 02:12:10 am

Title: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on September 25, 2014, 02:12:10 am
I'm close to release an updated version of MAME for the GCW-Zero.

As an option, I want to support hardware screen scaling using the IPU. This would be very useful for MAME given the multitude of different resolutions that various games use.

Anyway, how exactly is the IPU screen scaling implemented?

From the http://www.gcw-zero.com/updates (http://www.gcw-zero.com/updates):

Quote
Applications can be modified to request resolutions smaller than 320x240, which will then be scaled up in hardware. This can allow for example some emulators to run a bit faster. By default, scaling will preserve the aspect ratio, but if you prefer to have no black borders even if that means distorting the image, you can switch modes using Power+A.

Applications can also set the key X-OD-NeedsDownscaling=true in their OPK metadata to request the use of resolutions higher than 320x240 which are then downscaled to 320x240. This can help in porting PC applications that need for example 640x480 output resolution. For applications that can render in either low (320x240 or below) or high resolution, we suggest to not set this key and render in low resolution, since outputting fewer pixels is better for performance and battery life.

This is a nice description and exactly what I would like to use but I can't find any implementation details.

Are we talking SDL function calls here?
ie.
Code: [Select]
surface = SDL_SetVideoMode(width, height,depth, mode_flag);
Or kernel function calls? Is there example code using the scaler?

                                                                               

EDIT: Isn't it always the way, you find the info a few minutes after posting a question?

http://boards.dingoonity.org/gcw-releases/opendingux-update-2014-08-20/msg111587/#msg111587 (http://boards.dingoonity.org/gcw-releases/opendingux-update-2014-08-20/msg111587/#msg111587)

Now if only the IPU could do rotations as well, that would be awesome! But scaling is harder/time consuming so this is a very nice addition.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: hi-ban on September 25, 2014, 02:41:41 am
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:

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

Code: [Select]
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:

Code: [Select]
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:

Code: [Select]
X-OD-NeedsDownscaling=true
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on September 25, 2014, 03:16:19 am
Thanks for the quick and comprehensive answer.

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?

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?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: mth on September 25, 2014, 03:43:27 am
Thanks for the quick and comprehensive answer.

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:

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 (https://github.com/Nebuleon/fba-sdl/commit/27343bc) 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.

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:

Code: [Select]
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.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on September 25, 2014, 03:49:26 am
Thanks to mth, hi-ban and Nebuleon (from a PM).

Excellent information and my questions are all answered.

This kind of stuff should be in the GCW-Zero Development Wiki.

Slightly off-topic, If HDMI output could be realized soon, the GCW-Zero would certainly give Raspberry Pi a run for it's money. The reason I mention this is I've been experimenting with HDMI output on the PI and DispmanX scaler/rotater using gles2.

I prefer the GCW-Zero, but I do love the easy connectivity of the Raspberry Pi with its standard, HDMI, 4x USB and Ethernet.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: David Knight on September 25, 2014, 08:29:57 pm

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.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Nebuleon on September 25, 2014, 10:55:33 pm
<1 level of quote nesting omitted ~Nebuleon>

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.
That is a current limitation of the framebuffer. Its maximum resolution is 640x480 in 2014-08-20 firmware.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: mth on September 26, 2014, 05:56:32 pm
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 ;)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Nebuleon on September 27, 2014, 09:17:55 am
We've gone ahead and documented hardware scaling here: http://wiki.gcw-zero.com/Hardware_Scaling

There's also a page (http://wiki.gcw-zero.com/Triple_Buffering) about triple buffering.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 09, 2014, 07:13:14 am
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.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Nebuleon on October 09, 2014, 07:40:32 am
It's RGB to RGB scaling. The JZ4770 also inherits YUV to RGB scaling from the JZ4740 of course, but it's not implemented on the GCW Zero.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on October 09, 2014, 08:04:06 am
By the way, to all those involved with the IPU scaling code, it's pretty awesome.
I'm glad you like it :D It took 6 months of work.

Basically the hardware can convert everything to everything  ;D
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.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 10, 2014, 01:11:35 am
Well great job, I'm impressed as it is working very well AND is very fast with good quality results.

For me RGB565 and RGB888 support is all my application needs at the moment so I'm covered. I was only curious about YUV as it was the only way the jz4740 did scaling, which like I already said isn't very useful most of the time.

One more question, can the IPU do 90/180/270 degree rotations?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Nebuleon on October 10, 2014, 01:39:08 am
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).]
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 10, 2014, 01:59:21 am
Thanks Nebuleon, so it should be fairly quick.
I have a basic "C" based blitter that will do 90/180/270 degree blits already but an optimized assembler blitter would be beneficial here. I see good use of the MIPS32r2 INS/EXT instructions here!

One more IPU question - can it do palette conversions?
ie. 8-bit palette framebuffer (ie. each pixel represent by a byte) converted to RGB565 or RGB888?

By the way where are you guys getting your technical information in regards to the IPU?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Nebuleon on October 10, 2014, 02:33:07 am
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...
Code: [Select]
; 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.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 10, 2014, 02:58:35 am
Here is a list of what my application's blitter needs to handle:


So you end up with a blitter that is anything but straight forward as there are many cases it needs to handle.
A generic blitter that handles all cases all the time is too slow.

So to optimize, I have various blitters that do some or all of the transformations required. The application selects the blitter which is most suitable for the job.

To have the IPU handle scaling is a huge benefit as it's probably the most CPU intensive of all the aspects of the blitter.
Rotation is probably the next biggest, followed by the palette lookups.

Most of the time I am dealing with 16-bit pixels so I thought could read 32-bits (two pixels) and write each pixel with INS. Which saves one read operation. This is ignoring palette lookups though.

Anyway I'll sort something out.


Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Nebuleon on October 10, 2014, 03:02:30 am
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 :)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on October 10, 2014, 07:38:16 am
The IPU does not handle rotation nor palette lookup. The 2D core of the GPU might... But we have no driver for it.

Slaanesh, writing assembly routines is an ARM thing. The MIPS architecture is simpler, and GCC generally does a very good job at optimizing.

Technical information is available on Ingenic's FTP, IIRC.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on October 10, 2014, 07:40:21 am
Oh, you could also use a shader for the rotation and palette lookup.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: mth on October 10, 2014, 12:57:03 pm
While the JZ4770 documentation is currently not publicly available, the JZ4780 documentation (http://elinux.org/CI20_Hardware#Programmers_Manual) is and the IPU most likely didn't change all that much.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 13, 2014, 03:28:48 am
Are multiple calls to SDL_SetVideoMode() with different resolutions honored?

For example, if there is an initial call of:

Code: [Select]
SDL_SetVideoMode(400, 300, 16, SDL_HWSURFACE|SDL_TRIPLEBUF);
and then later:

Code: [Select]
SDL_SetVideoMode(392, 300, 16, SDL_HWSURFACE|SDL_TRIPLEBUF);
will the IPU handle the change in resolution?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: hi-ban on October 13, 2014, 03:45:06 am
Are multiple calls to SDL_SetVideoMode() with different resolutions honored?

For example, if there is an initial call of:

Code: [Select]
SDL_SetVideoMode(400, 300, 16, SDL_HWSURFACE|SDL_TRIPLEBUF);
and then later:

Code: [Select]
SDL_SetVideoMode(392, 300, 16, SDL_HWSURFACE|SDL_TRIPLEBUF);
will the IPU handle the change in resolution?

Yes, every time you change the resolution, the IPU will scale it accordingly. For example, Pocketsnes uses 320x240 in menu, but (if scaler is set to hardware) automatically changes the resolution to 256x224 (or 256x240 for some PAL games) when going to the game. And, of course, when calling the menu, it changes the resolution again to 320x240.

You could make a game which changes its resolution every second, and the IPU would handle it.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 13, 2014, 03:46:30 am
Ok thanks.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: hi-ban on October 13, 2014, 04:10:40 am
However, if you set a resolution to be, lets say, 256x224 you shouldn't copy more than 256x224 pixels to the screen surface when using the IPU, because the app will probably crash.

When adding IPU support to Pocketsnes, it always crashed with some specific PAL games, which we later realised they were the ones which the emulator outputted as 256x239. The cause was that the resolution we were setting when using the IPU was always 256x224, so in those PAL games, 15 extra lines were copied to the screen, corrupting nearby memory.

The first attempts to fix those crashes didn't work because we were changing the resolution one frame late. But fortunately, Nebuleon managed to somehow make it change the resolution in the right frame.

Of course, copying a smaller image works ok.
You can also play with resolutions to achieve different scaling effects. For example, if you want to do horizontal scaling only, you can request a screen height of 240 and that way the height wont be scaled. (you need to turn off the aspect ratio preserving for this)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 13, 2014, 09:37:14 pm
Oh, you could also use a shader for the rotation and palette lookup.

Yes, the Raspberry PI implements GL and have found examples of how to do rotation and scaling using a combination of DispmanX and GLES2. I've ported my application to it and it runs... okay... The GCW-Zero seems *much* faster than Raspberry Pi - true given the relative CPU speeds but even with the PI overclocked and using assembler CPU cores it's substantially slower.

So it seems that the GCW-Zero has the pretty much the same set of libraries that the Pi has for GLES2, I wonder if that would provide an alternate approach to scaling and rotation?

Also, back to the IPU scaling, are there any issues with odd resolutions, say, 395x253? Does it round up/down? If so do I need to compensate for it?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Nebuleon on October 13, 2014, 09:51:32 pm
<1 level of nested quoting omitted, and the part of the post about OpenGL ~Nebuleon>
Also, back to the IPU scaling, are there any issues with odd resolutions, say, 395x253? Does it round up/down? If so do I need to compensate for it?
You can request 395x253, and if the user makes a screenshot of that, it'll also be 395x253. But for display, the driver may do adjustments transparently. See http://wiki.gcw-zero.com/Hardware_Scaling#Limitations .

I'm not exactly qualified to answer about OpenGL, so I'll leave that part up to others.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on October 13, 2014, 10:09:08 pm
Some resolutions are indeed problematic. When scaling with a ratio of X:Y, X must be < 32 if upscaling, and Y must be < 32 if downscaling. But typically you will never run into this, unless you want say 319x239. In that case, the driver will return a higher resolution that works (in this case, 320x240). But SDL will detect that and center the image accordingly so that it will always work.

About the GLES shader, doing scaling there would not be useful. The IPU can scale the output of the GPU, too.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 13, 2014, 11:56:12 pm
So I don't need to compensate for any padding?

if I request a horizontal resolution of say 395, I can just write 395 pixels per line?

ie. from my previous example, using 253 lines, I would write in total 395x253xsizeof(short) bytes and it should be fine?

Currently, using the IPU for scaling for 395x253 and 392x253 I don't get "square" images, they look shifted by a few pixels each row.
When I use my software scaler, these work fine.

But it could still be something I am doing wrong, I'm still investigating. I just wanted to narrow down where the issue is.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Nebuleon on October 14, 2014, 12:17:59 am
a) if I request a horizontal resolution of say 395, I can just write 395 pixels per line?

ie. from my previous example, using 253 lines, I would write in total 395x253xsizeof(short) bytes and it should be fine?

b) Currently, using the IPU for scaling for 395x253 and 392x253 I don't get "square" images, they look shifted by a few pixels each row.
When I use my software scaler, these work fine.

But it could still be something I am doing wrong, I'm still investigating. I just wanted to narrow down where the issue is.
a) Yes.

b) According to http://wiki.gcw-zero.com/Hardware_Scaling#Limitations

320/395 => 64/79. The denominator of the scaling fraction is larger than 32, so the IPU has to adjust it so you have at least 395 pixels in the source and the denominator is 32 or less. It must use 25.92405/32 as a starting point, which becomes 25/32. The new source width is 410.
240/253 => 240/253. The fraction is irreducible, and its denominator is larger than 32. It must use 30.35573/32 as a starting point, which becomes 30/32. The new source width is 256.

Your image, 395x253, is in the middle of a 410x256 image that gets resized to 320x240. You need to make sure that you handle the case where 395 * sizeof(uint16_t) is not necessarily the line pitch, which you get with SDL_Surface.pitch, though. In this case, the next line is not 395 * sizeof(uint16_t) away, but 410 * sizeof(uint16_t).
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 14, 2014, 12:50:47 am
Thanks, got it! Now i've got rid of the wobbles and the IPU is scaling nicely again.

I didn't realize that I had to vary the pitch which may not be entirely clear. It's working now, weird resolutions are now all good.

Nice playable speeds too, thanks to the IPU hardware removing the burden of software scaling for these games.

Thanks Nebuleon for your help, I think that example would be good for the Wiki.
The current simple case example there is great if you have "IPU friendly" resolutions but if you have difficult ones, some extra info would good.

And thanks again for the work on the IPU hardware... it really is a super effort! It couldn't be easier to use and integrated really well into SDL (and the kernel I would think). Thumbs up all round. ;D
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 20, 2014, 06:06:00 am
Sorry guys, I've found a bug in the IPU Scaler. I've got the latest firmware.

Here's the test case:

Makefile
Code: [Select]
TOOLCHAIN = /opt/gcw0-toolchain/usr
CC = $(TOOLCHAIN)/bin/mipsel-linux-gcc
LD = $(TOOLCHAIN)/bin/mipsel-linux-gcc

LIBS = -lSDL -lpthread -lm -lgcc
LIB_PATH  = $(TOOLCHAIN)/lib

W_OPTS = -Wall -Wno-write-strings -Wno-sign-compare

F_OPTS =-falign-functions -falign-loops -falign-labels -falign-jumps \
    -ffast-math -fsingle-precision-constant -funsafe-math-optimizations \
    -fomit-frame-pointer -fno-builtin -fno-exceptions -fno-common \
    -fstrict-aliasing  -fexpensive-optimizations -fno-pic \
    -finline -finline-functions -fmerge-all-constants \
    -ftree-vectorize -fweb -frename-registers -ggdb

CFLAGS = -DGCW0 -pipe -O2 -march=mips32r2 -mtune=mips32r2 -mhard-float -mno-mips16 $(W_OPTS) $(F_OPTS)

LDFLAGS = $(CFLAGS) -L$(LIB_PATH) $(LIBS) -s

all: test_ipu

test_ipu: test_ipu.o
        $(LD) $(LDFLAGS) $< -o [email protected]

test_ipu.o: test_ipu.c
        $(CC) $(CFLAGS) -c $< -o [email protected]

clean: test_ipu
        @rm -f test_ipu test_ipu.o

Test program: test_ipu.c

Code: [Select]
#include <SDL/SDL.h>

int main(int argc, char **argv)
{
        int width = 410;
        int height = 256;
        SDL_Surface  *Surface;
        SDL_Init(SDL_INIT_VIDEO);
        printf("SDL_SetVideoMode(%d, %d, 16, SDL_TRIPLEBUF | SDL_HWSURFACE | SDL_FULLSCREEN );\n", width, height);

        Surface = SDL_SetVideoMode(width, height, 16, SDL_TRIPLEBUF | SDL_HWSURFACE | SDL_FULLSCREEN );

        printf("Success: Pitch=%d\n", Surface->pitch);

        SDL_Quit();

}

Those parameters cause the GCW-Zero to die...

I run the following to switch on IPU hardware:

Code: [Select]
opendingux:/media/data/local/share/test # cat full.sh
#!/bin/sh

echo "Setting allow_downscaling for IPU"

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


opendingux:/media/data/local/share/test # ./test_ipu

Screen fades white and GCW0 reboots.

Other width values will work. ie 400 works but 410 seems to be bad. Maybe others are bad too.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on October 20, 2014, 09:14:41 am
The ratio is 41:31, and 41 > 32.
The algorithm doesn't handle the case where the numerator is a prime number, I think...
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 20, 2014, 12:28:17 pm
How can we go about fixing this issue?
Obviously it shouldn't crash like it does.

Who needs to know about this bug?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on October 20, 2014, 03:06:22 pm
Who needs to know about this bug?
Just me ;)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 20, 2014, 09:39:42 pm
Can't play Smash TV on Mame 0.84 with IPU hardware scaling without it fixed! :)

If you create a fix, can you let me know so I can test it?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: hi-ban on October 20, 2014, 10:08:42 pm
until (if) that is fixed, you might have to use the next working resolution (420, i think). It will not be completely fullscreen , it will have some very tiny black bars (2 or 3 pixels) but it should work.
(http://i.imgur.com/GtSFeog.png)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Gab1975 on October 20, 2014, 10:16:07 pm
If I'm not wrong, "Smash TV" should be the only Midway/Williams "TMS34010" coin-op with horizontal resolution of 410 pixels, the other games (like Judge Dredd, Mortal Kombat, NBA Jam, Total Carnage, Trog, etc.) should have a horizontal resolution of about 396-400 pixels.
I'm looking forward to see how the GCW Zero is able to emulate these games! ;) 
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 20, 2014, 11:28:48 pm
If I'm not wrong, "Smash TV" should be the only Midway/Williams "TMS34010" coin-op with horizontal resolution of 410 pixels, the other games (like Judge Dredd, Mortal Kombat, NBA Jam, Total Carnage, Trog, etc.) should have a horizontal resolution of about 396-400 pixels.
I'm looking forward to see how the GCW Zero is able to emulate these games! ;)

Correct!

Smash TV is one of my standard testing games - because of it's unusual resolution, fairly demanding on the host system and of course is fun to play :)

Smash TV on Mame 0.37b16 used to have a resolution of 396 pixels and works with the IPU scaler no problems. It runs at full speed w/ zero frameskip and most importantly looks and plays great!
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Gab1975 on October 21, 2014, 06:29:08 am
Smash TV on Mame 0.37b16 used to have a resolution of 396 pixels and works with the IPU scaler no problems. It runs at full speed w/ zero frameskip and most importantly looks and plays great!

Your forthcoming release promises to be really interesting! ;)

I'm curious (I hope you can give us a "little spoiler" ! :P )... are you making three different MAME4all(s) or a single release which supports three different ROMsets (37b16, 0.66 and 0.84) ?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on October 21, 2014, 06:41:12 am
I'm curious (I hope you can give us a "little spoiler" ! :P )... are you making three different MAME4all(s) or a single release which supports three different ROMsets (37b16, 0.66 and 0.84) ?

Yes, one release.

There will be a single frontend, which lets you select which version of MAME you want to use, initially the three versions you mentioned will be available.

New versions of MAME will be easily added if desired, perhaps some even later versions.

The new frontend has screen shot and favorites support as well as being able to filter games.

I'm just adding IPU hardware scaling support which certainly helps for games that have different resolutions to the GCW-Zero's native 320x240.

My current favorite is "xexex" - an awesome shooter by Konami!

It's a great game for testing as it really pushes the hardware as it has unusual video mode and resolution but it's a great game!

On top of that I'm making versions for Pandora and Raspberry Pi - so pretty busy.
The Pandora version is looking pretty awesome as well so far as it has very capable hardware.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Gab1975 on October 21, 2014, 07:26:01 am
I'm looking forward to see your release! ;)

PS: I'm also curious to see how the GCW Zero "is doing" with the emulation of SEGA System32 games!
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: glimmer on October 26, 2014, 06:35:44 pm
Yes, one release.

There will be a single frontend, which lets you select which version of MAME you want to use, initially the three versions you mentioned will be available.

New versions of MAME will be easily added if desired, perhaps some even later versions.

The new frontend has screen shot and favorites support as well as being able to filter games.

I'm just adding IPU hardware scaling support which certainly helps for games that have different resolutions to the GCW-Zero's native 320x240.

My current favorite is "xexex" - an awesome shooter by Konami!

It's a great game for testing as it really pushes the hardware as it has unusual video mode and resolution but it's a great game!

On top of that I'm making versions for Pandora and Raspberry Pi - so pretty busy.
The Pandora version is looking pretty awesome as well so far as it has very capable hardware.
Not sure if you're taking volunteers for testing on the Zero, but if you are, count me in. ;)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: eltehero on November 08, 2014, 11:38:51 am
I'm curious (I hope you can give us a "little spoiler" ! :P )... are you making three different MAME4all(s) or a single release which supports three different ROMsets (37b16, 0.66 and 0.84) ?

Yes, one release.

There will be a single frontend, which lets you select which version of MAME you want to use, initially the three versions you mentioned will be available.

New versions of MAME will be easily added if desired, perhaps some even later versions.

The new frontend has screen shot and favorites support as well as being able to filter games.

I'm just adding IPU hardware scaling support which certainly helps for games that have different resolutions to the GCW-Zero's native 320x240.

My current favorite is "xexex" - an awesome shooter by Konami!

It's a great game for testing as it really pushes the hardware as it has unusual video mode and resolution but it's a great game!

On top of that I'm making versions for Pandora and Raspberry Pi - so pretty busy.
The Pandora version is looking pretty awesome as well so far as it has very capable hardware.

Slaanesh, many thanks for the incredible mame support on GCW Zero. Can we expect a Christmas release of this new version?

Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on November 08, 2014, 12:17:49 pm
Yes certainly before that :)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: TimeDevouncer on November 08, 2014, 09:38:11 pm
Yes certainly before that :)

(https://lh6.googleusercontent.com/_YYiIFWwXHDw/Tc-FAtKkbbI/AAAAAAAAANA/R9rs6CdeVqk/s800/dancinron.gif)
 :-*
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Inertia on November 11, 2014, 10:30:31 am
Can't Wait :)

THANK YOU SLAANESH ! :)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on December 11, 2014, 02:22:54 am
On track for a before-Christmas release! :)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: howie_k on December 11, 2014, 07:41:34 am
That is great news!
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on December 12, 2014, 02:01:33 pm
I'll try to fix the bug you reported before Christmas then.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on December 12, 2014, 09:45:02 pm
Make sure y'all have the triple buffer firmware installed ie.latest firmware
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: surfi80 on December 18, 2014, 05:17:52 pm
On track for a before-Christmas release! :)
Yes certainly before that :)

(http://i943.photobucket.com/albums/ad279/rocklee_san/adplus%20Kosaka%20Tamaki/Danboard/18/BarneyStinsonMindExplosionGif.gif)
I'm excited companion to play Alligator Hunt
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on December 23, 2014, 12:03:22 am
Alligator Hunt should work, use the "unprotected" version.

Okay I've finally got a preliminary .OPK installer so will test this tonight.

Its' going to be close. May even be end up being "Christmas Day" :)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: surfi80 on December 23, 2014, 06:22:13 am
Alligator Hunt should work, use the "unprotected" version.

Okay I've finally got a preliminary .OPK installer so will test this tonight.

Its' going to be close. May even be end up being "Christmas Day" :)

that's a big big news ;D
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Gab1975 on December 23, 2014, 06:44:35 am
Okay I've finally got a preliminary .OPK installer so will test this tonight.

Its' going to be close. May even be end up being "Christmas Day" :)

The wait is about to end... thanks! :)

PS: ... and I hope that a GCW Zero version of Temper 0.81 will be out soon... I'm a "fussy child" ! :P
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: surfi80 on December 28, 2014, 12:43:31 pm
@slaanesh as you take the project?
I burn with impatience  :P :P :P :P :P :P :P :P :P :P :P :P :P :P :P :P :P :P
(http://gifsanimados.de/img-gifsanimados.de/y/yoshi/yoshi.gif)
Title: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on December 28, 2014, 01:17:34 pm
Almost there very close.... Trust me...
Some things taking longer of course.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: surfi80 on December 30, 2014, 06:16:23 am
I already know I'm a heavy, but the cravings dominate me .... ;D

how you doing? :o
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on December 30, 2014, 10:43:49 am
Tomorrow it will be released!
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: surfi80 on December 30, 2014, 11:51:15 am
Yiiiiiihaaaaa
(http://img.pandawhale.com/66350-America-Fuck-Yeah-gif-Colbert-wIcN.gif)

many thanks !! colleague you got me tomorrow like a nail, attentive to everything lol
(http://statics.memedeportes.com/mmds/2014/04/MMD_291828_gif_asi_estamos_todos_que_empiece_la_champions_ya.gif)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: Gab1975 on December 30, 2014, 01:22:24 pm
Tomorrow it will be released!

Thanks... a very good news! ;) Tomorrow will be an excellent new year's eve! ;)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: hi-ban on December 30, 2014, 08:23:08 pm
slaanesh, i suppose you are aware of the guidelines for getting an app hosted in the repo.

I saw your last MAME release for the Dingoo, and i noticed it was bundled with preview images of all games.
For the GCW, i'd recommend to make it optional to add previews into the home directory folder ($HOME/.mame4all/previews/ or whatever the mame4all directory is) and then have the previews as a separate download.

That way, the opk file will be much smaller and there wont be any problems with copyrighted stuff.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: surfi80 on December 30, 2014, 10:05:03 pm
Comrade is right, I already have the images ready
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on January 12, 2015, 04:47:46 am
Okay it's released.

Any chance of a kernel update to fix the screen-scaling issues?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on January 15, 2015, 11:50:38 pm
Also... I'm not sure how the scaling is implemented BUT would a "viewport" mode be doable?

ie.

* Define an arbitrary resolution (like already supported) surface but with options to be larger than the current max (640x480), say up to HD (this will need to happen for HDMI out anyway).
* Define a viewport (or window) on surface: an (X,Y) co-ordinate and width/height or maybe a rectangular box.
* Only the viewport is displayed, the "borders" are clipped.

Like the accelerated version of the Open Pandora's SDL. See the SDL_OMAP_BORDER_CUT mode:
http://notaz.gp2x.de/cgi-bin/gitweb.cgi?p=sdl_omap.git;a=blob;f=README.OMAP;hb=HEAD (http://notaz.gp2x.de/cgi-bin/gitweb.cgi?p=sdl_omap.git;a=blob;f=README.OMAP;hb=HEAD)

 
Also, I think the way that the scaling options using env variables makes sense. Perhaps the GCW-Zero implementation should be the same instead of using system files to determine functionality.

Anyway it's just a suggestion and understand totally if it's not going to change at all :)
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on January 16, 2015, 08:54:11 am
In theory it would be possible; you could request a large framebuffer from the video driver and only use a portion of it.
But SDL is clearly not designed for that so you would need to change the API.

What "system files" are you talking about?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on January 16, 2015, 08:57:25 am
In theory it would be possible; you could request a large framebuffer from the video driver and only use a portion of it.
But SDL is clearly not designed for that so you would need to change the API.

What "system files" are you talking about?

Like "/sys/devices/platform/jz-lcd.0/allow_downscaling" to activate re-scaling.

Have a look at the link above to see how the Pandora's SDL enhancements have been implemented. It's a fairly tidy way of doing it.

The viewport mode for the Pandora is done by setting SDL_OMAP_BORDER_CUT.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on January 16, 2015, 09:01:47 am
Well you're not supposed to touch those files directly. Instead, use X-OD-NeedsDownscaling=true in your OPK's metadata.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on January 16, 2015, 09:04:49 am
Well you're not supposed to touch those files directly. Instead, use X-OD-NeedsDownscaling=true in your OPK's metadata.
I'm touching them in my apps :)

I don't understand why the OPK is supposed to activate these through their metadata?
Shouldn't they be user controlled options via user programs? ie like env variables?

Reason being is that during development I don't use the OPKs at all, I'm ssh running a shell to test.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on January 16, 2015, 11:34:39 am
There is no point for an application to write the "/sys/devices/platform/jz-lcd.0/allow_downscaling" file. Either your program needs downscaling, or it does not; and this is not something that changes at runtime.

This is different for "/sys/devices/platform/jz-lcd.0/keep_aspect_ratio". It is possible to toggle between fullscreen and apect ratio using the combo Power+A, but some applications might want to have a menu option for that. Then it's fine to read/write the file, as long as you handle errors and don't crash/segfault if the file doesn't exist.

This cannot be done using environment variables, because then it would be specific to SDL1 applications, and you would have to re-set the video mode for the setting to be applied.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on January 16, 2015, 10:22:49 pm
Ok, IPU bug squashed (I think).
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on January 16, 2015, 10:23:45 pm
Ok, IPU bug squashed (I think).
Is it a library update or a new kernel?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on January 16, 2015, 10:36:38 pm
New kernel.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on February 03, 2015, 01:03:11 am
Whilst we're at it, any chance of increasing the resolution limitation?

Some MAME games need more than 640x480. Outrunners is one, it needs 832x448.

Why not just go with HD resolution ie 1920x1080 as it would need to support that for HDMI output anyway?
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on February 03, 2015, 09:24:21 am
We set the max to 640x480 because above that limit software rendering is very slow.
Later I tried to increase that limit to 800x600 but the kernel wouldn't boot. I guess we will try to increase that limit again when we have HDMI. But first we have to rewrite the entire video driver.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: slaanesh on February 04, 2015, 10:41:09 pm
We set the max to 640x480 because above that limit software rendering is very slow.
Later I tried to increase that limit to 800x600 but the kernel wouldn't boot. I guess we will try to increase that limit again when we have HDMI. But first we have to rewrite the entire video driver.

What do you mean it's slow? The speed would be the same, just the time taken to do the work would scale proportionally to the number of pixels being shifted.
Title: Re: GCW-Zero IPU screen scaling implementation
Post by: pcercuei on February 05, 2015, 11:24:28 am
I mean that the time required to render 320x240 = 76k pixels in software is four times less than the time needed to render 640x480 = 307k pixels, and an order of magnitude less than to render 1920x1080 = 2074k pixels.

We may enable high resolutions at some point but they will only be useful to the applications that use the GPU.