Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 122 of 173 FirstFirst ... 2272112120121122123124132172 ... LastLast
Results 1,211 to 1,220 of 1724

Thread: OpenGL 3 Updates

  1. #1211
    Senior Member OpenGL Guru knackered's Avatar
    Join Date
    Aug 2001
    Location
    UK
    Posts
    2,833

    Re: OpenGL 3 Updates

    the index offset shouldn't be part of the object though - it should be part of the draw call.

  2. #1212
    Intern Contributor NeARAZ's Avatar
    Join Date
    Dec 2006
    Location
    Lithuania
    Posts
    51

    Re: OpenGL 3 Updates

    Quote Originally Posted by pudman
    As a comparison, no one complains (as vocally) about Microsoft's development of D3D behind closed doors. The reason is likely that:
    I think the reason is that D3D development is "open just enough". MS does go out to game developers and ask them what do they want, what they would like to be improved, and how. It does the same with IHVs. And with some people who are "important enough in graphics or D3D land" (this includes various well known graphics people, D3D MVPs, and so on).

    Yes, MS does act as the final aggregator/moderator of all the suggestions and wishes. And they get the stuff done.

    So to me, it seems as if OpenGL is not that much more "open" than D3D (*)... Except that OpenGL does not have a single authoritative decision maker, and does not seem to be able to get stuff done either.

    (*) Who is on ARB? IHVs and various "important companies / people". Who MS talks to when designing next D3D? IHVs and various "important companies / people". Find a difference.

  3. #1213
    Junior Member Regular Contributor
    Join Date
    Apr 2001
    Posts
    180

    Re: OpenGL 3 Updates

    Quote Originally Posted by knackered
    yeah, that doesn't sound like an ugly hack one little bit.
    You mean like detecting the name of the executable making the OpenGL calls to adjust the settings of the driver?

    Anyway, no, I don't think a caching mechanism is a hack.

    Quote Originally Posted by knackered
    the index offset shouldn't be part of the object though - it should be part of the draw call.
    Fair enough.

  4. #1214
    Senior Member OpenGL Guru knackered's Avatar
    Join Date
    Aug 2001
    Location
    UK
    Posts
    2,833

    Re: OpenGL 3 Updates

    Quote Originally Posted by Lord crc
    Anyway, no, I don't think a caching mechanism is a hack.
    If it's an unspecified implementation specific caching mechanism, then yes, it's a hack.

  5. #1215
    Member Regular Contributor
    Join Date
    May 2001
    Posts
    348

    Re: OpenGL 3 Updates

    Quote Originally Posted by knackered
    the index offset shouldn't be part of the object though - it should be part of the draw call.
    To be honest I'd prefer to see a single object that describes the mesh to be rendered - including the draw call parameters.

    Quote Originally Posted by knackered
    If it's an unspecified implementation specific caching mechanism, then yes, it's a hack.
    OpenGL specifies behaviour, not implementation (nor performance characteristics). Following your line of reasoning all implementations would just be huge accumulations of hacks by definition.

  6. #1216
    Senior Member OpenGL Guru knackered's Avatar
    Join Date
    Aug 2001
    Location
    UK
    Posts
    2,833

    Re: OpenGL 3 Updates

    true, what I should have said was that me writing code that relies on an IHV's possible caching mechanism to get the performance I need would be a hack.

  7. #1217
    Member Regular Contributor
    Join Date
    May 2001
    Posts
    348

    Re: OpenGL 3 Updates

    You're always relying on implementations being fast for the specific call sequence you're using. That's not a hack, it's implicit in the fact that OpenGL doesn't give performance guarantees. What the implementation does internally doesn't matter, it's the same whether it uses caching to avoid doing some work or whether it simply doesn't have to do much work at all.

  8. #1218
    Senior Member OpenGL Guru knackered's Avatar
    Join Date
    Aug 2001
    Location
    UK
    Posts
    2,833

    Re: OpenGL 3 Updates

    Completely re-specifying buffer bindings is likely to be expensive. Like swapping a texture used to be. To assume that the IHV has an implementation that doesn't make it expensive is a finger-in-the-air hack in my opinion. However, to have a mechanism whereby you do not need to completely re-specify buffer bindings is not a hack, even though no guarantees are given that it would be any faster. The fact is that the existence of the mechanism implies better performance, and will likely be mentioned as a motive for the mechanism in the specification for said mechanism.

  9. #1219
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: OpenGL 3 Updates

    What are vertex declarations for when you have GL's flexible setup.
    GL 3.0 won't be having that "flexible" setup, if the last information dump is any indication. There will be a vertex array object that explicitly defines what attributes it expects to use. That way, the driver can say, "Sorry, I don't support that," if you ask for something like unnormalized unsigned short that the implementation doesn't support. It also allows the driver to do the setup and verification stuff once and never again.

    Flexibility can get in the way of reasonable optimizations. And when it does, it needs to go away.

    You're always relying on implementations being fast for the specific call sequence you're using. That's not a hack, it's implicit in the fact that OpenGL doesn't give performance guarantees. What the implementation does internally doesn't matter, it's the same whether it uses caching to avoid doing some work or whether it simply doesn't have to do much work at all.
    The point is to be able to supply the implementation with enough information to be able to make reasonable optimizations. A driver that can't optimize the index offset will simply internally respecify pointers. A driver that has no overhead for pointer specification will simply respecify pointers. A driver that can optimize for it will.

    It is much harder to do this the other way, where a user simply respecifies pointers. You would have to ensure that each pointer was offset from the others, and offset by the same amount, based on parameters that can change. That's one of the reasons for OpenGL 3.0 to begin with: to be better able to communicate with the driver.

  10. #1220
    Junior Member Regular Contributor
    Join Date
    Apr 2001
    Posts
    180

    Re: OpenGL 3 Updates

    Quote Originally Posted by knackered
    If it's an unspecified implementation specific caching mechanism, then yes, it's a hack.
    Obviously, at this point, it'll have to be an extension in some form for it to be usefull in the way it was suggested. I guess my point was that it didn't have to be the way it is.

    Anyway, it's a bit academical at this point. If you're introducing a new extension, you might as well just introduce the extended draw call.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •