@Capehill
Now that I saw it: yes, definitely a Nova bug, no need to look at the source, thanks.

@kas1e
Thanks!

@Capehill
Definitely sounds like yet another Nova bug. Did you check older (like 1.68) Nova versions? The reason I ask is because IIRC "Spencer" uses FBOs with float texture targets for its shadow effects; this at least worked at some point in the past (at least <= 1.68). So maybe this problem is something new? Unfortunately the latest "fixes" in more recent Nova versions increased the register demand even more to levels so high that "Spencer", among much other stuff, doesn't work anymore at all, obviously because of the generally broken register management
Also, because it has a similar smell as that other recent bug, did you disable mipmapping for those textures?
Anyway, please mail me what you got, if possible with src like the last time.

@AlfredOne
Hans seems to be too busy to answer, I'll try based on my experiences and observations instead.
Unfortunately this has not been fixed during the last 3,5 years.
It's hard to give any precise info on what to change without seeing your shader code, but there are some rule of thumbs and hints I can give.

I suggest to get your hands on a standalone SPIR-V compiler (glslangValidator) and a SPIR-V disassembler (I use the windows spirv-dis.exe, was too lazy to try to port that to aos4 so far). Taking a look at the disassembly (no worries, it's pretty easy to grasp) of your shader will help you to get an idea about the ~ overall register requirements and where your shader "loses" the most registers, in case of Nova. The reason is:

SPIR-V has no concept of registers. For many operations it simply introduces new "dummy" variables to hold intermediate calculation results or to pass function parameters around. And it doesn't reuse such variables, it simply doesn't care and adds new ones. Nova should of course have a register manager which doesn't do that but instead transforms those dummy variables into true temporary register usage. Unfortunately that isn't the case. Which is why until now and right now the first rule of thumb is:

Nova's register demands are roughly equivalent to the SPIR-V source's variable usage.

Probably the biggest reason for register-waste are function calls, the more parameters the function has the worst. This is because SPIR-V creates variables for every parameter passed. If you want to make Nova's shader translator to give up real fast then have many functions and / or functions with many parameters and / functions that are called multiple times.
Therefore try to avoid this. If your function isn't recursive and reasonably small, consider making it a #define. If your function has tons of single float parameters, consider packing those into vec4 or so. Or maybe, as a last resort and if possible without side-effects, work with global variables instead.

It may also help if you keep the amount of true named non-temporary variables low in general and also try to reuse your own temporary variables instead of coming up with new ones.

As a last resort, if you run out of ScalarGPRs (stuff like "float") then try to use VectorGPRs (stuff like "vec2") instead and vice versa.

Also, try to avoid arrays, Nova is particularly wasteful with those. Of course that's often not an option.

Hope that helps a bit, cheers!

@Capehill
Quote:
Yes, and it should also work if you attach the same texture to multiple FBOs. Also measures have been taken so that glTexture2D doesn't cost extra time in general. Was no 1-liner

Quote:
It should be inside the next official Enhancer update. Talked to Matthew about that yesterday.

@Capehill
Yo, done, new regular ogles2_3_wip.zip has been updated accordingly. The reason why it didn't work in my previos first shot from above was that I forgot to update the internally cached FBO width / height...

@Capehill
There's an ogles2_3_capehill.zip on my FTP for you.
Now a glTexture2D should be enough, totally untested, of course , crossing fingers .
If it doesn't work then please mail me your latest exe for me to try.

@Capehill
Yes, you are right, it doesn't trigger an FBO update if the same texture is being reattached. So right now a dummy attach(0) would be required a.t.m., just as you outlined above.

@Capehill
It should be possible if you use glTexImage2D and then call glFramebufferTexture2D again to explicitely update / notify the FBO accordingly.
I have to admit that I'm not sure about what the specs say here, whether a call to glFramebufferTexture2D is required or not / whether glTexImage2D should internally take care by itself that an FBO the texture is attached to gets updated.
But at this time our ogles2 wants you to call glFramebufferTexture2D again, unless Nova internally readjusts things (if you got garbage that could be an indicator that Nova doesn't care neither without an explicit FBBindBuffer or so).

EDIT: woops, apparently our last postings overlapped
EDIT2: from what I read now so far it seems that this is a standard violation in my ogles2 implementation, it should be enough to call glFramebufferTexture2D once to establish the connection. A resize of the texture via glTexture2D should from then on automatically trigger eventual FBO updates under the hood. I'm going to fix this asap.

@kas1e
Quote:
That's something totally unrelated. Support for arrays inside ogles2 has nothing to do with local arrays inside shaders. No, this one's for sure yet another Nova bug.

@kas1e
Such a basic problem in glslangvalidator is extemely unlikely (maybe even more unlikely than a bug in your favorite smart_ptr implementation ), whereas another bug in Nova is highly likely. Considering Nova's current state I'd suggest to asume that it's another Nova bug and just report it.

@kas1e
Quote:
Just report it the way you just did here. It's Hans' job to extract the "why" out of this and to fix it.

@thellier
Yes, it would be possible to make such shared texture-samplers. And there certainly is some benefit here, after all samplers are a limited resource and maybe sharing those also improves performance a tiny bit. ogles2.lib manages "fixed" sampler / texture pairs, no sharing. In theory Nova could use shared samplers under the hood, but I bet it doesn't neither. I'll keep that in mind for an ogles2 update.

However, unfortunately the texture / sampler handling has no impact on the shader's register usage. It's something independent. I mean, the shader's binary code doesn't change if you bind different textures / samplers to different tex units. Of course, a sampler, just as a texture, uses up a certain amount of SGPRs to be used with an image instruction, but that's independent of the actual bound samplers during rendering. Maybe imagine those registers as being pointers to sampler-data. What you'd change with your proposal is where those point to but not the number of pointers in the code.

No, the reason for shaders running out of registers so quickly is this.
Nova simply has no acceptable real register allocator / manager until now. And the only way to fix those problems is to write a real one, simple as that.

@Capehill
Well deserved "holiday"

@kas1e
yes, not having working mipmaps is close to being a show-stopper here in case of ShaderJoy (in most games it should work, the common way of vertex interpolated UV mapping seems to work). That's why I marked the bug as what it is: severe and with high priority. Wonder what Hans messed up there, it's really a weird issue. I mean, it's not random garbage. Looks as if the wrong lod is picked for fragments on the edge of the triangles only if a mipmap filter is enabled for the respective sampler.

@Capehill
@kas1e
Reported as Nova bug.

@Capehill
At first glance I cannot see a bug neither in your code nor in ogles2.lib. The automatically generated mipmap chain seems to be okay too.
Btw.: the 2x2 pixel look stems from the fact that both triangles of your fan produce the same artefacts at their respective edges (most often but not always those are of the same color as I saw now).

That garbage diagonal line revealed a minor issue with Shadertoy though: apparently the render-rectangle is not necessarily resized correctly until you manually force it to resize.

Edit: Wanted to see what happens if I explicitely select a LOD by using textureLod() instead of texture() -> not implemented in Nova.

Edit: I'm now building a test app from ground up to see if I can somehow reproduce this with my own code So far I could not, but so far I'm using normal UV mapping (which is what that textureCube example does too).

Edit: Some Nova-"fun": if you add the following no-op lines on top of your texture_rotator.frag, then the diagonal garbage starts to flicker (stop animation to see the effect):
vec2 fc=fragCoord;
fc.x+=0.0;

Verdict:
Severe Nova bug. Can be reproduced and triggered if you use gl_FragCoord to access a mipmapped texture via texture(). No workaround found.

Quote:
I tried too, and it was pretty easy after all:
Modified Nova's own textureCube example to reproduce the bug and to rule out any other factor, check it out here.

@Capehill
Thanks for the great updates

Quote:
Sorry, if this workaround had been mentioned before I missed it. Yes, it did and my report was wrong, it was just that sometimes I had started notepad or sth else with a text gadget before and didn't realize it. But who cares, it's fixed

@kas1e
@Capehill
Quote:
Quote:
Nova once had problems with NPOT mipmapping but that should have been solved long ago (IIRC it was fixed during "Spencer" development). But that bug resulted in general pixel garbage, the texture data was misinterpreted, IIRC. Here however the texture fetch is obviously broken, not the texture data. Also interesting that the "pixels" of the diagonal line are actually always 2x2 pixel blocks of which all of its 4 pixels share the same color.
Really weird, never saw sth. like this before. Looks as if you just found a fresh big Nova bug.

However, before I give my final verdict, please mail me the source of your texture setup. Maybe there's some subtle bug somewhere which in turn tricks ogles2 to prepare an invalid sampler (e.g. if I forgot to check some error condition somewhere). A Nova bug is much more likely of course (last not least because I actually cannot imagine any bogus sampler setup which would result in sth like this), but let's check first.

@walkero
Well, it's a dirty hack, an emergeny sort-of solution for those Polaris cards without classic W3D support (which I wouldn't recommend anybody with interest in older Amiga 3D stuff to buy at this time, better go for SI for best 3D support). And I certainly won't find time to make GL4ES reentrant and MiniGL4GL4ES more compatible / stable in the foreseeable future.

@thellier
Could well be that on top of that Blender would need some special treatment.

@Capehill
Here the text gadget pretty much randomly works / doesn't work. Well, either it works after system start - and then it always works, or it does not - and then it won't no matter how often you try.
But maybe it's better to launch the user's favorite editor and then monitor the currently active shader file for changes and auto-reload?

My results are the following.

https://www.shadertoy.com/view/4djGzh - black screen
https://www.shadertoy.com/view/MsSGWz - ouch, system freeze, always

For those I took a quick look at the shader code:

https://www.shadertoy.com/view/3lscDf - almost black, only a handful of rotating sphere-like entities visible. didn't spot anything critical, in theory, with certain theoretically possible N / P constant combinations some math could become undefined, but not in this config, so didn't spot bugs in the shader.
https://www.shadertoy.com/view/4djGWV - pixel garbage revealing CUs, pattern depends on mouse input (which is to be expected for all shaders which use mouse-input). Didn't spot bugs in the shader.
https://www.shadertoy.com/view/Md2GDy - solid brown-red with pixel garbage in the center and at the right edge. Didn't spot bugs in the shader.

This was with Nova 1.71. I'd say it's fine to throw'em at Hans.

@jabirulo
great idea!



Note:
The analogue stick detection didn't advance for the XEOX left stick when it asked for the right direction. Circling the stick helped.