kas1e,

TinyGL now supports GLSL 1.20, which is what is mandated by OpenGL 2.1, which is the newest version of OpenGL that R300, R400 and R500 can support. GLSL 1.30, which is what is mandated by OpenGL 3.0, introduces for example integer variables in shaders, which the R300/R400/R500 does not and cannot support. So until the R600 driver is done, no newer version of GLSL can be supported.

beworld has been super helpful and tested a lot of things with shaders already, which has lead to a bunch of bugs being found, which will be fixed in an upcoming TinyGL update, which again will almost certainly be ready this week. What this means is that unless you want to be on the bleeding edge of testing, you can easily wait a little bit and let others test and get bugs ironed out before trying it yourself.

@bigfoot
Thanks for answer !

Did you wrote your own GLSL parser to binary data or it's done by some 3d party stuff like glslangvalidator or so ?


Btw, to find all the possible bugs in GLSL shaders will be nice to have something like ShaderJoy tool we have on os4: http://os4depot.net/share/graphics/viewer/shaderjoy.lha, which can use shaders from https://www.shadertoy.com. With this one i find hundred bugs which devs later fixed and that all improve GLSL support a lot in our drivers. So maybe it worth making something simple-easy at least to be able to load up those shaders just for bug-hunting.


@beworld
Sounds good! Lately i bug-report scummvm guys in terms of shaders and they did fix all of them (at least those which used in Grim, Myst, Wintermute3D, et) so they works on big-endian fine. If GLSL1.20 will works as it on morphos, it mean morphos port should works as it without issues too with "opengl with shaders" renderer.

[ Edited by kas1e 07.09.2022 - 13:00 ]

I'm not sure if Capehill would be open to letting ShaderJoy be ported to MorphOS but it's worth an ask.

Edit:

There's an open-source version of ShaderToy for iOS here.

[ Edited by Samurai_Crow 07.09.2022 - 11:52 ]

> letting ShaderJoy be ported to MorphOS

ShaderJoy requires OpenGL ES 2.0, of which there is no implementation on MorphOS, so it wouldn't be a straightforward port at least.

I updated TinyGL to the latest public beta and run my 4 programs wich use 3D acceleration. Everything looks correctly.
I also updated SDK and rebuilt my current project. The result is perfect. No problems detected!

Thank you for backward compatibility. :) Currently this is very important for me.

Re:ShaderToy source

A quick search on Brave Search revealed this GitHub project. I don't know if it's any more straightforward than the iOS source I linked above in ObjectiveC.

Quote:

At least a magnitude more straightforward to port.

Still, probably 99% of shadertoy shaders will simply fail to work on our totally outdated GPU. Keep in mind that those R200/R300/R500 belong to the very first programmable GPUs with GLSL.

For example, R300 has 64 instructions limit (and even less for R200), no loop, limited conditional, no jump, no native sin/cos instruction (it is emulated but takes a fair number of instruction to do so), no support for integer, just float (FP24 for r200/r300, FP32 for r500).

{precison}
After some deeper inspection, vertex supports native sin/cos instruction but fragment doesn't and must emulates those instructions.
{/precison}

It still can do wonders but with 20 years old shaders.

For example, this kind of shaders are more likely to be working :

https://graphics.cs.wisc.edu/WP/cs559-sp2016/2016/03/08/glsl-shader-examples/


[ Edited by Tcheko 08.09.2022 - 14:50 ]

I've released another version of the TinyGL update. It is mainly a bugfix update, fixing some (but not yet all) of the many issues found and reported by beworld. Thank you for the testing and the reports!

Thanks bigfoot and BeWorld for this new release!

Quote:

So that mean most of today's shaders can't work until there will be support for more or less modern gfx cards ?

@beeworld

Is ScummVM's shaders works on current tinigl-beta ?

Fantastic! Another week, another update!

@kas1e
"all to be able to made morphos versions of some of my stuff."
Great. What program have you in mind to port to MorphOS?

