Direct State Access

[kRogue]

The depth and stencil buffers are single buffered, that is why in both the double and triple buffered situations there is only one 32bpp. In practice this is also true. Indeed:

• A compositor does not use the depth/stencil buffers of an application. In fact, it does not even have access to those buffers.
• GL ES2 does NOT support read back of stencil and depth buffers

So in practice, only the color buffer is doubled (or tripled or whatever). The key point here being that the stencil and depth buffers are "private" data of an application, where as double or triple (or whatever) buffering is about what to render to so that a compositor (or a more low level part) can present it.

As a side note, if one really needs read back from the stencil and depth buffers of the previous and current frame separately, triple buffering _only_ happens on the color buffer, so the relative added memory is even lower as a percentage. The idea behind triple buffering the color buffer is so that neither the compositor or the application has to ever wait: the application chooses whichever buffer is "not the last one rendered to and not the buffer the compositor is presenting" and the compositor always presents the last buffer finished. Only locks are for updating those pointers/integers.

[Alfonse Reinheart]

Not exactly a lot more relatively speaking.

So you want to increase the overhead of simply drawing something by 20%. And even moreso if you take the bold and unorthodox step of wanting 32-bit colordepth. And how does antialiasing fit into that?

All to make initializing your application and buffer swapping slightly easier? Is that really worth it?

An application can choose to render at a lower resolution and have the compositor display at a larger resolution (it will get a touch blurry). A number of iPhone apps running on the iPad act this way.

Are you really saying that developers should compensate for the increased memory overhead of having a slightly easier to use API by making their apps look worse? This is a good idea?

It also unnecessarily hides the fact that for (1) we are really talking about a global memory manager, and all is needed is cross-process texture support to make everyone happy.

But that assumes that textures and render targets are the same thing. They don't have to be. Especially if there is the issue of swizzling involved in texture data storage.

I don't see a need to force them to be the same concept. Why should everyone who implements EGL be forced to run their OS's, compositors, and window managers exactly as you want? You'd basically be saying that anyone with code that doesn't work this way doesn't get to use your API.

And that's not a place one should put themselves. OpenGL ES and EGL lives on more than just smart phones and tablets. If going through a bit of boilerplate annoyance code means that other kinds of hardware can use those same APIs, why is that a bad thing? Should there be a special API for every single device? Is that somehow better for a programmer's life?

[V-man]

Texture Image specification: the glTexImage/glTexSubImage commands in OpenGL ES (1 and 2) are awful. The internal format of the texture is essentially set by the 6'th and 7th arguments together (format and type), and even that is only sort-of-ish.

Personally, I have not understood GL's glTexImageXD's internal and external format thing. Example : Why can you upload a floating point texture and have GL convert it to whatever you want?

From what I understand, GL ES's glTexImage2D has the same parameter list as GL but you can only upload texture formats supported by the graphics card. GL ES doesn't do any conversions for you.

Is that good or is that bad?
The more important question is why did they design GL 1.0 that way?

One might say "So what? A game developer does not care..." But a system does. Roughly speaking, a user interface should be drawn with GL on an embedded platform, you get every possible win: higher performance and lower power consumption. In that regard sharing image data across process boundaries: fonts, themes, etc is really a good idea.

What do you mean by "a system does"?
Lower power consumption? Perhaps you are talking about embedded systems. I was talking about a gaming API for desktops. Also, I am not saying bring "GL ES" as is to the desktop.

[kRogue]

So you want to increase the overhead of simply drawing something by 20%. And even moreso if you take the bold and unorthodox step of wanting 32-bit colordepth. And how does antialiasing fit into that?

All to make initializing your application and buffer swapping slightly easier? Is that really worth it?

Being almost lockless can be worth it. Additionally, the vast majority of embedded systems implement antialiasing at render time. To be precise: most of the embedded system are tile based renderers where the rasterization takes place on GPU in SRAM. Once a tile is completed that SRAM is blitted to the buffer target. For these systems the AA-resolve happens at that blit (roughly speaking). Going a step further, the color buffer can be AA for immediate mode renderers too (such as Tegra) with the knowledge that each color buffer is now 4-16 times as big, however this is likely a _bad_ thing. The wises thing would be that the color buffers are not-AA and an application does the AA-resolve themselves via a GL call. Also, keep in mind that very few(if really any) of the GPU's on embedded can even dream to handle AA rendering of large buffers or even intermediately sized buffers (the exception is ARM Mali where 4xAA is "free", but it is NOT to an AA-buffer, the resolve happens at the copy from SRAM to buffer target).

