Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
46 user(s) are online (35 user(s) are browsing Forums)

Members: 0
Guests: 46

more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 ... 12 13 14 (15)


Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4520
@Daniel
Tested new library, results are : both irrlicht engine example and q3 with enabled extensions start to show things and almost works ! I.e. they works, just something with colors happens.

That how irrlicht engine looks like (our hacked binary at left, and non hacked, but over new patched ogles2.library, at right). It looks about correct, just colors differs (looks like endianes issues?). See in patched version it more "black", and hello world words at left-top are purple:

Resized Image
(press rmb in new tab for full size)

And that how looks like q3 with enabled extensions:

Resized Image
(press rmb in new tab for full size)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 121
@kas1e
With extensions enabled? Note that this first workaround-version only tackles the situation if you don't use VBOs of any kind (by that I mean ogles2 VBOs)!
So what this first workaround is supposed to patch is if e.g. gl4es does a call like

glVertexAttribPointer(1,4,GL_UNSIGNED_BYTE,TRUE,28,pointer_to_first_color);

where "pointer_to_first_color" is really a pointer and no VBO is bound. So it's the typical old-school vertex-data-via-client-RAM-pointer setup.

Your statement about "enabled extensions" somehow sounds as if you're trying to use VBOs? That's not done yet.

Anyway, for the above situation ogles2 already has to manage an internal (hidden) Nova-VBO. Therefore the workaround is not that hard (it only costs performance and RAM is being wasted):
if such a glVertexAttribPointer call is made, then copy-convert to float (incl. eventual normalization) and tell Nova that it now got std. floats in the internal VBO, instead of simply copying it over.

I have no idea where endian-issues should come from (just as I don't know why not supporting uchar8 x 4 has anything to do with any endian-issues in the first place).
For Nova those are simple floats now, just like e.g. the xyz coordinates.

Anyway, check out the fresh version on the FTP. I found a typo that probably was the reason for this ;)

   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1942
@Daytona675x

Sorry for the confusion. I'll do my best to clarify, and also correct what I've been saying (got myself confused too ).

1. The big endianness issue concerns VBOs containing data of mixed sizes. If you try mixing byte, 16-bit and/or 32-bit data in one VBO, then it will fail. However, stick a 16-bit index array in its own VBO (or a VBO with only 16-bit data), and it *will* work. I just checked the code, and that is handled correctly.

So the "32-bit data only" statement isn't strictly true any more, and hasn't been for a while. Will have to update that...

NOTE: DBOs are still 32-bit only.


2. The second limitation is that the driver used to treat all Vertex Attributes (VAs) as 32-bit floats. The latest beta sets the VA's attributes correctly now, so it'll treat ints as ints, uints as uints, etc.

This is where I got a myself confused because I thought the hardware would treat floats and ints differently. However, 32-bit ints and floats are handled the same way: they get passed on to the shader unchanged (i.e., int VAs must go to an int shader input). So, 32-bit int VAs have probably been working all along.

The latest beta also correctly sets the VA descriptor for 8 and 16-bit attributes, including whether it's normalized. So, it should work provided you restrict each VBO to having one data size only (8-bit data in one VBO, 16-bit data in another, etc.). I haven't tested that, though, because I'd completely forgotten that my endianness handler was a bit more sophisticated than "32-bits only." Let me know what happens if you try it...


Quick summary: restrict each VBO to data of one size each (8-bit data in one, 16-bit in another, etc.). The latest beta sets the VA descriptors correctly based on type, so VAs of all types might work provided the restriction above is observed (untested so far).

My apologies for the confusion and gaps/errors in the docs. I hope that it's clear now, and will update the docs.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4520
@Daniel, Hans
Quote:

Anyway, check out the fresh version on the FTP. I found a typo that probably was the reason for this ;)


Yes! Now irrlicht engine exampe and q3 with enabled extensions (so use the gldrawelements, not glBegin/glEnd route) works fine ! There current results:

640x480

q3_minigl_sdl1_capehill: 90.8 fps
q3_minigl_sdl2_capehill: 86 fps
gl4es_sdl1: 74 fps

800x600

q3_minigl_sdl1: 87.5 fps
q3_minigl_sdl2: 83.1 fps
gl4es_sdl1: 72.2 fps

1024x768

q3_minigl_sdl1: 82.2 fps
q3_minigl_sdl2: 76.9 fps
gl4es_sdl1: 68.5 fps


1600x1200

q3_minigl_sdl1: 67.5 fps
q3_minigl_sdl2: 68.9 fps
gl4es_sdl1: 60.2 fps


