Shaderjoy 1.25

@All
Finished some statistic checking 350 random chosen shaders, results:


70: Working as expected

202 can't compile. Those ones different, but the most popular ones are :

--- 102: need XXX SGPRs as 102 not enough, and from time to time also need XXX VGRPS too, saying that 256 is not enough (BZ 484: http://www.amiga.org/developer/bugreports/view.php?id=484)
--- 41: Matrix element 0's type (unknown) doesn't match the matrix's element type (Float) (BZ 483: http://www.amiga.org/developer/bugreports/view.php?id=483).
--- 15: OpImageSampleExplicitLod instruction isn't implemented yet (BZ 482: http://www.amiga.org/developer/bugreports/view.php?id=482)
--- 20: Object xxx no found
--- 24: all sorts of other compiling errors.

35: blocky noise issue (BZ #481: http://www.amiga.org/developer/bugreports/view.php?id=481)
22 : wrong colors / wrong geometry / wrong rendering
4: crash (BZ #480: http://www.amiga.org/developer/bugreports/view.php?id=480)


So, at least Crash one is not that important (as happens very-very rare, just 4 shaders from 350 checked), while Blocky-Noise issue seems like some broken functionality in terms of passing values to/from functions, so pretty necessary to deal with.

Implementation of OpImageSampleExplicitLod also looks necessary as it cause of 15% of all failed to compile shaders. And "Matrix element 0's type unknown" almost half (41%) of all failed to compile shaders (and i found what issue is : just having mat2 m = mat(1,2,3,4); lines in shader cause shader fail to compile, even if nothing from that string is used called. Just enough to have it in shader to make it fail. Same for mat3).

And the most problematic now it's a low amount of SGRPS and VGRPS, quite a big problem. I noted for all failed shaders of that kind all the values of SGPRs and VGPRs they want, and:

1). there never happens issues when wanting only more VGRPS. VGRPS needs only when SGRPS needs as well. Such a combo from 100 shaders happens 30 times.

2). some shaders want really high values (like, 350 SGRPS while we can use 102 only, and 515 VGPRS while we can use 256 only). But most of the time , SGRPS needs it around 106 till 200. And VGRPS around 300 to 500.

So, realistically if it possible to make 256 SGRPS and 512 then 99% will fit in. Or at least making only SGRPS be not 102, but 150, will fix about 50% of failed shaders.

As for those with wrong rendering/broken geometry, I didn't parse them well at moment (soon), so probably something common can be as well in them as can fit in just a few bug reports, to avoid creating new ones for each.

@kas1e

Quote:

By now you must be dreaming of shaders! That is some serious testing, again.

I have just uploaded version 1.4 with icon tooltype support.

@Capehill
Quote:

:) At least we had some good result about things need to be fixed

Quote:

Tested : works from icon surely ! Have a question : should icon's tooltypes works also if i run app from the shell or not ? (currently not).

Also, i think i have an idea why sometime we have VSYNC to 30 fps instead of 60 : That probabaly happens when shader on start in first second give less that 60 fps, and then after increase FPS, but it will still 30 fps because at begining was lower by any of reassons. Once you disable VSYNC (and see how it jump to more fps, even like to 400 or to 900, depend on shader as usual), and enable it back, then it will be 60 fps. Maybe we need to wait 1-2 seconds since start before start FPS calculation ?

Btw, most of time it 59 fps when VSYNCed, not 60, is it ok ?


EDIT: I also see quite a few shaders use different buffers with shader's code, like "buffer A", which then included as iChannel too.

For example that one:

https://www.shadertoy.com/view/4lVGzc

Have any idea how to implement it ? Probabaly should be the same split as with sound implementation somehow (some tags or suffix etc ?)

@kas1e

Quote:

If started from the shell, it tries to parse command-line arguments instead of tooltypes. I can change that.

Quote:

But FPS counting is very simple. Measurement cycles shouldn't not impact each other. My theory is this could have something todo with compositing (+ vsync setting in the GUI prefs) but I have forgot to test it. I'm not using compositing effects at the moment.

Quote:

I will check on my system.

Quote:

It requires multiple rendering passes. First render buffer to a texture, then render final image using that texture. Probably the file structure is the hardest part of the problem. The GUI probably should be improved first.

@IamSonic

Parsed your database of working/non-working/glitches shaders, and can say that results are pretty the same as i have in my tests:

