Welcome, Guest. Please login or register.

Author Topic: Enhancer update: new ogles2, Warp3DNova and RadeonHD  (Read 2306 times)


0 Members and 1 Guest are viewing this topic.

Offline kas1eTopic starter

Enhancer update: new ogles2, Warp3DNova and RadeonHD
« on: December 25, 2019, 01:58:23 PM »

Everyone who has registered a copy of the Enhancer Software pack can fire-up Updater now and got a new version of ogles2.library (v2.11), warp3dnova.library (1.68) and RadeonHD (3.7).

Since the last public version, there was numerous bug-fixes and improvements, such as:

ogles2.library by Daniel "Daytona" Muessener.

Changes since 2.8 version:

- Fix: if an enabled vertex-attribute-array was being disabled then the corresponding generic vertex-attribute wasn't applied eventually, resulting in semi-random vertex-attribute data.This will rarely happen in a real-world app, which is why this bug wasn't found earlier. Thanks to Juha Niemimaki (Capehill) for reporting!

- extension to the glGetString GL_VERSION query: it will now not only return the ogles2 lib's version but also the Nova version! Programs should check both versions because especially GLSL functionality depends on Nova, not so much on ogles2. The returned string now looks like this: "OpenGL ES 2 2.9 on top of Warp3D Nova 1.65". Thanks to Hubert Maier (Raziel) for indirectly inspiring me to do this one ;)

- and for convenience (or if you find it too hard to parse the 2nd version number (cough, Frank, cough ;) ) which may appear at different positions depending on the 1st one) the Nova version number is also appended to the GL_RENDERER string which now reads like: "Warp3D Nova 1.65"

- Implemented the OES_get_program_binary extension as requested by Kasie Kasovich (kas1e). Because Nova doesn't provide any support here, this implementation works with the internal SPIR-V code of all shaders that make up the respective program. So the binaries here are no true machine-code but intermediate code, packed into a proprietary format. Providing such binaries essentially skips the vertex- and fragment-shader's GLSL compilation steps. Anyway, this means:

- new function glGetProgramBinaryOES to extract such a binary representation of the respective successfully linked shader program.

- new function glProgramBinaryOES to supply the GL with such a cached binary.

- support for the glGet parameter GL_NUM_PROGRAM_BINARY_FORMATS_OES - which returns 1 now.

- support for the glGet parameter GL_PROGRAM_BINARY_FORMATS_OES, which returns one single format ID identifying my binary format (0xC00DA675)

- support for the glGetProgramiv parameter GL_PROGRAM_BINARY_LENGTH_OES which gives you the buffer size required to store the binary for the respective program.

- consequently added GL_OES_get_program_binary to the extension string.   

- added glProgramBinaryOES and glGetProgramBinaryOES to the stubs library for direct use.

- Fix:  aglGetProcAddress returned function pointers in the Amiga interface style, with the first parameter being a pointer to the interface. Now the compatible "stub"-style signature is being returned which matches the GL function pointer prototypes. Apparently nobody used aglGetProcAddress before, so this went unnoticed. On our ogles2.lib even the extension functions are all simply directly accesible just like all other functions, so if you code for Amiga only you don't need aglGetProcAddress. gl4es however uses it - and this was where it all exploded now :) Thanks to Kasie Kasovich (kas1e) for reporting!

- Fix: glScissor didn't gracefully handle negative xy or height. Thanks to Kasie Kasovich (kas1e) for reporting.

- Improvement: under certain circumstances ogles2 could be triggered to resize its internal client-RAM-emu-VBOs multibuffer to very very large values, in fact so large that Nova allocated almost all VRAM for those. At least on some Nova/RadeonHD.chip/graphics.lib setups the VBO resizing also triggered a crash bug in Nova's DeleteBuffer function under such low VRAM conditions. This improvement therefore also acts as a workaround for that issue. This fixes all such issues with some of kas1e's Irrlicht engine examples. Thanks to Kasie Kasovich (kas1e) for reporting.

- Fix: there was a bug in the copy-converter for 8bit and 16bit index arrays (Nova doesnt support 8bit indices and is very slow with 16bit indices, therefore those are converted to 32bit internally, even if the ogles2-client passes them inside his own VBO, then a "hidden" 32bit clone is prepared and used) which in theory could result in the indices not being updated at all. It was extremely unlikely to happen and AFAIK it never did, but anyway: fixed.

- Workaround/Fix: if you attached a GL_BGRA_EXT texture as color render target to an FBO, then the texture's red and blue channels would appear to be swapped when you later used that texture for rendering. The reason for this is that the BGRA texture's internal pixel format is actually RGBA, only that its channels are "swizzled". At the moment Nova ignores that swizzle setting when rendering to the texture. The current workaround is to reset any eventual swizzle to the defaults if the texture is being used as FBO render target, so simply spoken an BGRA texture becomes an RGBA texture if you use it as render target. This fixes color bugs in e.g. an irrlicht demo and Tuxkart. Thanks to Kasie Kasovich (kas1e) for reporting.

- maintenance, C++ modernizations: all attribute initializations moved from constructor initializer lists into the respective class definitions. Makes the code smaller and it's harder to forget something (and oops, I actually found one unitialized   attribute during the process (uncritical though)...).

- maintenance, C++ modernizations: "auto" return-value replacement run on all inline functions, where appropriate.