It's almost on the pair with mgl, just a litte slower (in 1600x1200 very close to be almost the same).

Tried also those letters fall to see if trashing gone: nope, it still here, so another issue somewhere else.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1942
@kas1e
Great news! Wish I'd thought of the existing Nova limitations sooner. Anyway, that's good progress.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 121
@kas1e
Great!
Did you check the performance impact of the workaround (by comparing it to a version where you did the ubyte-float-conversion of the color inside gl4es)?
Next to come is the workaround for VBOs. Do you have sth. for testing here too?

@Hans
Quote:
Wish I'd thought of the existing Nova limitations sooner.

And I wish I had not overlooked this limitation info in this readme

Quote:
Sorry for the confusion. I'll do my best to clarify, and also correct what I've been saying (got myself confused too ).

And sorry for my initial rant Although it's a real hefty limitation that came as a big surprise to me, it was my fault to miss the note in the first place.

Quote:
NOTE: DBOs are still 32-bit only.

Luckily that's no problem. The respective commands of ogles2, namely glUniformXX, only operate with 32bit-floats and 32bit-ints. So this limitation "only" affects VAs, and out of those only VAs that are defined via glBufferXXX and glVertexAttribPointer (the glVertexAttribXf functions only work with floats).

Quote:
Quick summary: restrict each VBO to data of one size each (8-bit data in one, 16-bit in another, etc.). The latest beta sets the VA descriptors correctly based on type, so VAs of all types might work provided the restriction above is observed (untested so far).

I could do this for the internal client-RAM-emu-VBOs, since I have full control over those. However I already made the workaround for that situation, which seems to work well looking at kas1e's latest feedback, which essentially patches the data when the emu-VBO is being built up internally, no need for extra VBOs here.

For "real" VBOs supplied by the user via glBufferXXX etc. this could be exploited though. However in my current wip workaround for this I already took another route:
when I detect that a VBO contains critical element-types, then I create one additional internal "sub"-VBO and copy-convert the critical data over to that one when a draw-call with that VBO is being issued and if there have been data modifications since the last sub-VBO-refresh. So it's one sub-VBO with x float-arrays for all x critical arrays of the user-supplied VBO.
Patching the original VBO is a no-go, of course. Just imagine the fun if somebody does a partial glBufferSubData...
Adding the patched arrays at the end of the original VBO is no good idea neither, this just complicates all the internal book-keeping.
The solution I'm implementing now is the "easiest" in this regards.

In both cases interleaved and linear memory layouts are supported, of course.

However, I won't put too much effort into optimizing those workarounds. I hope that this is only a temporary necessity and that it can be removed rather soon again

   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4520
@Daniel
Quote:

Great!
Did you check the performance impact of the workaround (by comparing it to a version where you did the ubyte-float-conversion of the color inside gl4es)?


In case with q3 exactly, in 1600x1200, differences is about 3fps. I.e. workaround done in ogles2 better, and give 3+ fps in compare when we has workaround in gl4es. Probably when it all will be done in hardware, in warp3d, and without workarounds, it will give us another little speed increase for few more fps ?

Quote:

Next to come is the workaround for VBOs. Do you have sth. for testing here too?


Not sure to be honest.. ptitSeb added some initial support of VBO some time ago, when we test q3, but at that time it give no speed differences at all (and i rechecked now, its still make no differences in quake3 at least), so i just think it didn't works at moment in gl4es.

As i understand all VBO support in gl4es for now emulated. And that what was added as "initiall support of VBO" , or not works , or works wrong. I will ask him about again, maybe now he can have a look at this more deeply.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1942
@Daytona675x
Quote:
Luckily that's no problem. The respective commands of ogles2, namely glUniformXX, only operate with 32bit-floats and 32bit-ints. So this limitation "only" affects VAs, and out of those only VAs that are defined via glBufferXXX and glVertexAttribPointer (the glVertexAttribXf functions only work with floats).

That'll change when uniform booleans are finally supported.

Quote:
However, I won't put too much effort into optimizing those workarounds. I hope that this is only a temporary necessity and that it can be removed rather soon again

Yes, hopefully.

@kas1e
Quote:
Not sure to be honest.. ptitSeb added some initial support of VBO some time ago, when we test q3, but at that time it give no speed differences at all (and i rechecked now, its still make no differences in quake3 at least), so i just think it didn't works at moment in gl4es.

I'm pretty sure that Quake III does NOT use VBOs. GL4ES might use VBOs when implementing the compiled vertex array extension, though.

IIRC, Nexuiz can use VBOs.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4520
@Hans
Yeah, i mean usage of real VBO in gl4es when compiled vertex array is used, and that should made difference in q3 as well when extensions enabled, and that what i test when says about VBO.