But that assumes that textures and render targets are the same thing. They don't have to be. Especially if there is the issue of swizzling involved in texture data storage.

What I am advocating does not at all assume they are the same thing. What I am advocating is to allow for textures and renderbuffers to be shareable across process boundaries. That makes no assumption about anything intrinsic to each of them. The functionality to use those is already part of a GL implementation.

I don't see a need to force them to be the same concept. Why should everyone who implements EGL be forced to run their OS's, compositors, and window managers exactly as you want? You'd basically be saying that anyone with code that doesn't work this way doesn't get to use your API.

..
Are you really saying that developers should compensate for the increased memory overhead of having a slightly easier to use API by making their apps look worse? This is a good idea?

I was not advocating that it MUST be a triple buffered approach. Rather I am advocating to view it as allocating buffers that are shared across process boundaries. The compositor and application agree on how. The triple buffering system is just one example. Another example could be single buffered where the compositor waits for for the application to finish a frame or even just uses it as is. The example of an app running in lower resolution that the present is another example. Right now with EGL, with API as is, it is single or double buffered with the same resolution as the presentation. As is, there is a difference between a surface and a pixmap. As is, for a compositor to work requires a number of odd things for a windowing system and GL implementation to provide which if not done *perfectly* will kill a system's performance. On the other hand, fessing up and saying it's about buffers (or really textures one renders to and renderbuffers) the whole jazz gets simpler for everyone: the system integrators, the application writes AND the driver makers. Compounding it, an application developer gets precise control too, via an API they are already using.

Personally, I have not understood GL's glTexImageXD's internal and external format thing. Example : Why can you upload a floating point texture and have GL convert it to whatever you want?

This was great in my eyes that a driver could choose to decide to change the format that helped it perform, again back in the days of fixed function pipeline, this was ok and cool. Now we have sized internal formats too, so we can potentially get the best of both worlds: precise control and/or let the driver decide. I freely admit the latter is not very popular or used often me thinks. The current GLES2 texture basically API killed this off: the understanding is that the format you feed the data into GL is the format of the texture but you cannot specify the texture internal format to guarantee what that format is.

As for converting data, my bet is that those that write drivers are likely going to do a much better job than most application developers. Additionally, a number of SoC's have dedicated silicon for blitting and converting formats. There is one place where format conversion I'd really rather let the driver do: to or from 16bit floating point formats. There are open source implementations out there, but really, who do you think is going to do a better job? My bet is on those that implement GL on the system especially in the embedded world where dedicated silicon for bits of functionality is the rule.

What do you mean by "a system does"?

Make a phone or tablet: you need a compositor, you need theme management, you likely want a browser. Each of these shares resources. The current model is that if you render the UI with GL, you need to replicate common data: fonts, images of themes, etc. That is insane. Throw in safer video decode the situation gets progressively worse.

I was talking about a gaming API for desktops. Also, I am not saying bring "GL ES" as is to the desktop.

Sorry for jumping the gun .. though I always figured GL3/4 core profile was meant to be that game-maker centric API.

[aqnuep]

The depth and stencil buffers are single buffered, that is why in both the double and triple buffered situations there is only one 32bpp.

Ah, actually I was thinking the other way around. I thought the color buffer is the one that you've referred to as 32bpp, but yes, you're right, only color buffer is required to have multiple buffers for double and triple buffer, however, isn't it that today's devices like iPhones and modern Android devices use 32bpp color buffer?

[kRogue]

Ah, actually I was thinking the other way around. I thought the color buffer is the one that you've referred to as 32bpp, but yes, you're right, only color buffer is required to have multiple buffers for double and triple buffer, however, isn't it that today's devices like iPhones and modern Android devices use 32bpp color buffer?

