PDA

View Full Version : updated EXT_render_target spec (rev 2)



cass
04-22-2004, 10:35 AM
Creating a thread for feedback on the latest public draft of the EXT_render_target spec.

ml
04-22-2004, 11:21 AM
This looks great and I can't wait to try it.

knackered
04-22-2004, 11:47 AM
Wow. So clear, so simple, so why did it take so long?
Cass, please can you tell us if this extension will be supported on nvidia hardware that currently supports standard RTT? Just juggle the driver around and bob's yer uncle?

Eric Lengyel
04-22-2004, 11:57 AM
Looks great. Just one thing -- don't forget to change

void glDeleteRenderTargetsEXT(GLsizei n, GLuint *renderTargets);

to

void glDeleteRenderTargetsEXT(GLsizei n, const GLuint *renderTargets);

(since the array pointed to by renderTargets is not modified).

-- Eric

cass
04-22-2004, 12:03 PM
Originally posted by knackered:
Wow. So clear, so simple, so why did it take so long?
Cass, please can you tell us if this extension will be supported on nvidia hardware that currently supports standard RTT? Just juggle the driver around and bob's yer uncle?Hi Knackered,

The plan is for this extension to be supported on all NVIDIA hardware. Certainly any hardware that supports standard RTT.

Thanks -
Cass

cass
04-22-2004, 12:15 PM
Originally posted by Eric Lengyel:
Looks great. Just one thing -- don't forget to change...
-- EricGood point, Eric, thanks! I'll pass that along to Jeff.

Cass

Jan
04-22-2004, 02:03 PM
Originally posted by cass:

Originally posted by knackered:
Wow. So clear, so simple, so why did it take so long?
Cass, please can you tell us if this extension will be supported on nvidia hardware that currently supports standard RTT? Just juggle the driver around and bob's yer uncle?Hi Knackered,

The plan is for this extension to be supported on all NVIDIA hardware. Certainly any hardware that supports standard RTT.

Thanks -
CassBesides the extension itself, this is the best news of the day :D

Is there any timeframe, in which we can expect first implementations to show up, or is this extension still too much in development?

There is one thing i don´t quite understand:

(18) Should there be N MRT-style depth textures?

What exactly does that mean? Does this extension support multiple render targets? I did´t understand it this way.
And what does this have to do with depth-textures?

Anyway, i would really really be happy, if multiple render targets will be supported (at least on hardware, which supports it).

Jan.

davepermen
04-22-2004, 02:14 PM
i really hope we'll see it on ati, but i dooupt it for the next time at least :(

not having the money to buy a 6800 anytime soon at all.. (and have to get one that works in an old xpc:D)

Corrail
04-22-2004, 03:54 PM
I really like the improvements of the second draft, mainly the framebuffer-objects. The extension didn't get much extra-complexity but is much more general. Great work, hope that this extension will be released soon (maybe for ATI, etc. too?).

cass
04-22-2004, 04:02 PM
Originally posted by Jan:
Is there any timeframe, in which we can expect first implementations to show up, or is this extension still too much in development?
Unfortunately there's no way to give a timeframe right now. Discussions with other ARB members may still affect the final form of this extension.



There is one thing i don´t quite understand:

(18) Should there be N MRT-style depth textures?

What exactly does that mean? Does this extension support multiple render targets? I did´t understand it this way.
And what does this have to do with depth-textures?
You probably shouldn't worry about this. We plan to allocate multiple sequential enumerants for color buffers for MRT (but a separate extension will enable *using* that functionality). The question was really about whether we should do the same for depth. The answer for now is no. You need something more than "MRT" for this to be useful, and no hardware that exists today supports multiple output depths and/or depth buffers. (At least none that I'm aware of.)



Anyway, i would really really be happy, if multiple render targets will be supported (at least on hardware, which supports it).

Jan.The extension that enables MRT will be very simple, and you should expect support to happen at the same time or very shortly after real implementations of this spec show up.

Thanks -
Cass

Stephen_H
04-22-2004, 04:40 PM
Regaring issue #12:



