Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
73 user(s) are online (5 user(s) are browsing News)

Members: 0
Guests: 73

more...
Support us!
Recent OS4 Files
OS4Depot.net
Recent Replied Topics
Topic Replies Last Post
Amiga Classic 3000T help request 14 (4505) Nuder_Try Today 15:07
Amiga General Forum Horny Source code on Github [1][2][3] 40 (1538) mr2 Today 14:32
AmigaOS4 Dynamic Code Execution, Malloc() and executable memory questions 2 (96) kas1e Today 14:00
AmigaOS4 Reminder: ZitaFTP Server Epiphany Discount ends soon (Jan. 20) 1 (98) Hans Today 4:34
AmigaOS4 ZitaFTP Server user experience 16 (584) khayoz Today 1:15
AmigaOS4 AmiUpdate 2.46? [1][2][3] 47 (2691) khayoz Today 0:30
AmigaOS4 MTP testing [1][2] 33 (10141) khayoz Yesterday 22:30
AmigaOS4 Battle for Wesnoth - SAM460 - Speed 4 (228) BobSacamano Yesterday 20:04
AmigaOS4 OctaMEDPlayer from A-EON Technology (WIP) 15 (6665) nubechecorre Yesterday 19:19
AmigaOS4 ScummVM and AmigaOS4.1 F.E. [1][2] 23 (5083) Raziel Yesterday 12:48
AmigaOS4 SDL2 [1][2] ... [37][38][39][40] 793 (207786) Capehill Yesterday 9:24
AmigaOS4 HD-Rec and audio recording 2 (194) mr2 1/17 22:30
AmigaOS4 How to build AmigaOS4 cross-compiler (Binutils 2.23.2 & GCC 8.3.0) on CYGWIN [1][2][3] 40 (1838) BSzili 1/17 19:32
AmigaOS4 GCC 8 - how to mix PPC asm & C code 6 (326) corto 1/16 21:14
AmigaOS4 SMBFS 2.1 19 (1979) MichaelMerkel 1/16 18:45
[View all topics]  [Forum Settings]
Amiga Events : Enhancer update: new ogles2, warp3dnova and radeonhd
Posted by kas1e on 2019/12/25 20:24:23 (226 reads) News by the same author
Amiga Events



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).


Resized Image

Resized Image

Since last public version there was numerious bug-fixes and imporvemtns, such as:

ogles2.library by Daniel "Daytona" Muessener.

Resized Image

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.

Resized Image

Changes since 1.65 version:

- Implemented W3DN_Q_TEXUREEXTSHARE

- 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.

Resized Image

Printer Friendly Page Send this Story to a Friend Create a PDF from the article
The comments are owned by the author. We aren't responsible for their content.
Author Thread
328gts
Published: 2019/12/26 18:28  Updated: 2019/12/26 18:28
Home away from home
Joined: 07/07/2009
From: Toronto, Canada
Comments: 2347
 !
this is great news! thanks to all involved & merry Christmas/ happy holidays :-)
khayoz
Published: 2019/12/28 2:13  Updated: 2019/12/28 2:13
Just popping in
Joined: 01/10/2007
From: Stockholm Sweden
Comments: 36
 Thanks!
Great news! Thank you to all involved and a happy new year!
General
Site sponsors
Advertise Here

Site statistics
Registered members
  1454
Logged in last:
  24 hours, 45
  7 days, 106
  30 days, 159
Top Posters
1 kas1e   kas1e 5724
2 Raziel   Raziel 3612
3 ChrisH   ChrisH 3553
4 Chris   Chris 3230
5 orgin   orgin 3181
6 samo79   samo79 3163
7 LiveForIt   LiveForIt 2751
8 Antique   Antique 2470
9 328gts   328gts 2347
10 Hans   Hans 2205
New Members
Spanky   Spanky 01/19/2020
simulant   simulant 01/19/2020
mpl   mpl 01/16/2020
TimoInutilis   TimoInutilis 01/14/2020
levellord   levellord 01/14/2020
arfcarl   arfcarl 12/31/2019
alienkidmj12   alienkidmj12 12/31/2019
gamemusicfan   gamemusicfan 12/16/2019
tw1sted1981   tw1sted1981 12/06/2019
Saksofon   Saksofon 12/02/2019
Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project