32bpp in portable world.. generally speaking that is for the high end (as of now). Indeed, the "color resolution" on many LCD screens are not exactly 24-bit . As one working in system integration, the vast majority times, it is RGB565, but that is for cheaper devices. For higher end we do/can see 24bit and for such devices there are occasion where RGBA8 runs faster than RGB565 (!).

For the Apple platform it was 18bit, then 18bit+dithering and now it is at 24bit take a gander at: http://www.edepot.com/iphone.html

Display Color depth

The number of bits used on the early iPhones to display a single pixel of color is 18 bits, with 6 bits used for each of the Red, Green, and Blue primary colors. 18 bits can provide a maximum of 262,144 colors (2^18).

Note that the standard on PC displays is True Color, using 8 bits for each of the primary colors, for a total of 24 bits per pixel. 24 bits can provide a maximum of 16,777,216 colors (2^24). The iPhone is outclassed by other mobile devices like the PlayStation Portable (PSP), which does use a 24 bit LCD display. The early iPhones are using very cheap LCD solutions to keep costs down.


The iPhone 3GS uses 18 bits plus hardware dithering. What this means is that compared to the iPhone 3G, it is still limited to 262,144 colors, but the iPhone 3GS has hardware that will try to place closely colored values in a pattern to "simulate" the intermediate value that it can't display directly. This will make the display "seem" to be able to display 24 bit True Color, when actually it can't. Starting with the iPhone 4 and the iPad, the display finally has the same quality of 24-bits per pixel seen on PC displays.

[V-man]

This was great in my eyes that a driver could choose to decide to change the format that helped it perform, again back in the days of fixed function pipeline, this was ok and cool. Now we have sized internal formats too, so we can potentially get the best of both worlds: precise control and/or let the driver decide. I freely admit the latter is not very popular or used often me thinks. The current GLES2 texture basically API killed this off: the understanding is that the format you feed the data into GL is the format of the texture but you cannot specify the texture internal format to guarantee what that format is.

As for converting data, my bet is that those that write drivers are likely going to do a much better job than most application developers. Additionally, a number of SoC's have dedicated silicon for blitting and converting formats. There is one place where format conversion I'd really rather let the driver do: to or from 16bit floating point formats. There are open source implementations out there, but really, who do you think is going to do a better job? My bet is on those that implement GL on the system especially in the embedded world where dedicated silicon for bits of functionality is the rule.

You can upload floating point textures and have GL convert it to RGBA8888.
Or You can upload a RGBA texture and have it stored as GL_ALPHA.
And whatever crazy thing you want to do.
That doesn't make any sense. That is a job for FreeImage or the DirectX Utility or whatever 3rd party library.

D3D's approach was the better one. Expose what the hardware supports and you can query D3D to find out what the hardware supports. There is no guesswork.

GL is the format of the texture but you cannot specify the texture internal format to guarantee what that format is.

Sure, people want guarantees. I want to know what the hardware can do so that I can feed it the data it needs and get the result that I expect.

[kRogue]

That is a job for FreeImage or the DirectX Utility or whatever 3rd party library.

and there is the rub that with which GL has always had to deal: there is not GL utility really to do it for you (in the DX case, Microsoft wrote the DX Utility, encourages you to use it and you can make a good bet they have optimized it). The current GL allows you to have precise control or to let the driver decide (but GLES does not really let you have either!). For me, I'd trust the driver writers more and in particular, in the embedded world there is likely a piece of silicon that might do the job faster than having the CPU do it.... also even if you do the conversion on CPU, in the embedded world the varieties of the ARM processor are staggering as such getting it highly optimized is not so easy.. but if the system provides it, then you can make a good bet that it will do the "right"/"fastest" thing for the conversion.

My 2 cents/opinion

[V-man]

Well, ARM processors and mobiles and all that are a different beast and I don't have any suggestions for them.

My suggestion was for a gaming API for the desktop (Windows/Linux/Mac). Don't tell me khronos can't handle it. They have been making several major APIs over the years.

[V-man]

The core profiles advantages at sucking
http://www.opengl.org/discussion_boa...389&page=1