- (small) hashing functions speed-up (without hash quality loss).

- Fix: a bug in the uniform shader variable handler resulted in same-named (and thus logically identical) vertex- and fragment-uniforms to eventually be assigned different virtual location numbers. If the user issued a glUniform(location_number,xyz) call then the lib would only find and set the vertex-shader's uniform and skip the writing to the fragment-shader's uniform because it would simply not find it. OpenGL doesn't distinguish between such same-named but physically different uniform variables in the shaders of a GPU program - in stark contrast to Nova, where all that info is shader and not shader-program based. Consequently Nova's ShaderGetObjectInfo, which is used to query uniform variable information, works on shaders only. Also, Nova only gives us a GLSL / GL compatible "location" info if that has been explicitely defined inside the shader, otherwise it doesn't generate one but only returns W3DN_NOLOCATION. Because of all this ogles2.lib has to generate such location infos by itself, in a GL compatible way. Which means that in case of a same-named variable in both of a program's shaders the same uniform location has to be enforced. Which is where the flaw was. In gl4es this bug manifested in fog not working. Thanks to kas1e for reporting and testing!

Warp3DNova.library by Hans de Ruiter.

Changes since 1.65 version:


- Added W3DN_Q_TEXTURE_1D_ARRAY, W3DN_Q_TEXTURE_2D_ARRAY, & W3DN_Q_TEXTURE_CUBEMAP_ARRAY queries  (NOTE: No drivers support them yet)

- Implemented W3DN_Q_ENDIANNESS and the ability to disable endianness conversion for VBOs & DBOs

- Migrated to GCC8, refactored shader compiler to use stdlib smart pointers instead of boost, and enabled optimization when compiling the shader compiler (bug #413)

- Fixed a null pointer bug in the shader compiler (bug #452)

- Using texture samplers with an offset variable would lock up an SI GPU. FIXED

- Sin()/cos() shader functions couldn't handle input values. FIXED (bug #407)

- Refactored the shader compiler to use make_shared (reduces  memory allocation overhead)

- Failure when creating a VBO, DBO or other object could result in a crash. FIXED (bug #447)

- Added a null index buffer pointer check to the DrawElements()

- The register allocator was leaving large gaps in the register file, resulting  in it running out of registers. FIXED (bug #407)

- The shader compiler was reusing the function execution thread mask in multiple functions, causing potential data loss and image corruption with multiple nested functions. FIXED (bug #409)

- The register allocator shader log output now lists all registers when printing the final register allocations

- Some GLSL special functions such as sign() and smoothstep() couldn't be used in if/else loops; caused compilation failure. FIXED (bug #401)

Radeon HD driver by Hans de Ruiter.

Changes since 3.6 version:

- 64-bit internal GPU addresses were accidentally being truncated to 32-bits, causing a crash (bug 457). Issue happens on X5000 and Tabor when fill more than 256mb of GPU video memory. FIXED

- Added buffer ownership checks to the render manager's buffer locking and free code for extra safety (needed to share buffers  between multiple drivers)

The Enhancer Software package has been the result of a small dedicated team who have committed great efforts to this body of work. A-EON would like to thank the developers, beta testers and translators for their significant contributions.

« Last Edit: December 25, 2019, 02:09:16 PM by kas1e »
The following users thanked this post: klx300r

Offline lionstorm

Re: Enhancer update: new ogles2, Warp3DNova and RadeonHD
« Reply #1 on: December 25, 2019, 06:54:14 PM »
Nice Christmas present and thanks to everyone involved in this release.

note that the RadeonHDv3 is not part of the Enhancer software pack but part of the Enhancer software graphics upgrade pack so for people who bought the Enhancer software pack (and not the graphics update) only the ogles.library and Warp3D NOVA are updated.

Offline Pgovotsos

Re: Enhancer update: new ogles2, Warp3DNova and RadeonHD
« Reply #2 on: December 25, 2019, 10:20:22 PM »
This is an upgrade to Enhancer version 1.x correct, not version 2.x? Along with the graphics upgrade package too for the new Radeon driver.

Offline Skateman

  • Newbie
  • *
  • Join Date: Oct 2017
  • Posts: 35
  • Country: 00
    • Show only replies by Skateman
Re: Enhancer update: new ogles2, Warp3DNova and RadeonHD
« Reply #3 on: December 26, 2019, 08:58:41 AM »
Thanks!! Updated and ready to go!

AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon R7 250 / M-Audio 5.1 -> AmigaOS 4.1 FE / Ubuntu Linux
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world

Offline klx300r

  • Amiga 1000+AmigaOne X1000
  • Hero Member
  • *****
  • Join Date: Sep 2007
  • Posts: 3231
  • Country: ca
  • Thanked: 19 times
  • Gender: Male
    • Show only replies by klx300r
    • http://mancave-ramblings.blogspot.ca/
Re: Enhancer update: new ogles2, Warp3DNova and RadeonHD
« Reply #4 on: December 26, 2019, 04:08:15 PM »
WoW!!! what a great Christmas present thanks to all involved !!! ;D ;D ;D
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Indivision AGA & Catweasel MK4+= Amazing
! My Master Miggies-Amiga 1000 & AmigaOne X1000 !
--- www.mancave-ramblings.blogspot.ca ---
  -AspireOS.com & Amikit- Amiga for your netbook-
***X1000- I BELIEVE *** :angel: