updated EXT_render_target spec (rev 2)

About time OpenGL had proper RTT! Good job.

One thing that will need to be addressed is the semantics for multiple contexts with shared objects. For example, what happens if two contexts attempt to bind the same render target object?

Given that deleting a bound texture will unbind it from the render target object, I believe that the answer to

An open question is what happens when both COLOR and DEPTH render targets buffers are set to zero.
must be that no output is produced. Leaving it undefined could lead to too many problems (especially if the undefined behaviour was to continue overwriting whatever piece of video memory used to belong to the texture).

Originally posted by Sunray:
Is rendering to floating-point textures supported, and is it vendor independent?
Sunray,

Yes. If the implementation supports float texture formats, then they can be rendered to. There’s a separate work in progress to provide float texture and color buffer formats to OpenGL 2.0 core. In the mean time, there are only vendor-specific float formats.

Thanks -
Cass

Originally posted by Christian Schüler:
[b]Questions according to Render-to-vertex-array:

(1) Which coordinates are you supposed to render to (x-coordinate, 0,1,2,3,…?)

(2) Can you render to integer render tagets and use them as vertex arrays (for instance, vertex color in RGBA32, or texture coords in 16-bit)[/b]
Hi Christian,

I’m honestly not sure what the right answer is on these issues. The objective with the RT spec is to make sure numerous options remain viable so that we can finish this spec (and ship an implementation!) and explore the right way to to RTVA next.

Thanks -
Cass

hi there,

i’m really happy of this new proposal especially for the new names … it seems that my cosmetic remark in 1st proposal thread lead to something :wink:

good work

Congratulations, this is becoming a very
nice extension, patching one of the few
major gaps left in the OpenGL.
I want to make 2 comments:

  1. I think that the FACE, LEVEL and IMAGE
    parameters should be per render-target-buffer
    rather than per render-target so that one
    to be able to change one of them only for
    the COLOR or DEPTH buffer without toching the
    other buffers. I don’t see why is this
    artificial binding of these parameters
    between the different render-target-buffers
    needed.
    For example we could have a function
    void RenderTargetBufferParameter(enum target,
    enum buffer, enum pname, T param);
    where target must be FRAMEBUFFER, buffer
    must be one of COLOR or DEPTH and so on.

  2. About the issue 27 in the extension spec.
    Please don’t use the GLhandleARB model!
    Don’t spoil the beautiful extension.
    IMO this GLhandle thing is a very bad thing
    in 2 ways: 1) it is unnecessary and very ugly
    patch to the OpenGL; OpenGL has a long-standing
    and well working with no problems model
    for managing objects, which is functionally
    superior to the handle mode (allows the
    application to managa the namespace itself).
    I think that it does not impose any extra burden
    to the OpenGL implementation to have one
    more type of objects because anyway it already
    must have the hashing stuff for transforming the
    user-managable object ids into internal
    pointers/whatever for the other objects
    (texture objs, program objs, buffer objs, etc)

  1. the user-managable namespace it is really
    a very useful thing thogh probably relatively
    rarely used because of the lack of such habits
    in the ISVs. An trivial example is when one
    has an convention that, say, the 1000-th texture
    object is the font texture for printing debug
    text on the screen, so that he could easely
    use it without bothering to pass various handles
    between different parts of the software.
    Another more complicated example is when one
    have user-written functions for manipulating
    textures (such as loading from file, setting various params, etc) which work directly with
    the GL texture object id rather than some user-defined texture objects and on the other
    hand the programmer can also use the ids
    directly with OpenGL calls like BindTexture,
    etc. One could have an convention that the high-
    order 8 bits of the id identify the texture
    type (2D, 3D, CUBE_MAP, etc.) and the low-order
    24 bits are an index in an array of descriptors
    or wahtever. The user-managable namespace is
    VERY useful thing. It’s not by chance that the
    best designed 2 APIs on earth have user
    managable namespaces of their objects, namely
    the OpenGL and the unix system API (the file
    descriptors there are such via the dup2 and
    fcntl(F_DUPFD) system calls)

About the issue 27 in the extension spec.
Please don’t use the GLhandleARB model! <etc>