(12) If a texture is bound for both rendering and texturing purposes, should the results of rendering be undefined or should INVALID_OPERATION be generated at glBegin()?

UNRESOLVED
Undefined results allow an application to render to a section of the texture that is not being sourced by normal texture operations. However it is highly desirable to define results in all cases, even if the result is defined as an error.
I realize that the results are undefined, but this kind of functionality is useful for things like building summed area tables, doing digital filtering, image processing, and other kinds of non-conventional usages for the GPU.

For game programming, I can understand that you might prefer an INVALID_OPERATION... but for other types of applications, we have a pretty good idea of when one area of the texture hasn't been written to in a sufficiently long while that it can be used as a source for another area of the texture... because we are accessing different areas of the texture in some predictable algorithmic fashion rather than an arbitrary way like most game applications would.

Perhaps you could make the error behaviour toggleable... so applications could choose if they want to receive an INVALID_OPERATION error or not.

cass
04-22-2004, 04:51 PM
Originally posted by Stephen_H:
I realize that the results are undefined, but this kind of functionality is useful for things like building summed area tables, doing digital filtering, image processing, and other kinds of non-conventional usages for the GPU.
[...]
I'm not sure whether there's precedent for it, but perhaps INVALID_OPERATION could be set, but it could still allow potentially useful undefined behavior via an NVEmulate kind of check-box.

I appreciate the desire to play with features like this, but using them reliably from one architecture to the next (or even one driver version to the next) is pretty much impossible.

Things like caching mess things up.

In general, while I would like to allow naughty behavior for experimentation and research, I (and pretty much all IHVs) worry that people will come to rely on behavior that is unsupported and fundamentally unreliable.

Thanks -
Cass

edit: clarify last paragraph

plasmonster
04-22-2004, 08:10 PM
This blows the socks off the whole wgl mess, both in terms of the simplicty of the spec, and the clean usage model - very nice indeed.



Another idea is to add a render target parameter that magically adds an accumulation buffer to the render target object.
I'd be intersted to see if you can pull this one off. :)

zeckensack
04-22-2004, 08:36 PM
Issue 7:
An open question is what happens when both COLOR and DEPTH render
targets buffers are set to zero.Wouldn't it be sensible to just not produce any results? Just like what happens if you go
glDepthMask(0);
glColorMask(0,0,0,0);
glStencilMask(0);
glDisable(GL_DEPTH_TEST);
glDisable(GL_STENCIL_TEST);Unless I misunderstood this issue, or there's some interaction with other functionality (feedback, histogram?) I don't see why there would be much debate over this.

edit:
added stencil state, added depth test - I know it's redundant, it's just supposed to be extra obvious

Korval
04-22-2004, 11:39 PM
Good stuff. Objects out of the box.

While the lack of forced relaxation of the size restriction is unfortunate, it is also understandable... as long as there is a relaxed extension available from Day 1.

Oh, and if it matters, I support the


glRenderTargetBuffer(GL_FRAMEBUFFER, GL_COLOR, GL_BUFFER_OBJECT, buffer_obj);syntax for using VBO's as render targets. It looks like what should be happening: you're binding the buffer object to the frame buffer as a render target.

BTW, this extension also nicely deals with copying data from/to various textures (and with VBO, buffer objects).

Build this, and superbuffers is utterly superfluous (pretty much. VBO provides the memory allocation ability, and EXT_RTVA provides everything else). Plus, we don't need another way to bind vertex arrays ;)

Do all this (and fix your GLSlang impl to be perfectly conformant ;) ), and I could easily see myself picking up a nice NV4x card. I'll never justify a $500 purchase, but a nice mid-range $200 card would work...

Christian Schüler
04-23-2004, 01:46 AM
Perfection is reached when you can't take away any more thing ... good work!

Ah, and watch those const-correctness!

Corrail
04-23-2004, 01:53 AM
Originally posted by Korval:
Oh, and if it matters, I support the


