Remember me

Lost Password?

Register now!


Who's Online
114 user(s) are online (8 user(s) are browsing News)

Members: 1
Guests: 113

TiredOfLife, more...

Support us!

Recent OS4 Files

Recent Replied Topics
Topic Replies Last Post
AmigaOS4 Amiupdate settings? 10 (684) Sbaitso Today 14:58
AmigaOS4 SDL PoP 6 (143) K-L Today 14:27
AmigaOS4 The OpenGL ES 2.0 thread [1][2][3][4] 68 (14651) kas1e Yesterday 16:02
AmigaOS4 Shaderjoy 1.14 [1][2] ... [11][12][13][14] 273 (17367) Capehill Yesterday 7:18
AmigaOS4 Need for Speed SE Amiga OS4 port? 2 (136) utri007 8/7 23:47
AmigaOS4 atheros wlan device is working [1][2] 35 (2473) ncafferkey 8/7 23:41
AmigaOS4 URL prefs 9 (238) nbache 8/7 23:24
AmigaOS4 StormC 5 5 (239) jap 8/7 13:40
AmigaOS4 SMTube api key 0 (85) white 8/6 9:10
E-UAE E-UAE keyboard configuration 3 (153) white 8/6 9:09
AmigaOS4 Classifieds working? 1 (125) walkero 8/5 20:00
AmigaOS4 M-Audio Envy 24 - test beeps and Mic only OS4.1 5 (211) trixie 8/5 7:04
AmigaOS4 Blog about developing the XP-Pen driver and also adding tilt support to SketchBlock 8 (683) khayoz 8/5 1:55
AmigaOS4 Simplemail shutdown locks up system 4 (351) Paul 8/5 0:38
Odyssey Does Odyssey use graphics memory above the 256MB? 7 (536) trixie 8/4 8:40
[View all topics]  [Forum Settings]
Amiga Events : Enhancer update: new ogles2, warp3dnova and radeonhd
Posted by kas1e on 2019/12/25 20:24:23 (618 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:


- 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
The comments are owned by the author. We aren't responsible for their content.
Author Thread
Published: 2019/12/26 18:28  Updated: 2019/12/26 18:28
Home away from home
Joined: 07/07/2009
From: Man Cave, Canada
Comments: 2402
this is great news! thanks to all involved & merry Christmas/ happy holidays :-)
Published: 2019/12/28 2:13  Updated: 2019/12/28 2:13
Just popping in
Joined: 01/10/2007
From: Stockholm Sweden
Comments: 103
Great news! Thank you to all involved and a happy new year!
Site sponsors
Advertise Here

Site statistics
Registered members
Logged in last:
  24 hours, 29
  7 days, 80
  30 days, 121

Top Posters
1 kas1e
kas1e 6354
2 Raziel
Raziel 3722
3 ChrisH
ChrisH 3553
4 samo79
samo79 3336
5 Chris
Chris 3240
6 orgin
orgin 3186
7 LiveForIt
LiveForIt 2799
8 Antique
Antique 2476
9 328gts
328gts 2402
10 Hans
Hans 2310

New Members
IconDesigner 08/05/2020
angelawhatson 08/05/2020
desrat 07/29/2020
tchomasz 07/22/2020
paulvandyk68 07/21/2020
madhumithasri 07/20/2020
Loggio 07/16/2020
htpmatt 07/04/2020
PlakativDruck 06/30/2020
devils_advisor 06/30/2020

Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project