Um, yeah. You believe in code obfuscation, correct? Because assuming the n-th texture object to be a font is definately obfuscated. How can anyone else, let alone yourself after 6 months, know that this special texture object is the font? And what if you want 2 fonts?

Supporting code obfuscation is bad. Clean code is good.

Certainly, the frequent use of hard linebreaks in your post points to being a fan of obfuscation :wink: Just kidding…

While, as a user, I prefer the handle approach, it really doesn’t matter that much. Future ARB extensions seem to be moving to the handle approach (re: superbuffers), so it wouldn’t be unreasonable to use it in this extension. But, this is a discussion that should take no more than 5-10 minutes of discussion time

Here’s a possible case in favour of making at least some of the calls compile into display lists: dynamic environment maps. If the dynamism was limited to parameter tweaking (e.g. shader consts) then all the rendering required to generate the environment map could be placed into a display list. However, one would need to change FACE_EXT 6 times inside the display list.

I think the comparisons in issue 25 are somewhat flawed, because the comparable functions are all WGL/GLX functions which AFAIK never get compiled into display lists. The other comparison is to TexImage, which sources client state (the texture data) while GenerateMipmapEXT doesn’t.

BTW how do these functions interact with gl(Push|Pop)(Attrib|ClientAttrib)? I notice the attribute field in the state tables is just given as ‘-’.

Originally posted by Korval:
[b] [quote]About the issue 27 in the extension spec.
Please don’t use the GLhandleARB model! <etc>

Um, yeah. You believe in code obfuscation, correct? Because assuming the n-th texture object to be a font is definately obfuscated. How can anyone else, let alone yourself after 6 months, know that this special texture object is the font? And what if you want 2 fonts?

Supporting code obfuscation is bad. Clean code is good.
[/b][/QUOTE]I’m not sure what you mean by obfuscation, but
it looks like you’re talking about the coding
style, right? If so, I think that the really
bad thing is when someone tries to impose his
own comprehension of the coding style. Note that
the standard OpenGL model of managing objects
lets you work as with handles (you have the
glGen* functions) while the opposite is not true
i.e. the standard model allows greater freedom
of coding styles.
It looks like you didn’t see my second example
which definitely is not as stupid as the first
one.

l_belev,
I have reason to believe that a driver-enforced numbering of objects allows some assumptions that ease driver implementation and tremendously help scalability of its object model.

A sparse numbering model can also be layered on top of a handle model, if you wish, inside the client application.

Originally posted by zeckensack:
[b]l_belev,
I have reason to believe that a driver-enforced numbering of objects allows some assumptions that ease driver implementation and tremendously help scalability of its object model.

A sparse numbering model can also be layered on top of a handle model, if you wish, inside the client application.[/b]
This sounds reasonable, I agree with you.
Still remains the aesthetical issue - IMO
introducing handles would greatly uglify
the otherwise quite stylish API.
I think that such a switch between the two
models should happen at once for all
the objects (textures, progs, etc.) at
some major version change (say in OpenGL 2.0)

Originally posted by Korval:
Um, yeah. You believe in code obfuscation, correct? Because assuming the n-th texture object to be a font is definately obfuscated. How can anyone else, let alone yourself after 6 months, know that this special texture object is the font? And what if you want 2 fonts?

Agree. That was not a good example. Many people (especially newcomers) used to do that, but noy anymore. In theory you could argue that by using fixed names you could save some storage and gain speed, but that’s so little that it’s irrelevant.

[b]Supporting code obfuscation is bad. Clean code is good.

While, as a user, I prefer the handle approach, it really doesn’t matter that much.[/b]
The one place where it hurts is in multi-threaded apps. You can only generate handles in a thread that has a bound context, which is usually not the thread you create your objects in.

Therefore I’d prefer being able to do my own management, but it’s not big enough a deal to make a big fuss about it. I just want to point out that there are legitimate reasons for wanting to do your own management.

Dirk

(10) Aside from attempting a drawing command, is there a way to determine if the current configuration is valid?
UNRESOLVED
Similar to glValidateProgram(), a newfunction could be added that returns a Boolean value indicating whether or not the current configuration is valid.
I am much in favor of this. Especially as the complexity of the extension increases (and maybe others get layered on top), the number of sources for possible errors in the configuration increases. Would be good to be able to easily find out if the error is in the RT-configuration.