25% of non working shaders are because of needs more SGPRs/VGPRs (reported already)

20% of non working shaders are because of "noise" bug (reported already)

15% of non working shaders are because of "Matrix element 0's type (unknown)" (reported already)

few "non implemented OpImageSampleExplicitLod" (reported already)

And some other there and there. Issues with broken geometry and look (when there no noise) can be very easy be because of return values issues (that noise-bug and boolean bug reported already too).

So, once those things (or most of them) deal with, we can expect that many non-working and glitches shaders will works.

Now only to wait when Hans/AEON will prioritize work on warp3dnova again :) Remembering how it was in last year, we can't count on fast bug fixes. But at least they will be fixed soon or later.

How hard would it be to convert some of those cool shaders into screensavers?

@PEB
Very easy. I thinking about making some, just need to find some screensaver skeleton, to which you can just include drawing code. There some on os4depot with sources, so that very doable.

@kas1e

The best thing is you would have to implement the engine only once and just load the fragment shaders randomly.

Maybe add some fade in / out.

@Capehill
Found bug when tried to verbose big enough shader:

Insufficient log buffer: xxxxx bytes neeed.

To reproduce try to load any of those with verbose-output set:

https://www.shadertoy.com/view/llGGzh
https://www.shadertoy.com/view/4lyGzR

@kas1e

Thanks. I have fixed the Logger limitation for the next release.

I'm thinking about changing the default window size to 800*450 pixels (same as Shadertoy).

@Capehill
Quote:

Thanks!

Quote:

Yeah right, it's better to have default size as on shadertoy.com, easy to compare speed when size 1:1 the same

@Capehill
Found shader which give me 30 FPS when VSYNC, and 200 when non-vsync : https://www.shadertoy.com/view/XtBBzR. Even swith to/from few time anyway give 30 fps all the time.

More of it, when we in VSYNC mode, then we have 100% cpu loading with those 30 fps. But when we in non-vsync mode, we have 200 FPS, and no cpu loading.

@kas1e

Here:

- 60 FPS @ 75% CPU with VSYNC and
- 82 FPS @ 100% CPU without VSYNC.

Also, it seems that if compositing is enabled in the GUI prefs, FPS is rather 59 than 60.

@kas1e

Is the 30fps with VSYNC a Polaris issue ?

I also have 30fps with VSYNC.
139fps without VSYNC .

@Spectre,Capehill
Yep it on polaris, will check just in case on RAdeonHD too.

But anyway the strange thing is , that with VSYNC in window mode, we don't have reall VSYNC anymation. Its still jerky. The only real VSYNC i had on amigaos4 its in fullscreen. But on win32 for example, they surely have real vsync in window modes too. Not sure if it only ShaderToy, or general issue.

@kas1e

Thx for testing and categorizing my shader archives. It's probably easier for Hans to fix them by (Problem-)Category.

@kas1e

Quote:

On RadeonHD (R9 280X) i get 60 fps with VSYNC when using 1920x1080@60 Screenmode and 76 fps with VSYNC when using 1920x1080@76 Screenmode.

Quote:

Also noted that, even when VSYNC is enabled on Workbench using the switch in SYS:Prefs/GUI Effects section. It's actually visible without Grapics/Shader stuff when moving a window on the workbench fastly. Especially the borders of a window look frayed.

@kas1e
Quote:
What if you disable compositing effects in GUI prefs?

Hans

@Hans
Quote:

Dunno what happens, but once i disable compositing in prefs, then shadertoy can't do "load shader" or any other "load". Simple clicking on menu do nothing, and no ASL request opens (i tried that even after reboot). Quite strange !

That happens on RadeonRX, dunno about RadeonHD, didn't tested. But there seems something wrong if disabled of compositing cause calling of ASL requesters disappear

@Capehill

Can you reproduce on your setup differences with "load shader" or "load textures" menu when you had disabled/enabled compositing effects ? I can try to put RadeonHD for tests as well, but that will be strange if that will cause difference , as it just ASL requester to be called (right ?)

@IamSonic
Quote:

If i disable in prefs:gui/effects "synchronize with vertical refresh" , then on RadeonRX in shadertoy everything messed even more. Vsync start to give just 20 fps, while no vsync give 100 fps, and things jerky same as before.

And that "jerky" happens like every few frames "jumps" a bit, just like not vsync working

Is it at all expected that amigaos4 can have real vsync in window mode ?:)