OpenGL 3 Updates

[sqrt[-1]]

I am not sure what you are trying to say. Decisions like selecting the correct format for normal maps, height maps, font textures etc are simply unavoidable.

What I meant was if you are letting the driver decide the compression, it would need lots more info to decide what format to use. Say you have an alpha channel that is only black or white, you could use DXT1A type format, but a driver cannot make these decisions - only you know how the textures will be used and what trade off can be made.


So yes, a decision on a compression format still needs to be made, but it should be your decision, not the drivers.

[Korval]

It's not the same, but everything you can do with alpha test can be done with discard, and vice versa.

Not true. The thing about an alpha test is that it is an alpha test. That is, it tests alpha and determines pass-fail. Which means if the fragment passes, this is the alpha that will be used by the per-sample operations. Period.

Discard can be used on an arbitrary condition. So if don't discard, the alpha can be whatever you want it to be.

Still hardware, but it wouldn't surprise me if it would be removed in say DX11 or DX12 hardware.

You'll see alpha-test go away when you see depth tests go away. IE: never. It's minuscule hardware for a good performance gain.

[pudman]

That is, it tests alpha and determines pass-fail. Which means if the fragment passes, this is the alpha that will be used by the per-sample operations. Period.

Would it make senses to support GLSL semantics that support a construct such as this? I mean, would there be times when programmatically you'd want some value (other than alpha) to "be used by the per-sample operations" based on a condition (or strictly discard)?

Why not expound the alpha test to be more generic in line with the programmatic model?

It's minuscule hardware for a good performance gain.

But have there been other "minuscule hardware" improvements that, as a whole, if removed would simplify chip design?

Maybe this would be in line with a Mount Evans improvement? Getting rid of even more fixed functionality?

[tranders]

Seems like a slower, more annoying version of asking questions to me.

Nonsense. It's much more flexible.

By taking fully formed formats and returning yes/no, you have the ability to forbid things that are not easily quantifiable.

Hit and miss algorithms are highly inefficient and are definitely NOT flexible. GL3 should provide sufficient query capabilities (prior to actually attempting to create an object) so an application can pre-select a broad range of attributes that more than likely will succeed prior to beginning any committal of graphics resources.

I would only hope that the return is more than just yes/no and actually tells the caller why the format can't be created (e.g., "Insufficient graphics memory", etc.)

[Korval]

Hit and miss algorithms are highly inefficient and are definitely NOT flexible.

I don't particularly know what you mean by "inefficient" (we are talking about start-up code here), but I clearly disproved your "not flexible" thing by showing you a place where object creation clearly proved more explicit at showing limitations than simple queries.

GL3 should provide sufficient query capabilities (prior to actually attempting to create an object) so an application can pre-select a broad range of attributes that more than likely will succeed prior to beginning any committal of graphics resources.

First, a format object is not a "committal of graphics resources" by any reasonable measure. It's not even an object the actual GPU recognizes.

Second, even if you could query things, what would you do with that information? I mean, your format object creation code still needs to have fallbacks (as I described previously), so you may as well make format object creation your form of querying.

I would only hope that the return is more than just yes/no and actually tells the caller why the format can't be created (e.g., "Insufficient graphics memory", etc.)

After thinking about it for a while, I came to a certain conclusion. It just doesn't matter?

What exactly would you do with information like "the texture size is too big, considering the other format parameters?" I mean, is your format creation code going to be a tree of format possibilities? Where if it doesn't work one certain way, you try something else compared to if it didn't work a different way?

No. Odds are, it's going to be linear. A is the primary format. If A fails, try B. If B fails, try C. If C fails, there aren't any more fallbacks, so assert or throw an exception or something. It's really that simple.

So unless you can explain, with reasonable code, exactly what you intend to do with such information, I would have to say that it is superfluous. It's also the reason why FBO has a dozen different completeness failures for implementation-defined reasons, but only one for implementation-specific ones.

[Komat]

You'll see alpha-test go away when you see depth tests go away. IE: never. It's minuscule hardware for a good performance gain.