Along those lines, is it possible for certain configurations to trigger a software fallback when rendering to a target or using it as a texture?
If so, it might be helpful to have IsRenderTargetNativeARB or something similar to ensure a fully hardware accelerated path…?

Originally posted by dirk:
[quote]Originally posted by Korval:
Um, yeah. You believe in code obfuscation, correct? Because assuming the n-th texture object to be a font is definately obfuscated. How can anyone else, let alone yourself after 6 months, know that this special texture object is the font? And what if you want 2 fonts?

Agree. That was not a good example. Many people (especially newcomers) used to do that, but noy anymore. In theory you could argue that by using fixed names you could save some storage and gain speed, but that’s so little that it’s irrelevant.
[/QUOTE]Dirk,
If you have something constructive to say
regarding the thread subject (EXT_render_target),
say it. Otherwise please don’t just fill the
thread with pointless noise.
This noise only makes the lifes of the interested
parties (cass) harder when they try to find
some useful ideas/comments in the thread.
If you wish, you may start a new thread about
how one should organise and write a software.
Or you may write a book about it, if you please
so.

You can only generate handles in a thread that has a bound context, which is usually not the thread you create your objects in.
Why/how are you creating objects in one thread and generating handles in another? I can understand wanting to create objects in one thread and use (as source data) them from another. But I don’t understand the purpose of creating a texture object, for example, without actually filling it with data. If you haven’t loaded the image into it yet, you certainly aren’t going to be using it. So there’s no point in allocating the object. In general, the act of generating handles/names goes in concert with filling those handles/names with actual data.

In your case, you’ve, presumably, developed some convention that gets around the cross-thread communication issue. While that’s nice, it is also bad programming practice. The way it should be done is that you query something that tells you which object the loaded data went into. A convention, rather than passing explicit names, you use makes it difficult to add to the convention system.

All your system does is get around needing a semaphore. A semaphore’s not that prohibitively expensive that one should avoid it with poor programming or esoteric conventions.

If you have something constructive to say
regarding the thread subject (EXT_render_target),
say it. Otherwise please don’t just fill the
thread with pointless noise.
He’s responding to your wish that EXT_render_target use the texture object mechanism rather than handles. He’s responding to your argument that this is a good thing. As such, it is very much on-topic.

Because the interface (texture object vs. handles) has very much to do with the structure of programs, it is hardly unreasonable for this to be involved in the debate. Indeed you were the one who brought it up, when you mentioned not having to pass around object names. You opened the door here; you can’t close it because someone else has a different, possibly more defensible, position in the debate from you.

Also, Dirk is arguing for your position.

Originally posted by Korval:

[quote]If you have something constructive to say
regarding the thread subject (EXT_render_target),
say it. Otherwise please don’t just fill the
thread with pointless noise.
He’s responding to your wish that EXT_render_target use the texture object mechanism rather than handles. He’s responding to your argument that this is a good thing. As such, it is very much on-topic.[/QUOTE]Really, how I didn’t noticed that :wink:
Seriously, he (as did you) speaks about things
that have little-to-nothing to do with the
concrete subject. Originally I meant that the
standard model offers reacher choice to the
programmer but not what exactly the programmer should choose or do. Then you stareted giving
lesons about how we must write and how we mustn’t
write software - THAT is off-topic. Do you see
the difference?

Also, Dirk is arguing for your position.
Even so, that doesnt change the fact that his (as yours) post was off-topic. And this thread has
very concrete subject - nvidia, apple & 3dlabs
are requesting comments about their new extension
but not about sombody’s particular habits and
comprehensions about organising a software.

as a summary about the hendles/no-handles issue
we can say this: if the overhead in the drivers
for doing the user-managable model is negligible
then it’s better to keep it, because it offers
reacher options for the application. If the
overhead cannot be ignored, then (of course)
the handles are better, because the extra
possibilities offered by the standard model are
relatively rarely used but the overhead is always
present. In this case if some app needs the
user-managable model, it can implement it itself
on top of the handles. I would suggest
to the OpenGL vendors not to mix both models
but to keep the old one until OpenGL 2.0 and
then switch at once for all objects.

