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 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Bindable Uniform Issues

  1. #1
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Bindable Uniform Issues

    I'd like to see a couple of the issues with bindable uniforms resolved, regarding packing (issue 2) and programmatic determination (issue 6).

    The spec authors are aware of the need, so I'm just bringing it to the fore in an attempt to bring some attention to the subject.

    All comments are welcome.


  2. #2
    Advanced Member Frequent Contributor cass's Avatar
    Join Date
    Feb 2000
    Location
    Austin, TX, USA
    Posts
    913

    Re: Bindable Uniform Issues


    DX10 does specify a layout, but due to some unfortunate alignment constraints, it's not the layout you might hope for.

    I think the ideal would be transparent access of structs between CPU and GPU and the ability to memcpy them around.

    There was some discussion of whether to match the DX10 memory layout or to leave it unspecified. It was an unfortunate decision (IMO) to leave it unspecified, because it just adds complex introspection where none would have been necessary.
    Cass Everitt -- cass@xyzw.us

  3. #3
    Advanced Member Frequent Contributor
    Join Date
    Feb 2006
    Location
    Sweden
    Posts
    744

    Re: Bindable Uniform Issues

    My preference would be just a big fixed data block that the gpu and CPU (though somewhat limited due to the fact it resides in the video memory) can freely read from and write to as either bits, bytes, floats(16, 32 and 64bit) or integers.
    Bindable uniforms would then just be a list of pointers to that memory structure.

  4. #4
    Advanced Member Frequent Contributor cass's Avatar
    Join Date
    Feb 2000
    Location
    Austin, TX, USA
    Posts
    913

    Re: Bindable Uniform Issues

    The main reasons you'd find naked pointers unpleasant are caching, memory layout, and pipeline synchronization.

    If you just had a naked pointer like VAR gave you, there is a lot less implementation flexibility on the driver / hardware side, and it puts the burden of synchronization and cache management on the app. Usually this means fences and uncached memory - both of which are teh suck for most apps.

    The level of abstraction we have in OpenGL buffer objects is actually pretty good. You can get a pointer which *may* eliminate a copy if the driver supports it, but in a way that may cause some automatic synchronization that is taken care of by the driver. Or you can send in-band updates via BufferSubData. And buffers can be renamed via BufferData. And finally, it provides an abstraction from raw bytes to formatted data (like texture images). If you had to know all the layouts in memory that formatted data can have and alignment constraints, etc, you would thank your stars for the pixel transfer path.

    Implementations of buffer objects have not been perfect, but having direct memory access is no panacea either.

    That said, direct memory access is very useful to those who need it and are willing to handle the extra burdens associated. For consoles, it's usually worth it because it's a fixed platform. For PCs in general, it's a much thornier situation.
    Cass Everitt -- cass@xyzw.us

  5. #5
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: Bindable Uniform Issues

    Just from a practical usage perspective, I think vec4 packing would be preferable to nothing at all. It's pretty easy to pack and pad structures out to match a shader, with any rule in place, but I can see the trouble in specifying this without bringing hw-specific terms into play, or becoming fixed to a packing scheme that may not be optimal now or at some point in the future. That's why I asked; the spec mentions the possibility of an extension to address this and it piqued my curiosity toward what it might look like.

  6. #6
    Advanced Member Frequent Contributor
    Join Date
    Feb 2006
    Location
    Sweden
    Posts
    744

    Re: Bindable Uniform Issues

    Yea, neither i like naked pointers, and to be honest i don't want just unrestricted DMA, I'm thinking more along the lines of a large array(of lets say 1KB of vec4) and that the pointers are really just offsets to that array, and reading/writing for the cpu would be done in a similar way in how the PBOs are done.
    But the main thing is that there is need for some persistent memory that all fragments has access to that is both read and write.

    @modus:
    I don't expect to see a fix for 2.x, instead i think it will be redesigned as core in either 3.0 or 3.1 using the new object model.

  7. #7
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: Bindable Uniform Issues

    Good point. It's possible that GL3 could introduce something that would affect this extension, and as far as I know Mt. Evans will make this extension (or something like it) core (if that's still the plan). But I reasoned it'll probably be Mt. Evans before any of this is set in stone so maybe now's a good time to discuss it.

    Cass touched on issue 3 (synchronization), which is also unresolved with respect to buffer interactions; e.g. ReadPixels and the relatively new texture buffer object extension. ReadPixels does seem to complicate things somewhat.

  8. #8
    Advanced Member Frequent Contributor cass's Avatar
    Join Date
    Feb 2000
    Location
    Austin, TX, USA
    Posts
    913

    Re: Bindable Uniform Issues


    I'm a little surprised by the amount of "GL3 could do this" kind of speculation that seems to be going on.

    As soon as the information stopped flowing, I think the logical conclusion should have been that there was nothing good to say. Any other conclusion is really foolishly optimistic. There's no reason to expect to be pleasantly surprised come SIGGRAPH.
    Cass Everitt -- cass@xyzw.us

  9. #9
    Advanced Member Frequent Contributor
    Join Date
    Feb 2006
    Location
    Sweden
    Posts
    744

    Re: Bindable Uniform Issues

    Quote Originally Posted by cass
    I'm a little surprised by the amount of "GL3 could do this" kind of speculation that seems to be going on.

    As soon as the information stopped flowing, I think the logical conclusion should have been that there was nothing good to say. Any other conclusion is really foolishly optimistic. There's no reason to expect to be pleasantly surprised come SIGGRAPH.
    True in this case it's more like a high probability that it will be done slightly differently(due to the new object model), however i wouldn't dare speculating on if it will be better or worse with openGL 3, just that they probably decided to push these issues forward a little.

    Remember, similar things where promised for FBO (that they will address certain shortcomings in future extensions), instead it was pushed to openGL3.

    My only hope for SIGGRAPH is that they will reveal some more info in it and/or even the finished spec.
    A simple example app would be more than enough.

  10. #10
    Advanced Member Frequent Contributor cass's Avatar
    Join Date
    Feb 2000
    Location
    Austin, TX, USA
    Posts
    913

    Re: Bindable Uniform Issues


    Anything short of a finished spec and a timeline for implementation availability would be a massive failure at this point, and they should really provide that before SIGGRAPH so that people could come prepared with detailed questions and issues to discuss.

    As it is, people are going to be expecting anything between GL 2.x and draft GL3 proposals with hardware support anywhere between DX9C class and DX10 class.

    If OpenGL spec management were being run by a single company, there would be no other way to look at the lack of real progress over the last couple of years and then fire them. I know and really like a lot of the people that work on OpenGL standardization, but the lack of progress really hurts OpenGL.

    But the hardware vendors themselves are also really hurting OpenGL. With the lone exception of NVIDIA, vendors don't have OpenGL drivers that match their DX9 hardware features.
    Cass Everitt -- cass@xyzw.us

Posting Permissions

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