Windows in OpenGL ES or OpenGL ES in window?

General discussion about anything related to Ultibo.
pik33
Posts: 852
Joined: Fri Sep 30, 2016 6:30 pm
Location: Poland
Contact:

Windows in OpenGL ES or OpenGL ES in window?

Postby pik33 » Fri Dec 14, 2018 2:12 pm

Windows in OpenGL ES or OpenGL ES in window - that is the question :)
-------------------------------------------

After several days of exploring I hope I have all ingredients now to run OpenGL ES screen in a Retromachine window manager window.

Then I thought about moving all the window manager to OpenGL ES environment, freeing the CPU from image related tasks.

The worst restriction I encountered is the max number of texture image unit which is only 8. This means you can have only 6, maybe 7 windows on the screen, no more, without using tricks

This also explains no Raspbian openGL ES accelerated window manager and all the effort to make full OpenGL to work on RPi (I never got it working - switching to OpenGL driver causes black screen and nothing else)
Gavinmc42
Posts: 1555
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Windows in OpenGL ES or OpenGL ES in window?

Postby Gavinmc42 » Sat Dec 15, 2018 5:43 am

Is this a hardware limitation or set in start.elf to save memory?
Anyway 8 is still pretty good for lots of things :D

Overlaying OpenVG over the top of OpenGLES will make for interesting GUIs.
I see Ultibo more as a single purpose mission OS, not a General Purpose OS.
But once we can compile Ultibo on itself then those extra Windows might be useful ;)
Hans
Posts: 14
Joined: Mon Feb 06, 2017 7:28 am
Location: Europe

Re: Windows in OpenGL ES or OpenGL ES in window?

Postby Hans » Mon Dec 17, 2018 8:03 am

do you mean it's not possible to have more than eight texture bitmaps loaded at any one time, or is the limit you encountered with reference to the maximum number of GL-ES windows you can have opened at any one time?
pik33
Posts: 852
Joined: Fri Sep 30, 2016 6:30 pm
Location: Poland
Contact:

Re: Windows in OpenGL ES or OpenGL ES in window?

Postby pik33 » Mon Dec 17, 2018 5:10 pm

It seems to be 8 textures limit. Bitmaps are up to 2048x2048 and this is good.

It also seems to be hackable but I have to experiment first

Possible hack #1: use cubic texture. It occupies one slot and has 6 bitmaps.

Possible hack #2: maybe textures can be reloaded between objects. Load texture-draw object-load texture-draw object
Gavinmc42
Posts: 1555
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Windows in OpenGL ES or OpenGL ES in window?

Postby Gavinmc42 » Tue Dec 18, 2018 12:01 am

It seems to be 8 textures limit. Bitmaps are up to 2048x2048 and this is good.

That's is still very usable for game stuff ;)
Minecraft type blocks are 32x32 pixels, so a 2048 x2048 bitmap is 4096 block textures or 682 cubes with different textures on each side :D
Some texture optimising maybe needed for large number of polygon limits.
How much the textures can be baked and reused will come into play.

It might be an issue for trying to do Windows or X11 type windows, but I don't see many multitasking applications as Ultibo's main use.
4K image slide shows maybe. At full HD this is about 8 x double buffered screens.

The limit for EGL screens is 128/256?
pik33
Posts: 852
Joined: Fri Sep 30, 2016 6:30 pm
Location: Poland
Contact:

Re: Windows in OpenGL ES or OpenGL ES in window?

Postby pik33 » Tue Dec 18, 2018 7:07 am

The real limit is RPi's memory bandwidth; no more than 3 dispmanx fullhd layers, or maybe 5 if overclocked. Every dispmanx layer eats the bandwidth and makes the RPi slower. This means if you don't need a framebuffer, destroy it.
pik33
Posts: 852
Joined: Fri Sep 30, 2016 6:30 pm
Location: Poland
Contact:

Re: Windows in OpenGL ES or OpenGL ES in window?

Postby pik33 » Fri Jan 04, 2019 7:02 pm

Now the answer seems to be: windows in OpenGL

RPi allows direct accessing the texture memory. Its structure is strange, but the first version of putpixel is done now. Putpixel is the base or all other graphic procedures like circle, line or putchar. They are ready: you change putpixel, all the rest will work.
Using a simple trick, the max texture size for 8-bit screen is 8192x2048. There is 8 teture slots. 8192x2048 allows to allocate several windows on it: the allocating algorithm has to be written. The windows height will be restricted to 2048 pixels but it is not very tight restriction.

Considering both of these it seems that OpeNGL ES window manager is doable. It will work in 8-bit depth and some tricks allowng more than 256 colors on the screen at once. The size and amount of windows wil be restricted to fit on one or maybe two 8192x2048 textures. To make true color windows also available, one of the texture slot may be reserved for such a window; the size restriction is 2048x2048.

Using graphic procedures directly on the texture memory allows to avoid massive (and slow) memory copy every frame. The texture will be sitting there. If the window is not changed, the texture doesn't need to be uploaded every frame. You don't need to care about what part of the window is visible: the OpenGL ES will do it. If you want to put a character to the window, you change several bytes directly in the texture memory and the character wil be displayed after the next vblank.Ths wll remove all the heavy CPU load my current window manager uses to refresh the screen. Let the GPU do this instead. And then let the GUI run on Zero, it has exactly the same GPU as 3B+ :)

So it seems I will use 4 texture slots for the window manager. There wil be 4 more left if someone wants to draw some objects.

The work (or maybe play) is now in progress.
Gavinmc42
Posts: 1555
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Windows in OpenGL ES or OpenGL ES in window?

Postby Gavinmc42 » Sat Jan 05, 2019 8:32 am

Nice idea with 256 colour mapping.

You want to try texture compression next?
https://www.raspberrypi.org/forums/view ... 0#p1412070

Those TMU sound interesting, I actually know what this means now :D
Each TMU performs programmable filtering and automatic level-of-detail (LOD) determination when mipmap
textures are used.


Each TMU is ‘virtualized’ and therefore can theoretically sample from an unlimited number of textures in any
given shader. The shader program passes the TMU all the setup data it needs (texture base address, format
wrap modes etc.) at the same time as the sampling information using uniforms.

Unlimited?

The memory organization of most texture types is T-format or LT-format, with LT-format automatically selected
for smaller size textures. The texture units also support raster format 32-bit YUYV and RGBA textures, allowing
video and image data to be directly used as a texture without needing conversion to T-format. Finally, the TMUs
can also be used for general 32-bit data lookup using a direct address.

Hmm mostly makes sense, wish I knew how to use it :oops:

I supect that video and image format with be handy, is it the secret to Openmax?
pik33
Posts: 852
Joined: Fri Sep 30, 2016 6:30 pm
Location: Poland
Contact:

Re: Windows in OpenGL ES or OpenGL ES in window?

Postby pik33 » Sat Jan 05, 2019 2:16 pm

You want to try texture compression next?

No, not this time. Compression needs time to compress and/or introduces artefacts. I don't want any artefacts and I am fighting for speed. The idea is: to allocate a texture and then put pixels directly to it, when needed, to avoid copying all textures from CPU area to GPU area every frame.
Gavinmc42
Posts: 1555
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Windows in OpenGL ES or OpenGL ES in window?

Postby Gavinmc42 » Sun Jan 06, 2019 1:55 am

Compression ie S3TC(Direct X) seems to be for games.
ETC1 for OpenGLES/Android.

Precompressed for games, hardware decompressed on VC4?
aprox 4 times less memory moving around ;)

Return to “Discussion”

Who is online

Users browsing this forum: No registered users and 0 guests