Alternatively they could
add the handles without removing the old model -
the old model could be implemented on top of the
handles but in the driver for the sake of
backward compatibility (this way every object
could be accessed simultaneously via an handle
and an old-style object id - two new functions
for converting between the two things). So that
the apps who don’t need to manage namespaces
themselves could work directly with handles
with no overhead and the old apps and any new
ones that need that functionality still will
have it.

About the superbuffers: they are emerging to be
so cumbersome and heavy to work with that I would
suggest to the OpenGL vendors to chuck them up
altogether and to start all over. This new
extension looks like a very good start point.

Seriously, he (as did you) speaks about things
that have little-to-nothing to do with the
concrete subject. Originally I meant that the
standard model offers reacher choice to the
programmer but not what exactly the programmer should choose or do. Then you stareted giving
lesons about how we must write and how we mustn’t
write software - THAT is off-topic. Do you see
the difference?
No.

You’re arguing that handles are a bad idea (in general). I’m arguing that they are good.

Your arguments against handles and for numbers use bad programming techniques. Indeed, the best argument for handles is that they encourage good programming. As such, in order to argue for them, I must be able to discuss what is and is not good programming. Indeed, this argument also needs to get into why it is or is not good programming. If it is “off topic” to use these arguments, then I don’t have a case.

Put it this way. You say that the texture object mechanism allows for options. If you’re arguing for a mechanism because it allows for options, you are implicitly arguing that these options are both valid and benificial. Ergo, I should get to argue that these options are superfluous and/or promote bad programming. Otherwise, I could say that ripping out the object mechanism, forcing the user to go back to the days of 1.0, gives the user “options” too. Obviously, these are bad options, and you can make a case for it. As such, I get to make a case for why these options that you want are bad. And Dirk gets to make the case as to why they are good.

Otherwise, you are winning the argument because I don’t get to give my side of the case.

I would suggest
to the OpenGL vendors not to mix both models
but to keep the old one until OpenGL 2.0 and
then switch at once for all objects.
This is getting off-topic, but it bears noting. Apparently, GL 2.0 is not going to be a revision of the API, but instead the same kinds of difference between GL 1.4 and 1.5. Adding some things to the core, promoting ARB extensions, etc. So the handle vs. texture object stuff will be around for a while.

About the superbuffers: they are emerging to be
so cumbersome and heavy to work with that I would
suggest to the OpenGL vendors to chuck them up
altogether and to start all over.
I agree, except for the starting over part (abondon it. We’re getting what we need through this path). However, I doubt ATi will agree. It all depends on what happened in the March ARB meeting, but the notes aren’t up yet.

l_belev does offend quite some right from the start of his existance… good luck for getting accepted…

i’m all for the Gen functions. not because i actually like them, but because they are the way opengl works all the time.

in the end, in any real code, it happens to simply result in this

 GLuint id = -1; glGenX(1,&id); 

instead of this

 GLhandle id = glCreateX(); 

wow… that difference. the important thing to me is to be consistent. something, nvidia missed for a long time with their proprietary extensions, that simply didn’t fit the opengl style. now, this one IS an opengl style extension, and great work. superbuffers on the other hand… i don’t get them (both not in drivers, and not in brain:D).

hope we get this one, and soon.

By the way:
Why aren’t there any functions in EXT_render_target to query which textures are bound to a render target object? There is only GetRenderTargetParameter{if}vEXT… Am I able to query the textures with this function?

Originally posted by davepermen:
l_belev does offend quite some right from the start of his existance… good luck for getting accepted…

Ok, sorry for that if you interpret it this way,
but I was provoked. Note that I wasnt the first
to attack but at first I was attacked.
I’m never the first to start flaming someone, I’m
a big believer in the constructive cooperation.

Generally I assume that the people at this
forum are rationally driven rather than
emotionally driven, so in this sence I don’t
care much for things like acceptance for myself
as long as they are willing to accept any valuable
ideas no matter who is offering them.