ps. Is it expected that Drag&Drop didn't work when we run ShaderJoy with disabled "EditorView"? It brings me "GetAttr failed, Unknown type for dropped file". Once I uncomment back "EditorView" tooltype, Drag&Drop starts to work again.
Great, time permitted could you add support for registering it via application library so user will also be able to disable the screen blanker activation?
float d = grid2D(ro, rd, st);
vec3 p = ro+rd*d;
vec3 n = normal(p,st);
vec3 l = vec3(cos(iTime),sin(iTime),.25)*10.;
vec3 ld = normalize(l-p);
float diff = max(dot(ld,n),0.);
col += diff*p.z+(p.z+.1)*.1;
fragColor = vec4(sqrt(col*mix(B,G,p.z*1.5)), 0.);
}
Maybe now it's the same issues ? I mean check with previous versions, like 1.16 (at least on my x5000/RadeonRX it bars.frag works on 1.16 version of shaderjoy)
Maybe it can be some memory trashing somewhere which cause some bad data to be send to GPU ? At least that how i can explain why shader which i post works till 1.8 and start freezes after.
If that will be common case, then we can think about what cause it :)
@kas1e I can reproduce it with my SI setup (it's not just the bars shader btw.). My tests indicate that it's a Nova 1.78 bug with practically 100% certainty, probably unique to SI, considering that it works just fine for you.
It's strange from Shaderjoy perspective if one shader freezes but the others work, considering that every shader is treated equally. They use the same uniform variables.
Was there a Mantis ticket about this "green cubes" shader issue?
@Capehill I didnt create bugreport for this one, as if particular shader work in previous versions of shadetjoy, and start freeze after, then even if i will report it, most luckily Hans will ask us to pinpoint what were the changes which made behaviour changes. Maybe start to revert commit per commit to see when that shader start to work again, so it may give us some clue.
Anyway, there also some othet shaders freezes with the same "gpu ring hang" on serial, but they freezes from beginin (need to test them on nova 1.78). There is reports for them if it will be of any help: 494, 544, 553 and 602.
Dunno if it all common issue, but at least this one which wr discuss works before at some point
Well I can make a Mantis ticket then. It's an error dump from the driver level and Shaderjoy is not commanding driver directly. If this can be an application error Hans may need to give some advice what to check.
IIRC the only OpenGL change between 1.11 and 1.12 was the default texture filter mode and this shader doesn't even use textures.
EDIT: @kas1e "green cubes" doesn't work on Shaderjoy 1.11 anymore with Nova 1.78. How about your side (Polaris)? Freeze looked similar to #616 so I haven't opened a new ticket yet.
I retested "green cubes" now, and they works on Polaris till 1.11 ShaderJoy, and start freezing since 1.12 of shaderjoy. That all with nova 1.78.
But then, your freeze on RadeonHD is probabaly the same issue as you had with bars.frag, and which Hans already fixed, and once he add few more insturctions he probabaly will release 1.79 so we can check.
@Capehill It turned out that in 1.78 those ones were fixed: 494, 553, and 544. Only 602 one is freezing and our "green cubes". I created a report about so we move to something: http://www.amiga.org/developer/bugreports/view.php?id=617
Btw, checked for now for about 2000 shaders for the last days, and can say that yeah, SGPRs/VGPRs limits are on 99% gone since 1.78. There few shaders that can be found which still fail, but it's just about 20 from 2000, and they _very_ complex. See for more info: http://www.amiga.org/developer/bugreports/view.php?id=484
And while all compiles and seems works (it change the pictures randomly from 3 ichannels of bufferA and a bit fuzz/blure them): there still some error, on some switch, instead of showing actual texture image on the left side, it shows grey screen. Just want to be sure it is not a ShaderJoy issue about handling multipass shaders, but Nova one so can report.
Run it, it will bring you 2 error windows (one console output, and another with an "ok" button). Now, once it fails:
1). Take the scrollbar of console output, and scroll at the top. 2). Hit "OK" in the reaction window. 3). Now you still at the top of your previous output once you scroll it via scroll bar as expected, so then close that console window via a close gadget. 4). Try to close the main ShaderJoy window => fail + suspend.
Run it, it will bring you 2 error windows (one console output, and another with an "ok" button). Now, once it fails:
1). Take the scrollbar of console output, and scroll at the top. 2). Hit "OK" in the reaction window. 3). Now you still at the top of your previous output once you scroll it via scroll bar as expected, so then close that console window via a close gadget. 4). Try to close the main ShaderJoy window => fail + suspend.
Now this looks like some system issue (console?). Shaderjoy wants to print the GL error after you close the message box but if console is scrolled to top position, nothing happens and Shaderjoy is blocked.
EDIT: made a simpler test that should show 2 issues:
1) If you scroll up during delay, program doesn't exit. There is a DisplayBeep call to detect this easily. 2) When you scroll down, the last print will corrupt the previous line.
@Capehill Not sure that I can reproduce it from your test case. For me it just runs, starts print strings, once it comes up to the Delay, I grab the scroll bar and scroll it up. Wait for some seconds (and didn't hear any Beep at this time), and then scroll down: and I can see correctly beep, and exit and no corruption.
PS. btw, Trevor shown ShaderJoy on Amiwest video. Though he didn't show for real cool shaders which works now, just some of the current ones from your archive. But still looks tasty :)