Scaler

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Wed Nov 07, 2018 8:15 pm

VIP Scaler has no such shifting on old coeff_nn. That's OK. I've removed this bug report.
Since this scaler is already close to the stage when it can replace VIP scaler, i've started to work on closer integration.
I believe Grabulosaure will fix remained bugs soon.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Thu Nov 08, 2018 5:40 pm

i've just tried to make a input video (to scaler) 1 pixel wider - and got the same problem on 321x224 video as on 256x224 as i've posted earlier.
So, it seems not overflow. Scaler doesn't like some input widths.

GreyRogue
Atari maniac
Atari maniac
Posts: 88
Joined: Thu Mar 22, 2018 3:50 am

Re: Scaler

Postby GreyRogue » Mon Nov 12, 2018 5:34 am

Sorgelig wrote:Something completely wrong with scaling happens when output resolution is 1920x1080 and input resolution is 256x224 (240p Suite test pattern, or for example game Clue). Large portion on the left has copy from the middle. Probably some overflow happens inside.
20181107_180831.jpg

Ok. I think I found the issue with 16x9 in 1920x1080. There are only 1920 displayed pixels, but this:

Code: Select all

reg  [11:0] WIDTH  = 1920;
reg  [11:0] HFP    = 88;
reg  [11:0] HS     = 48;
reg  [11:0] HBP    = 148;

means there are actually 2204 elements in the line. The OHRES value is currently maxed at 2048, so you're getting wrapping.
Testing with 4096 seems to work, but maybe it's possible to use something smaller to not waste as many resources. Not sure if it's needed or not. The instructions require power of 2, but maybe you can tell the parts that care that there are 4096, but only reserve the 2204 resources that are actually going to be used.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Mon Nov 12, 2018 9:05 am

GreyRogue wrote:The OHRES value is currently maxed at 2048, so you're getting wrapping.
Testing with 4096 seems to work, but maybe it's possible to use something smaller to not waste as many resources. Not sure if it's needed or not. The instructions require power of 2, but maybe you can tell the parts that care that there are 4096, but only reserve the 2204 resources that are actually going to be used.

thanks for info!
I've fixed issue in my repo. Now OHRES is not required to be a power of 2. Scaler is made as universal but in practice resolutions higher than 1920x1080 aren't reachable due to high pixel clock. In VIP scaler even 1920x1080 directly unreachable on Cyclone V. I had to use 2 parallel pixel processing, so clock is twice lower 74.25MHz. Actual FullHD pixel clock is used only on very last stage.
So, ascal working on 148.5MHz is already surpassing the VIP scaler performance. But at the same time it makes me worry about usage it in different cores as it may become unstable. With vsync_adjust and FulHD resolution sometimes pixel clock goes very high. For example ao486 in text mode produces 70Hz video which together with vsync_adjust converted to about 180MHz pixel clock! This is a big question will ascal survive this. VIP scaler working on a half pixel clock has a solid margin before it gets unstable.
It's just my thoughts - it's not stopping feature. At last, i can(i think) modify ao486 VGA timings to output lower framerate.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Mon Nov 12, 2018 9:19 am

btw, I didn't understand how interlaced mode should work in this scaler.
The test game is Sonic 2, VS mode. Lines are flickering even if there is no movements. So just static pic is flickering.

Grabulosaure
Atari User
Atari User
Posts: 36
Joined: Tue Sep 05, 2017 9:35 pm
Contact:

Re: Scaler

Postby Grabulosaure » Mon Nov 12, 2018 8:44 pm

I''ve just posted a new version.

Many fixes, many changes.

* Framebuffer size is a now constant
* Packed pixels.
* More pipelining for fewer timing violations.
* Optional image properties header
* Optional low latency synchronized mode (experimental)

Known issues : Borders, downscaling, more timing analysis, optimisation and cleanup, ...

Notes :
- osd.v was changed : Pipelining : Time critical path.
- There is a case typo in the Genesis project: File T80/t80.qip versus "set_global_assignment -name QIP_FILE T80/T80.qip" in Genesis-lite.qsf.
- The low latency mode synchronizes the display of the first line of the output image with the third line of the input image, by delaying the vertical sync. pulse. I don't know if it works on an actual TV.

