No, it won't. It will basically cover the OpenGL 2.0 features. Multisample textures are likely to be introduced in the subsequent releases or as extension.
No, it won't. It will basically cover the OpenGL 2.0 features. Multisample textures are likely to be introduced in the subsequent releases or as extension.
I wouldn't be too sure about that.No, it won't. It will basically cover the OpenGL 2.0 features. Multisample textures are likely to be introduced in the subsequent releases or as extension.
The concepts of RenderBuffers and Textures are defined by the Format object. That is, you set a usage parameter on the Format object, which acts as something of a suggestion as to how you intend to use it (as a render target or a render source or both).
Obviously, format objects will need to be able to create render sources that can be multisample-able; this will get them up to speed with FBO renderbuffers. However, since it's just a format object parameter, it's entirely possible to express in GL 3.0 the desire to create an image that will be multisampled and be used as a render source (texture).
From there, it is up to the IHVs to actually make this format object work for the hardware that it can work on.
Yes, of course, but this is also possible in the current OpenGL (wth appropriate extension). I understoond the question as "will this feature supported out of the box?", and the answer is most probably no. GL3.0 has to be fully implementable on GFFX (or so we were told), and only G8x (ATI2xxx) and up support multisample lookup.
Yes maybe in the "Reloaded" time frame, but by Mount Evans for sure.
The folks calling the shots on this thing are aware of what the hardware can do, and Mount Evans has a minimum hardware requirement, thus I think it's safe to say we'll see those features in Mount Evans.
It's going to be one hell of a mountain.
Btw, I agree with what you said earlier, Zengar. Honestly I couldn't give a rats ass what language people use... just wanted to point out the console thing as something of an impediment at this point. But who knows what the future holds... I'd be willing to bet we'll see managed languages on those boxes too at some point down the road (sure would be nice anyway IMHO).
Since the initial release of OGL 3.0 won't include alot of the newer extensions will Nvidia and them release 3.0 specific extensions to enable those features or will we just have to wait however long it takes Kronos to get Mount Evans completed(I'm guessing a realllly long time..)?
I would think so.
They have a history of being quick to the gate with new hw features via extensions. After all, it's good for business.
So, if GL 3.0 has the expressiveness to specify, "make an image format for a multisample image that I intend to look up from", why would an IHV not allow a program to use it if the hardware is available?I understoond the question as "will this feature supported out of the box?", and the answer is most probably no. GL3.0 has to be fully implementable on GFFX (or so we were told), and only G8x (ATI2xxx) and up support multisample lookup.
Just because GL 3.0 has a minimum hardware requirement doesn't mean that it has maximum requirements. GL 3.0 won't require implementations to provide this, but it won't stop them either. Maybe Mt Evans will be where they actually require it, but you ought to be able to at least use it in 3.0.
Plus, unlike GL 2.1, you can actually test to see if you can do it.
I seriously doubt the IHVs will create stop-gap extensions for DX10 features. There's no point when those extensions will be deprecated in a few months.Since the initial release of OGL 3.0 won't include alot of the newer extensions will Nvidia and them release 3.0 specific extensions to enable those features or will we just have to wait however long it takes Kronos to get Mount Evans completed
It won't be that long. GL 3.0 is taking a while because it's an entirely new API; getting it right for future extensibility is hard.I'm guessing a realllly long time..
Most of Mt Evans features will drop into GL 3.0 without even API changes.
Because you will need new GLSL functions to read from such textures. You will need something like 'texture2Dms(sampler, coords, sample)'.
when used shader program in GL3.0,is it like this:
and when used multi-pass:Code :GLcontext ctx; ctx=glCreateContext(); program=glCreateProgram(ctx); vs=glCreateShader(GL_VERTEX_SHADER); gs=glCreateShader(GL_GEOMETRY_SHADER); fs=glCreateShader(GL_FRAGMENT_SHADER); glAttachShader(program,vs);//attached to program so contained in ctx glAttachShader(program,gs); glAttachShader(program,fs); ...//create other GL object for current GL context glBindContext(ctx);//bind the ctx as current active context of GL for rendering renderSence ... or vs=... gs=... fs=... program=glCreateProgram(); glBindProgram(program);//bind program object as a part of current context ...
Is right?Code :[i]create shaders for one pass[/i] program[0]=glCreateProgram(); [i]attach shaders to program[0];[/i] ... [i]create shaders for n pass[/i] program[n]=glCreateProgram(); [i]attach shaders to program[n];[/i] ... glBindProgram(program[0]); ... glBindProgram(program[n]); //bind program objects:program[0]~program[n] to current context