By the way, for the next Pipeline there is going to be a segment about "GL2 to GL3 migration". I'd like to hear about specific areas of developer curiosity to try and cover those in some detail where possible, we could conceivably even air some of them briefly here and then in more detail in the Pipeline piece.
That'd be great. I'm sure we'd all like to see some sample code and get a sneak peak at some of the more radical changes we're in for.
Thanks for the update and the good news!
FP16:
GeForce FX, Radeon 9, Radeon X - no filtering, no blending
Radeon X1 - blending supported
GeForce 6, 7, 8, Radeon X2 - filtering and blending supported
So basically if you implement HDR you have to provide one implementation for GeForce 6/7/8 and Radeon X2 and one separate implementation for Radeon X1.
In my game I perform multiple tests at beginning to determine if FP16 blending/filtering is supported, if it runs reasonably fast and if it crashes or not. Then I know which HDR implementation to use if any.
This has been discussed many times, so I don't want to go off topic here. I hope life will be easier for us in future. Right now it's "test if it really works before you use it".
Yes, some way to ask what level of FP support is available would be vitial imo.
Shouldn't alpha test be removed? You can easily simulate all possible alpha test modes using texkill functionality in the fragment shader.Originally Posted by Khronos_webmaster
Asking questions. That's so DirectXYes, some way to ask what level of FP support is available would be vitial imo.
In GL 3.0, you simply try to make a format object of the appropriate type. Part of the format object is a specification of what you intend to do with the images you create from it (bilinear filtering, anisotropic, etc). If, when you create this format, GL says, NO, well, you can't do it.
No. It's much faster to have real alpha test than to do it in shaders. Plus, alpha test can be per render target (eventually). Plus, you can easily mix and match alpha test without having to write shaders for it.Shouldn't alpha test be removed?
It's not just that.
Try writting a vertex shader that's compatible with clip planes and works on all hardware supporting GLSL.
On GeForce you need to write to gl_ClipVertex, otherwise it won't work. On some Radeons you can't write to gl_ClipVertex - it causes software mode.I'm using #ifdef for that.
Doh! You got me talking off-topic again
GL3 will make this easier to assess by way of the format object mechanism as Korval noted. However the per-GPU-type outcomes you list above aren't likely to change, because the root issue is in the hardware.
Yes, format objects are something I await with great anticipation. I hope it will be sufficient solution not only for supported-unsupported problem, but also for software-hardware problem
Even worse, sometimes EXT variants work better than ARB ones or vice versa, and there really is no way to test at runtime which implementation works reliably. Format objects FTW!This has been discussed many times, so I don't want to go off topic here. I hope life will be easier for us in future. Right now it's "test if it really works before you use it".
Anyway, some possible discussion topics regarding migration issues:
1) How will a GL3 render context be created? Assuming that creation will still go through the wgl/glx/agl/cgl API's, how will one be able to distinguish between GL2 and GL3 contexts?
2) Regarding multisampling, will there be any changes to the (context creation/format query/context destruction/final context creation) round trip?
3) What are the changes in VBO creation, binding and drawing?
4) Which functions require the consumer to keep data on client memory? (For example, in GL2 vertex arrays are the responsibility of the consumer, which can be problematic in garbage collected environments - VBO's don't suffer from this issue).
5) This is possibly what I'm most interested in: Will the new .spec files be available, to ease creation of bindings for other programming languages? Any chance for the wgl/glx specs?
Posting Permissions