Quote:

Maybe Irrlicht Engine or FoobillardPlusPlus?

Quote:

not yet...

Quote:

That's a correct summary. The less is superfluous nonetheless ^^.

Today's shaders are more like in many thousands of instructions when compiled... Some are even doing raytracing with...

For example, NVidia RTX3080 have 8704 shading units (ie kind of cpu executing vertex/fragment program) and 272 TMU (Texture Mapping Unit). Comparatively, R300 runs 8 vertex shaders and 4 fragment shaders and has only 8 TMU.

Also, current GPU runs in the 4 to 10GB VRAM ballpark...

Anyway, we will probably do wonders with that old hardware :)

@Tolkie,waldiamiga
Quote:

IrrlichtEngine surely at first (this one can works with very minimal shaders support or even without at all, just need to be opengl 2.x at least), foobillardplusplus also very possible. Things which use lots of shaders probably will be no go for current supported gfx cards: for example Words game quite heavy in terms of shaders support, Eldritch also do use some heavy shaders.. But of course, all depends on the level of GLSL support and the latest/better gfx card which will be supported on Morphos. Even old GLSL shaders of 110-120 version usually big enough with all those things which Tcheko descibe above, which if emulated, will made things with shader be slower than without.

For now for example i works on some port for os4 based on irrliht engine, which use just one single shader, this one: https://github.com/elnormous/RealisticWaterSceneNode

See there in directory shaders 2 glsl shaders, which while not big enough by code, still when i use them as it in the game, it drop the FPS in whole game play radically, even if it works and renders as expected. So i tried to optimize it as much as possible => by all this i mean, that even if shader works, it's to be seen how fast and good it is, as it can make things even worse if it written bad in compare with no shader usage at all. And it's quite common that things with shaders can be even slower (and on Windows/Linux that the same), than without. And if many things in shader will be emulated in software, then imagine how slow it will be and better go "no shaders" way.

In other words once bigfoot and co done, this will be very interesting to play with

@bigfoot: why Cube Map example up my G5 (X1950) to 100% please ? Bizarre no ?

Quote:

Of course! If these updates (or any MorphOS update) breaks anything that used to work before, then it's a bug. In that case, please report it to me (or use MorphOS' built-in bug report tool) so it can get fixed as soon as possible!

Quote:

It's unfortunately completely normal currently. There is a fix for this in the works, but it needs more testing to make sure it doesn't break anything for anyone, so it'll probably only get fixed with the MorphOS 3.18 release.

Quote:

Ok thanks for your return!

It's time for a new public update of TinyGL. You can download it here.

The highlights of this update are:
- Support for shaders on R500.
- Various shader related bug fixes and optimisations.
- Inclusion of ShaderBoy to test and play around with shaders.

See the included readme file for a full list of changes since the last update.

Work fine on my Quad G5 + X1950 !

Thanks a lot bigfoot !

[EDIT] Bizarre, i have a small black square in the middle of the window in Doom3 game...
[EDIT2] Fixed with new SDL2 libraries Thanks a lot beworld !

[ Edité par Papiosaur 05.10.2022 - 16:39 ]

Teh nice

Big Thanks @bigfoot !!!!
All examples are working well on my G4 with Radeon 9650 and G5 with Radeon x1900GT :)

Thanks Mark!

Could be my flashed RadeonXT 9800 256MB AGP but on ShaderBoy when choosing Preset: Twister, my system freezes. Can somebody else pls test it as well?

Quote:

This preset is working ok here (Powerbook 17" 1.67). Your system is probably still running (try pinging the machine from another computer for example). The problem is probably located inside r300.library which is the radeon driver for tinygl. If something bad is happening here, the whole graphic stack is frozen (ie: no more rendering to screen). The only solution to grab information of what's going on is to use firewire ochi_mon to catch the debuglog.

Can you get this firewire debuglog? Without it, it will be hard to figure out what's going on.