I hope it can work with 1920 with OHRES set to 2048, as it is used for sizing the line buffers.

Sorgelig wrote:btw, I didn't understand how interlaced mode should work in this scaler.

It didn't work. At all. Was never tested.

Sorgelig wrote:
Grabulosaure wrote:There were some issues with divider ratios, off-by-one errors, draining pipes.

There is other way to make a scaled steps: Instead of calculate fraction step, you can use integers.
For example, input size in 320pix, output is 1920pix:
with every output pixel step, you add 320 to accumulator, and when it becomes more than 1920, switch to a new input pixel and subtract 1920 from accumulator. And so on til the end. The advantage of this method - you are guaranteed to have 0 and max input values on the edges regardless how complex relation between input and output sizes.
Since fraction is used for filters, this will be a problem as fractions are of the output size, not decimal. It can be workarounded in either filters to include recalculation according to current size. Or coefficients can be re-calculated during VBlank on each frame - there should be enough time to re-calc the coefficients without rush.

That's a good idea.
Like fractional synthesizers, Bresenham lines...
I'll try it. It's trivial for vertical, a bit more tricky for horizontal.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Mon Nov 12, 2018 9:33 pm

Grabulosaure wrote:- osd.v was changed : Pipelining : Time critical path.

please use updated osd.v from my latest release. It's reworked especially to minimize time critical paths. If there are still some problems, your changes are welcome.

ijor
Hardware Guru
Hardware Guru
Posts: 3624
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Scaler

Postby ijor » Tue Nov 13, 2018 2:19 am

Grabulosaure wrote:- The low latency mode synchronizes the display of the first line of the output image with the third line of the input image, by delaying the vertical sync. pulse. I don't know if it works on an actual TV.


Any change on the sync timing would make some ill effects on most monitors. But as long as it happens only once during initialization, or when changing resolution, it doesn't matter. And if the input video frame timing is step locked with the output one, the delay should produce changes on the timing, only once.

Care must be taken however on synchronizing this correctly. Otherwise it might produce a single cycle oscillation back and forth. It might not be possible to avoid this with normal synchronization chains. This is a not a meta stability problem. And step locked doesn't mean both clocks are fully synchronous at the cycle level.

Ideally the scaler should implement some allowed sync range. Say, delay to the middle of the third line, and then don't resync again as long as it is still delayed at some point of the third line.

Other possibility is to provide an extra input signal that would disable the delay. Then the core might enable the delay only once, or for a few frames, and then disable it.
Fx Cast: Atari St cycle accurate fpga core

cacophony
Atari maniac
Atari maniac
Posts: 97
Joined: Sun Jul 22, 2018 11:14 pm

Re: Scaler

Postby cacophony » Tue Nov 13, 2018 3:43 am

Grabulosaure wrote:...
* Optional low latency synchronized mode (experimental)
...
- The low latency mode synchronizes the display of the first line of the output image with the third line of the input image, by delaying the vertical sync. pulse. I don't know if it works on an actual TV.


FYI, I tried Genesis-lite.rbf and when I toggle the third OSD scaler menu item from "Normal" to the next option my TV goes black and the HDMI signal is lost. Two other people from discord mentioned they tried as well and got the same issue. If it helps, my setup is currently outputting 1080p/60 to a 4k TV. Thanks for looking into the low latency mode! :D

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Tue Nov 13, 2018 12:48 pm

Grabulosaure wrote:Many fixes, many changes.

- Edges now are much worse. 320pix mode has around 8-10pix of wrapping with inverted colors on the left. Line with garbage on the up.
- 256pix mode bug is still present.
Tested on 1920x1080 HDMI resolution. Even precompiled rbf from your site has the same problems. So, it excludes my misuse.