glRenderTargetBuffer(GL_FRAMEBUFFER, GL_COLOR, GL_BUFFER_OBJECT, buffer_obj);syntax for using VBO's as render targets. It looks like what should be happening: you're binding the buffer object to the frame buffer as a render target.This would be nice and easy but how does the driver know which internal-format you use and how many components per Pixel, ... ?

Overmind
04-23-2004, 02:26 AM
Why not just making a buffer object, making a texture in it, rendering to it and then binding it as VBO?

Sunray
04-23-2004, 03:23 AM
Is rendering to floating-point textures supported, and is it vendor independent?

Christian Schüler
04-23-2004, 04:21 AM
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)

Bruce Merry
04-23-2004, 06:09 AM
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).

cass
04-23-2004, 06:13 AM
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

cass
04-23-2004, 06:18 AM
Originally posted by Christian Schüler:
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)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

glitch
04-23-2004, 08:04 AM
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 ;)

good work

l_belev
04-23-2004, 01:48 PM
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)
2) 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)

Korval
04-23-2004, 04:55 PM
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 ;) 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

Bruce Merry
04-24-2004, 12:39 AM
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 '-'.

l_belev
04-24-2004, 02:08 AM
Originally posted by Korval:

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.
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.

zeckensack
04-24-2004, 04:59 AM
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.

l_belev
04-24-2004, 05:50 AM
Originally posted by zeckensack:
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.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)

Dirk
04-25-2004, 08:28 AM
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.


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.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

Dodger
04-25-2004, 10:04 AM
(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...?

l_belev
04-25-2004, 02:20 PM
Originally posted by dirk:

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.
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.

Korval
04-25-2004, 03:43 PM
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.

l_belev
04-25-2004, 04:40 PM
Originally posted by Korval:

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.Really, how I didn't noticed that ;)
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.

l_belev
04-25-2004, 05:25 PM
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.

Korval
04-25-2004, 07:20 PM
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.

davepermen
04-25-2004, 10:08 PM
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,&amp;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.

Corrail
04-26-2004, 01:20 AM
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?

l_belev
04-26-2004, 02:36 AM
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.

l_belev
04-26-2004, 04:05 AM
Originally posted by Korval:
No.

You're arguing that handles are a bad idea (in general). I'm arguing that they are good.
I'm not arguing that the handles are bad idea at all. I think i made my thesis perfectly clear so I'm not going to repeat it yet again.



Your arguments against handles and for numbers use bad programming techniques.Again my arguments are NOT against the handles but in support of the old-styled objects ids. There is a difference.
These "my arguments" were quite arbitrary examples what I thought of at the moment. The first one indeed was stupid, but it seems you didnt read the second one at all, for if you did I'm sure you would agree that it's far from being a bad programming technique even for your criteria.
Even if these examples are not good, it does not mean that good examples doesn't exist (only because we weren't able to think of them at the moment). But again, see the second example.



Indeed, the best argument for handles is that they encourage good programming.Man, can't you accept that what you call "a good programming" is not an universal constant as the value of pi. The definition of "a good programming" or "a clean code" does vary from one point to another in the time-space continuum bla-bla.
I would once again suggest to you not to try to impose your opinion in this matter to the others, and to permit others to have their own opinions.

BTW Dirk, I'm sorry for flaming you, I take back my words.

dorbie
04-26-2004, 04:12 AM
On handles, the central issue is caching of hardware resident resources so you're always going to need a context for that.

davepermen
04-26-2004, 06:34 AM
Originally posted by l_belev:
Note that I wasnt the first
to attack but at first I was attacked.
no one is ever the first :D :D

yeah, this forum is quite fine. still, you had quite a ... "good" start in here:D

i'm still waiting for an ati implementation... lets bomb devrel@ati.com to implement it:D

bobvodka
04-26-2004, 07:09 PM
an ATI impl would be nice, but i think we'll have to wait for the spec to be completed first ;)

jcabeleira
04-27-2004, 09:11 AM
I just wanted to say that this new extension seems to be great! I just can't understand how something like this wasn't created sooner.

i'm really looking forward to see this extension at work, please make it avaiable as soon as possible!