TinyGL: FBO, Shaders and futur improvements
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Cool_amigaN
    Posts: 731 from 2011/11/30
    Quake 2, Quake 3, Warzone, all recent BeWorld's SDL2 ports (Ottomatc, nanosaur 2 etc), Freespace, AvP, Robin Hood (btw, indeed it seems to run faster to me too) work perfectly. However, with GLQuake, I get the follwoing error: Starting Quake...
    I_Error: Hunk_Alloc: failed on 1544814608 bytes
    End
    I can't recall whether this was happening in the past with some versions of MorphOS/TinyGL and then it stopped working.

    [ Edited by Cool_amigaN 08.01.2023 - 22:56 ]
    Amiga gaming Tribute: Watch, rate, comment :)
  • »08.01.23 - 21:56
    Profile Visit Website
  • MorphOS Developer
    bigfoot
    Posts: 469 from 2003/4/11
    Quote:

    Cool_amigaN wrote:
    However, with GLQuake, I get the follwoing error: Starting Quake...
    I_Error: Hunk_Alloc: failed on 1544814608 bytes
    End
    I can't recall whether this was happening in the past with some versions of MorphOS/TinyGL and then it stopped working.


    You can easily test if it's caused by the TinyGL update by copying in MorphOS/Libs/tinygl.library, MorphOS/Libs/tinygl/r200.library and MorphOS/Libs/tinygl/r300.library from a MorphOS 3.17 ISO to your sys: partition, rebooting and trying again. It'd help me a lot to get this confirmation before I try to reproduce it myself. Also please create a new temporary Quake folder with just the Quake binary, id1/pak0.pak and id1/pak1.pak present, to make sure it's not triggered by some installed mod.

    If it turns out that it does work with the files from MorphOS 3.17, then please link me to the version of GLQuake you're using, as there are many of them around :)
    I rarely log in to MorphZone which means that I often miss private messages sent on here. If you wish to contact me, please email me at [username]@asgaard.morphos-team.net, where [username] is my username here on MorphZone.
  • »09.01.23 - 13:22
    Profile Visit Website
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Cool_amigaN
    Posts: 731 from 2011/11/30
    Yeap Mark, indeed it was some of my mods causing the issue. Vanilla Quake paks work flawless (with stock MorphOS 3.17 and your latest commits). Is there anything in particular you would like to test? Think I might have every game sitting on my HD :P
    Amiga gaming Tribute: Watch, rate, comment :)
  • »09.01.23 - 18:57
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    tolkien
    Posts: 480 from 2013/5/29
    It's not really to push, just out of curiosity. Any news about this?
    MorphOS: PowerMac G5 - PowerBook G4 - MacMini.
    Classic: Amiga 1200/060 - A500 PiStorm
  • »29.03.23 - 15:08
    Profile
  • MorphOS Developer
    bigfoot
    Posts: 469 from 2003/4/11
    Quote:

    tolkien wrote:
    It's not really to push, just out of curiosity. Any news about this?



    Sorry for the quiet as of late. I've been working on the R600 (and R700, Evergreen and Northern Islands) driver over the past few weeks, mostly focusing on writing the shader compiler for it. The shader compiler seems to be in a fairly good shape right now (more on that in the next paragraphs, for those interested), so my focus will shift to getting all the other parts required to make the driver work done. These things are mainly basic hardware setup, state handling, texture handling and so on. This means that I unfortunately am still not at a place where the driver can render even the simplest thing, but once I do get there, there will be very rapid progress to a fully functional driver. I am hoping to have the R600 driver run its first simple apps next week, although I can make no promise that that's when it'll happen.

    The following can be skipped for those who are not interested in the technical side of the driver development.

    Now how can I know the shader compiler is in a good shape if I can't run it yet? Well, graphics hardware in general, and certainly Radeons specifically, there's really not much you can do in terms of getting any sort of debug info out of the hardware. I write the driver, I try it and I get basically one of 4 possible outcomes:

    1) There's a software crash.
    2) Nothing happens.
    3) The hardware crashes, but the OS keeps running.
    4) The hardware completely locks up the entire system.

    1 is the easiest to debug, since it's almost certainly a software problem. The other 3 are much more difficult to debug, although each failure mode does give a hint as to what's going on. However, a bug in the shader compiler can cause any of the failure modes labelled 2-4 above, with no or little additional info available to help me figure out why it's failing. Simultaneously pretty much any other mistake in the Radeon state setup can also result in any of the same 3 failure modes, so it's really hard to tell what's going on at a first glance when there is a problem.

    When it comes to debugging shaders, there's no mechanism for stepping through a compiled shader program to see what's happening and when. There's no way to even get any sort of run time information out of there, so that makes debugging it very much a trial and error thing, which is very time consuming.

    So one thing I'm doing to reduce the amount of time I have to spend fumbling around in the dark is that not only do I write the shader compiler, I also write a disassembler for the shader binary that gets uploaded to the Radeon hardware for execution. So while writing the driver, I first make it compile whatever program is passed to it, and then immediately afterwards it disassembles what it has just compiled. It then dumps all this data (the original shader source, all the intermediate compiler states after parsing, optimising, etc and the disassembled program) for me in the debug log. I then go through everything manually, comparing it to the original shader source passed to the driver to make sure the final compiled program actually matches what the source code does.

    Doing it this way is a bit more work up front, but it saves me time in the end, as it helps me catch a lot of simple mistakes that happen while initially writing the compiler, and it helps me confirm that what the compiler does is actually correct. It is also why I can state - without having actually run any shader binary produced by the compiler - that the compiler is in a fairly good shape currently.

    Another interesting thing about R600 and newer hardware is that the part of the hardware that fetches vertex data from memory and presents it to the vertex shader for processing, which was fixed-function hardware in previous Radeons is now entirely, 100% a shader on its own. That means that just to have the hardware fetch vertex data from memory, the driver has to generate a shader to instruct the Radeon how to do so.
    I rarely log in to MorphZone which means that I often miss private messages sent on here. If you wish to contact me, please email me at [username]@asgaard.morphos-team.net, where [username] is my username here on MorphZone.
  • »01.04.23 - 09:32
    Profile Visit Website
  • MorphOS Developer
    zukow
    Posts: 636 from 2005/2/9
    From: Poland
    April Fools' Day is not the best day for the announcements :)
  • »01.04.23 - 12:21
    Profile Visit Website
  • MorphOS Developer
    bigfoot
    Posts: 469 from 2003/4/11
    Quote:

    zukow wrote:
    April Fools' Day is not the best day for the announcements :)


    Haha :) This is very specifically not an announcement, though ;) But yeah, no April Fool here.
    I rarely log in to MorphZone which means that I often miss private messages sent on here. If you wish to contact me, please email me at [username]@asgaard.morphos-team.net, where [username] is my username here on MorphZone.
  • »01.04.23 - 14:04
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    tolkien
    Posts: 480 from 2013/5/29
    Thanks for the detailed info and the hard work mate!
    MorphOS: PowerMac G5 - PowerBook G4 - MacMini.
    Classic: Amiga 1200/060 - A500 PiStorm
  • »02.04.23 - 07:50
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    ernsteiswuerfel
    Posts: 501 from 2015/6/18
    From: Funeralopolis
    The release notes unfortunately don't make it clear which state of the TinyGL project is included in MorphOS 3.18. So I am asking here. ;-)

    I suppose it's TinyGL-Update-2022-12-27.lha? Or is it anything beyond that?
    Talos II. [Gentoo Linux] | PMac G5 11,2. PMac G4 3,6. PBook G4 5,8. [MorphOS 3.18 / Gentoo Linux] | Vampire V4 SA [ApolloOS / Amiga OS 3.2.2]
  • »14.05.23 - 12:01
    Profile
  • MorphOS Developer
    cyfm
    Posts: 524 from 2003/4/11
    From: Germany
    Quote:

    ernsteiswuerfel schrieb:
    The release notes unfortunately don't make it clear which state of the TinyGL project is included in MorphOS 3.18. So I am asking here. ;-)

    I suppose it's TinyGL-Update-2022-12-27.lha? Or is it anything beyond that?


    It is a snapshot of what the MorphOS betatesters got after the 2022-12-27 TinyGL update. It contains a few more fixes which only bigfoot has all the details for.
    There is no major changes or any new milestones to be found in there AFAICT and I guess he will prepare a new update once he considers it to be worth it and his time permits.
  • »14.05.23 - 15:01
    Profile Visit Website
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    ernsteiswuerfel
    Posts: 501 from 2015/6/18
    From: Funeralopolis
    @cyfm: Thanks, that's what I wanted to know!
    Talos II. [Gentoo Linux] | PMac G5 11,2. PMac G4 3,6. PBook G4 5,8. [MorphOS 3.18 / Gentoo Linux] | Vampire V4 SA [ApolloOS / Amiga OS 3.2.2]
  • »14.05.23 - 15:10
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    matt3
    Posts: 564 from 2004/2/10
    @bigfoot

    I was checking in to see if you had an update of the status of the drivers?
  • »28.05.23 - 00:14
    Profile
  • Just looking around
    anchor
    Posts: 3 from 2014/1/1
    hello,

    i'm trying the improved TinyGL on MorphOS 3.18 + latest SDK. (powerbook with radeon 9600 pro)
    for me the framebuffer object extension is not available. could anyone use it?
    i tried with the latest powersdl, and with the latest sdl2, but i see opengl 1.2 context only, and no framebuffer object extension. i tried the tglEnableNewExtensions() function too, but the app hangs with it.

    any advise appreciated.
  • »01.06.23 - 21:31
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    Tcheko
    Posts: 481 from 2003/2/25
    From: France
    Quote:

    anchor wrote:
    ... the framebuffer object extension is not available.


    If the extension isn't advertised, it just mean that it is, well... not (yet) available.

    This extension will probably be implemented at a later time.
    Quelque soit le chemin que tu prendras dans la vie, sache que tu auras des ampoules aux pieds.
    -------
    I need to practice my Kung Fu.
  • »02.06.23 - 07:40
    Profile Visit Website