I don't know why you need to add pixel packing and make the code even more complicated. With fixed 8MB size per frame even 1920x1080 will have around 1.5MB of unused space. So, i see no point to make packing even more tight.
It's of course up to developer, but i would prefer to have lines fixed to addresses (with max 1920 width and 5 pixels per 128bits line stride would have a nice 0x1800 size which is just sum of 2 values in multiplication). It will greatly reduce complexity of internal calculation. You won't need to constrain the line by input burst numbers, so just pre-cache the next burst when it will be nearly empty regardless if it's already end or not as new line will jump to fixed address. Output resolution scanner will stop the line process at the end and command to cache controller to start the new line. And it will be easier to do auto upscale/downscale.

With ability to load coefficients, internal filters are redundant. So i would keep only NN as predefined and user will choose coefficient file according to his preference (i've done it already). So this will make the code cleaner.

Let me summarize the current problems need to be fixed in order to replace VIP scaler:
1) Edges have problems. Basically the previous version was kind of acceptable on this parameter. New version introduces big regression.
2) All possible input resolutions should be supported. Currently some resolutions (like 256pix width) has overflow - it's fixed in my repo, but needs to be integrated into main code.
3) Downscale need to be implemented. It's not a main feature and probably not required to be high quality as downscaling happens in rare occasions. But it still happens, so need to be handled.
4) Interlace support. Some cores like PCEngine, BBC Micro, Genesis, and some other have interlaced output. And the main beneficiary of interlaced modes is Minimig! One of the main MiSTer feature for Minimig is ability to use high definition modes like 1280x720. And all HiDef Minimig modes are interlaced. I don't know if simple mix of lines altering from F0/F1 (you use fl parameter in ascal which is actually f1 as it's flag of field 1) fields will be enough for start. Need to implement at least simple mix and see how it will look.
5) I found strange bug when around 3 upper lines are lagging against the rest of screen. I use tripple buffering, so this should not be happened. Also this tearing is fixed at the same position, so it's not related to difference input/output refresh. Probably scaler prefetches first lines from wrong buffer.

I like the features of this scaler. Especially ability of coefficients loading on the fly. Altera scaler hiccups on this and i couldn't make it reliable. And of course less used resources and faster compilation are big boosts for core development! But without fixing these bugs it's impossible to move to this scaler. Some fancy features like low latency and even header for grabber are undoubtedly great, but only after main features.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Wed Nov 14, 2018 4:35 pm

Playing with loadable coefficients for VIP scaler: The phase is different! My original coeff_nn.txt looks correct, while updated one with tap switch in the middle works incorrectly and shifts the picture.

So, coefficient files for VIP and ascal should be different.

ghogan42
Atari User
Atari User
Posts: 42
Joined: Wed Oct 17, 2018 7:27 pm

Re: Scaler

Postby ghogan42 » Wed Nov 14, 2018 5:58 pm

Sorgelig wrote:Playing with loadable coefficients for VIP scaler: The phase is different! My original coeff_nn.txt looks correct, while updated one with tap switch in the middle works incorrectly and shifts the picture.

So, coefficient files for VIP and ascal should be different.


That's very strange. If you look at pg 190-191 of the VIP doc

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_vip.pdf

It says that:

Phase 0 is centered at tap T1
Phase (N/2) is half way between T1 and T2
Phase (N-1) is just before tap T2

So for a 16 tap filter, the first 8 coefficients should be: 0 128 0 0
and then after that you're closer to T2 and should use: 0 0 128 0

As far as I could tell, my filter coefficients worked identically with both VIP and ASCAL. Except the edges on ASCAL.