It is already gone from DX10 api. As Humus pointed out the discard operation has both greater flexibility and even in some current implementations it should have performance better or equal to the alpha test. There is no reason for the hw to waste transistors for dedicated alpha testing unit when the driver can append test&discard equivalent to the shader and get possible optimization bonus from that.

[Zengar]

Korval, you can't compare depth test and alpha test. Alpha test is a hack and absolutely superfluous on GPUs with fast discard. Actually, I won't be suprised if newest cards emulate it with shaders...

[Eric Lengyel]

[*]- Interleaved depth/stencil is a required format for FBO rendering

Thank you! That's right, don't let the slackers at a certain company (that shall go unnamed, but we all know who I'm talking about) skimp on FBOs any more because depth/stencil was left out of the original extension spec. I still have to support pbuffers because of them. >-(

[tranders]

I don't particularly know what you mean by "inefficient" (we are talking about start-up code here), but I clearly disproved your "not flexible" thing by showing you a place where object creation clearly proved more explicit at showing limitations than simple queries.

Being explicit does not imply efficiency.

I don't know how many different options are available to the format creation request, but the total number of possible failures is N-factorial (n!). A linear search over a permuted range of options is in no way efficient -- no matter how you look at it. Also, it is not always possible to perform these operations at startup.

What exactly would you do with information like "the texture size is too big, considering the other format parameters?" I mean, is your format creation code going to be a tree of format possibilities? Where if it doesn't work one certain way, you try something else compared to if it didn't work a different way?

If I know before hand that a particular filtering mode is not supported, why should I attempt to create a format only to have it fail? That would imply a decision tree. Very efficient. I should be able to determine from the API what my limits are without having to discover them manually or try to infer them from some bizarre series of failures. While fallbacks are required for any implementation, they should be the exception -- not the rule.

Programming by exception is NOT exceptional programming.

[Korval]

It is already gone from DX10 api.

Well that's good for them. Personally, I would rather that IHVs not have to deduce that I'm doing an alpha test from my glslang code. These are people who, after all, cannot even write a decent C-style language compiler after 2.5 years.

I don't trust them to detect that I'm doing an alpha test at the end and modify the pipeline accordingly.

A linear search over a permuted range of options is in no way efficient

So here's an idea: don't do that!

I mean, it's not like you don't have images on-disc in a particular format that you were planning to use this format with. You know exactly what this particular format needs to do. You know what your minimum requirements are for that format. So most of that range of options is totally useless for creating the format of interest.

Not only is a "linear search over a permuted range of options" inefficient, it is a broken algorithm. It may well create a format that you cannot use with those images.

So instead you lay out a series of format choices, from the least likely to succeed to the minimum. More than likely, you only have 1 fallback, but I could see 2 or 3 in some cases. And you try them. If the minimum fails, then the format can't be created and you exit.

For example, let's say you have a format that you intend to use for RGBA floating-point render targets. But it needs to support framebuffer blending. So, the minimum format you can except is FP16 with blending. The first one you try (if you want the precision and can accept the performance loss) is FP32 with blending. If that fails, then you try FP16. If that fails, you raise an error.

Rather than saying, "I want to implement my format creation algorithm like this," you should be looking at GL 3.0 and using that to inform how your format creation algorithm will work.

Also, it is not always possible to perform these operations at startup.

Maybe not, but it would only ever be so in a program like Maya, Max or some other tool where texture formats were controlled specifically by the user. And in that case, you would simply tell the user that the format is not available.

If I know before hand that a particular filtering mode is not supported

You misunderstood the question.

What you said was, "I would only hope that the return is more than just yes/no and actually tells the caller why the format can't be created." That is, if a format object fails creation, you can query the system as to a specific reason why it failed creation.

Therefore, the reason for failure will not be as simple as, "Filtering mode X is not supported." It will be "Filtering mode X is not supported when you use data format X of pixel size Y, etc". In short, it will not be something you can easily correct. It can't even be an enumeration; it would have to be some kind of string you would need to either parse or look at.