Anyway, ptitSeb say it isnt done yet, so all VBO in gl4es in whole only emulated for now, and that what was done as initial support of VBO, was just fast-test-hack, so -> no VBO at moment

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 121
@Hans
Quote:
That'll change when uniform booleans are finally supported.

Yes, if Nova / the damn SI then expects 1-byte DBO data internally (and from what you told me it will ), then this will become an issue. Luckily the respective DBO-update-code is well isolated inside ogles2 and integrating a type conversion of this kind should be rather (!) easy.

@kas1e
Quote:
In case with q3 exactly, in 1600x1200, differences is about 3fps. I.e. workaround done in ogles2 better, and give 3+ fps in compare when we has workaround in gl4es.

Hehe But yes, actually something like that was to be expected after looking at the workaround in gl4es. ogles2.lib does the conversion on the fly while copying the data to the internal VBO. That this is faster than to loop over the memory twice is no wonder.

Quote:
Probably when it all will be done in hardware, in warp3d, and without workarounds, it will give us another little speed increase for few more fps ?

Of course it will be faster to don't do those workarounds, but I can't say by how much. It depends on how often the respective game or lib triggers it per frame and how big the data is (that's of course also of interest when it comes to sending that stuff to VRAM, e.g. 4 bytes vs. 16 bytes per color per vertex). And it depends on how the game works: if a game would use true VBOs (which aren't modified all the time) then the impact would probably be near to zero, because all the conversion and sending to VRAM would ideally be done only once per polygon-soup.

Quote:
Anyway, ptitSeb say it isnt done yet, so all VBO in gl4es in whole only emulated for now, and that what was done as initial support of VBO, was just fast-test-hack, so -> no VBO at moment

Alright, then I'll stick do my boing-ball test for now

   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2011/6/3 12:49
Posts: 200
@kas1e

Do you have in mind new progs or games that may now be ported to OS4 with a working GL4ES ?


   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4520
@thellier
Quote:

Do you have in mind new progs or games that may now be ported to OS4 with a working GL4ES ?


In general everything opensourced, which fit our deps (like no XWindow, no QT5, no heavy boost usage, but which use SDL1/SDL2 and opengl up to 3.x).

Probably everything which done for minigl before and was slow can be reported for sake of tests, to keep those ones which will be faster. But in case with minigl probably better wait once Daniel's minigl-reloaded will be done. So everything will works over ogles2/nova, and no need to recompile (and gl4es version probabaly will be no faster than Daniel's minigl-reloaded).

From top of head the new things which can be ported over gl4es are:

New version of Blender (at least version 2.68 for sure was tested with gl4es, and it works. ptitSeb through didn't tests latest ones which needs shaders, but should work. Of course, if those shaders will not use arrays, as arrays in shaders didn't supported in nova at moment).

Everything which done over Irrlich Engine. Almost all examples from it already works, and i even ported supertuxkart 0.8.1, which half of working, but that not because of problems with gl4es, but because patches boredom in that version of supertukkart are ugly. They somewhere used "//", somewhere "\/", somewhere another way, and there no single rule, all looks like mess, but game in terms of rendering of graphics for sure works. Through, without game's shaders, as they use arrays, and nova didn't support them. But game can be runs without their shaders anyway.

Also those ones works over gl4es: Foobillard++, Zyn-Fusion, OpenRA tiberian sun, Astromenace , freeorion, Minecraft, OpenMW, SeriousSam (both First and Second Encounters), RVGL (ReVolt GL), parsec47 and so on.

In other words, there almost no restriction about opengl now, except one: shaders in Nova didn't support arrays, so, any opengl stuff which use shaders, which use arrays, will not works till arrays support in nova not done. In others: no restrictions anymore. Sure, some quirks can arise, but if they gl4es related ptitSeb fix it all fast always.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2007/2/1 13:02
Posts: 74
@kas1e

Thank you very much for your work
The amigaos4 needs a modern tool

   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4520
@sinisrus
All work there done by 3 persons: Hans, Daniel and ptitSeb. All i do its only put pieces together and report bugs, nothing more :)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1942
@kas1e

Quote:
All work there done by 3 persons: Hans, Daniel and ptitSeb. All i do its only put pieces together and report bugs, nothing more :)

You're undervaluing the work you're doing. Thanks to you we have a GL4ES port progressing, which will open up a lot of extra software. Plus, it's helped test GLES2 and Warp3D Nova more extensively, and that's resulted in both fixes and improvements.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top


« 1 ... 12 13 14 (15)



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project