If your old coeff_nn.txt was correct (I don't think it is) then your coeff_pp.txt would have to be wrong (I think it is right) because you can easily see that the transition from T1 to T2 in the middle two columns of coeff_pp:

1st row: 0, 128, 0, 0
halh way -8, 72, 72, -8
15th row: 0, 3, 127, -2
Last edited by ghogan42 on Wed Nov 14, 2018 6:57 pm, edited 1 time in total.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Wed Nov 14, 2018 6:27 pm

ghogan42 wrote:If your old coeff_nn.txt was correct (I don't think it is) then your coeff_pp.txt would have to be wrong

Yes, coeff_pp for VIP is actually wrong as picture shifts up/left and makes those edges half-pixel.
i will release updated Genesis soon which will allow manual coefficients loading. Actually i've planed this feature for ascal scaler, but i'm already not sure when it will get enough features to replace VIP. VIP is not so stable for coefficients loading on the fly, so sometimes it misses the loading. But it's more or less ok now.

souldream
Atarian
Atarian
Posts: 1
Joined: Mon Jan 02, 2017 2:35 pm

Re: Scaler

Postby souldream » Wed Nov 14, 2018 6:58 pm

For what it worth ... ( not tested , and my skill in fpga ... :oops: )

https://github.com/skrapi/FPGA-Implemen ... -Filtering

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Wed Nov 14, 2018 7:05 pm

polyphase filter is already implemented in ascal scaler and works pretty much correct.

ghogan42
Atari User
Atari User
Posts: 42
Joined: Wed Oct 17, 2018 7:27 pm

Re: Scaler

Postby ghogan42 » Thu Nov 15, 2018 6:23 am

Sorgelig wrote:
ghogan42 wrote:If your old coeff_nn.txt was correct (I don't think it is) then your coeff_pp.txt would have to be wrong

Yes, coeff_pp for VIP is actually wrong as picture shifts up/left and makes those edges half-pixel.
i will release updated Genesis soon which will allow manual coefficients loading. Actually i've planed this feature for ascal scaler, but i'm already not sure when it will get enough features to replace VIP. VIP is not so stable for coefficients loading on the fly, so sometimes it misses the loading. But it's more or less ok now.


I hope I'm not bothering you about this. But I wasn't sure if the ascal scaler shifted like you said. So I used the nearest neighbor coefficients below:

Code: Select all

# range -128..128
# sum of line must not exceed the range!

# Mearest Neighbor on x-axis and y-axis
# Phase 0 is centered at T1 so this should
# be correct and not have 0.5 pixel offset?

# horizontal coefficients
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0

# vertical coefficients
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0, 128,   0,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0
   0,   0, 128,   0


and I compared the checkerboard chart in 240p test suite with a build from the Genesis core from Nov 6 and then from the 10/31 VIP build that supports coefficient loading. This is from the upper left corner of my 4k display. You can see that there doesn't appear to be any more cut off from the Ascal build in the vertical direction. But there is some more cut-off in the horizontal direction. (I didn't check the newest ascal build because it seems to have too many problems.)

VIP_Ascal_Nearest.jpg


Do you think it is a phase issue? Because I don't think there is a vertical shift. I think it is a horizontal shift only, or maybe a horizontal size problem because I think the aliasing pattern might be different in the horizontal direction.
You do not have the required permissions to view the files attached to this post.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Thu Nov 15, 2018 6:40 am

I use "grid 320x240" in 240p suite which is more suitable for edge cutting.
Also i use 1920x1080 HDMI resolution - this may be important as ascal has different shifts in different resolutions. For me it's clearly visible how both left and up are cut in VIP with second version of coeff_nn.
What i suspect, is that VIP scaler uses 0,0 - 320,224 range inclusive. Not supposed to be 0,0 - 319,223

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Thu Nov 15, 2018 11:01 pm

New releases of Genesis and MiSTer binary support runtime coefficients loading.
Full revision uses VIP scaler while Lite one uses AScal. Both scalers support the same coefficients loading.

coefficients files must be placed to /Filters folder in the root of SD.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Fri Nov 16, 2018 6:26 am

ghogan42 wrote:Do you think it is a phase issue?

here is modification of LCD filter:

Code: Select all

# range -128..128
# sum of line must not exceed the range!

# Even Sharper Bilinear with pixel outline
# effect (for LCD simulation)

# horizontal coefficients
   0, 128,   0,   0
   0, 128,   0,   0
   0, 127,   0,   0
   0, 125,   0,   0
   0, 122,   0,   0
   0, 116,   0,   0
   0, 108,   0,   0
   0, 102,   0,   0
   0, 100,   0,   0
   0, 102,   0,   0
   0, 108,   0,   0
   0, 116,   0,   0
   0, 122,   0,   0
   0, 125,   0,   0
   0, 127,   0,   0
   0, 128,   0,   0

# vertical coefficients
   0, 128,   0,   0
   0, 128,   0,   0
   0, 127,   0,   0
   0, 125,   0,   0
   0, 122,   0,   0
   0, 116,   0,   0
   0, 108,   0,   0
   0, 102,   0,   0
   0, 100,   0,   0
   0, 102,   0,   0
   0, 108,   0,   0
   0, 116,   0,   0
   0, 122,   0,   0
   0, 125,   0,   0
   0, 127,   0,   0
   0, 128,   0,   0


so you can compare now on VIP scaler.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Sun Nov 18, 2018 11:02 am

I think LCD and scanlines filters should be updated to have darker parts on the edges instead of middle. This will outline original pixels and will have better outlook.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Sun Nov 18, 2018 11:06 am

NES Lite revision now also includes ascal. It has problem when HQ2x is used - the video sometimes sporadic breakes. It looks like another overflow/edge issue.

Grabulosaure
Atari User
Atari User
Posts: 36
Joined: Tue Sep 05, 2017 9:35 pm
Contact:

Re: Scaler

Postby Grabulosaure » Sun Nov 18, 2018 1:16 pm

Sorgelig wrote:NES Lite revision now also includes ascal. It has problem when HQ2x is used - the video sometimes sporadic breakes. It looks like another overflow/edge issue.


I've posted the current version, many changes, but it's _really_ not ready. Many kinks, scaffoldings...

After painfully counting pipeline levels, pre-fetchs, offsets... I hope I have finally managed this time to get pixels aligned, taking into account the center of output pixels and map them to coordinates in the source image.

Grabulosaure
Atari User
Atari User
Posts: 36
Joined: Tue Sep 05, 2017 9:35 pm
Contact:

Re: Scaler

Postby Grabulosaure » Sun Nov 18, 2018 3:07 pm

cacophony wrote:FYI, I tried Genesis-lite.rbf and when I toggle the third OSD scaler menu item from "Normal" to the next option my TV goes black and the HDMI signal is lost. Two other people from discord mentioned they tried as well and got the same issue. If it helps, my setup is currently outputting 1080p/60 to a 4k TV. Thanks for looking into the low latency mode! :D


I've tried low latency...
It only works when the input and output vertical frequencies are _exactly_ equal. Which is a pain.

For example with Genesis/Megadrive, at 60Hz :

Mode 256*224 60Hz : Image = 342*262*20=1792080 @ 108MHz -> 60.265Hz
set : video_mode=1280,110,40,279,720,5,5,56,81000


Mode 320*224 60Hz : Image = 428*262*16=1794176 @ 108MHz -> 60.195Hz. (for example Sonic)
set : video_mode=1280,110,40,281,720,5,5,56,81000

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Sun Nov 18, 2018 3:16 pm

When ascal will be mature enough to replace VIP scaler, i can try to combine vsync_adjust option with low latency mode.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3081
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Scaler

Postby Sorgelig » Sun Nov 18, 2018 4:53 pm

Grabulosaure wrote:I've posted the current version, many changes, but it's _really_ not ready. Many kinks, scaffoldings...

After painfully counting pipeline levels, pre-fetchs, offsets... I hope I have finally managed this time to get pixels aligned, taking into account the center of output pixels and map them to coordinates in the source image.


I'm using 1920x1080 resolution:
1) 256pix bug is fixed.
2) upper 3 lines bug in triple buffering seems fixed as well.
3) right edge has garbage replacing original pixels. 1-2 pixels wide. The pixels are inverted and copied approximately from the middle of screen.
4) Using LCD effect coefficients i clearly see 2 pale vertical lines through the whole screen. They are on the middles of left and right halves. Looks like result of some fraction rounding (or offset re-adjusting). Old version (currently used in Genesis) has no such problem.
5) Interlace is totally broken now. Sonic 2 dual mode displayed on the upper half while lower half contains the memory dump.


Return to “MiSTer”

Who is online

Users browsing this forum: Gehstock, nathanhardie and 4 guests