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 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: mutable texture formats

  1. #11
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,135
    I personally think you're being a mite paranoid, not to mention showing some prejudice, over this. I wouldn't try to defend COM as an architecture - it's ghastly - but COM itself has nothing in it that prevents portability. It just uses standard C/C++ constructs, and as such can be implemented on any platform. This kind of approach only serves to weaken your argument. That aside, you seem to be missing the documentation for D3D11_RTV_DIMENSION, D3D11_SRV_DIMENSION, etc, which is the crucial part that implements the cast.

  2. #12
    Junior Member Regular Contributor
    Join Date
    Apr 2004
    Posts
    228
    in d3d you create render target view by specifying texture and region in this texture, i.e. face for a cube texture, a slice for a 3d texture and array texture, etc. then bind the view as render target.
    in opengl you do all this at once - the command with which you bind the color/depth/stencil buffer also takes parameters that specify which face, which slice, etc.
    how is the opengl's direct way worse than the views?
    in d3d you have additional objects to work with, which is more code, more opportunities for bugs (like leaks if you forget to release them), etc. for no benefit over opengl. don't you agree?

  3. #13
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,135
    I'm not commenting on whether the implementation is good or bad, just on what appears to have been the thought processes behind it. Personally I can see the utility of views in D3D, from the perspective of D3D's own capabilities, but feel that the current implementation of them is a lot clunkier than it should have been. But that clunkiness does not take away from the utility, and nor does the utility of a D3D-specific implementation of something mean that GL should implement the same thing in the same way (or vice-versa, of course).
    Last edited by mhagain; 07-19-2012 at 08:55 AM.

  4. #14
    Junior Member Regular Contributor
    Join Date
    Apr 2004
    Posts
    228
    I was not arguing that their views are a bad implementation, but that they are useless in principle
    Anyway there is really no point to argue over this, doesn't matter.
    I only hope the GL design guys wont take example from microsoft how to do it, should they wish to add such feature in the GL.

  5. #15
    Junior Member Regular Contributor
    Join Date
    Apr 2004
    Posts
    228
    It seems they actually added this functionality in 4.3. They did it in somewhat more complex way than what I was hoping, but it's still better than microsoft. At least we don't have new kind of objects.

    I would rather have them called "texture aliases" than "texture views". that would be more correct as thats what they actually are. also would be less copycating-of-dumb-microsoft-terms. Oh well.

  6. #16
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Quote Originally Posted by l_belev View Post
    I would rather have them called "texture aliases" than "texture views".
    Well, there not really aliases. Yes, they can be called so if you only change the interpreted internal format, however you can also select a subrange of mip levels and layers thus you actually select a subset of the texture images inside the texture. This way the "view" term is more appropriate.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  7. #17
    Junior Member Regular Contributor
    Join Date
    Apr 2004
    Posts
    228
    A "view of a texture" would imply that it is NOT a texture itself but something different that references a texture (as in d3d).

    But the new objects we have are really textures on their own right - after you create one, you use it exactly as you would a normal texture.

    They are just textures whose storage memory aliases that of another texture.

    As for that you can specify mipmap subrange - so what?
    Where in the definition of the programming term "alias" it is stated that it should exactly coincide with the other object?
    They can only partially overlap

    Moreover the mip range for the "view" makes much less sense - why a "view" should have it's own mip range if it is just a "view" to another texture?
    When someone "looks" at a texture, he sees a texture with 5 mips. But when someone else "looks" at the same texture at the same time, he sees 3 mips!
    Last edited by l_belev; 08-07-2012 at 05:38 AM.

  8. #18
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    578
    Maybe the better way to look at is that the new texture call says this texture uses the exact same backing store of memory as an existing texture. Since that is what it is doing. By being a texture in it's own right, it makes it heck-a-simple to specify all the texture state, swizzles varying, mip map ranges, lod biases, etc.. blah, blah blah. I think that which was added was great.. to me it makes crystal clear sense: "new texture's texel data references same memory for the texel data as an existing texture".

  9. #19
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Moreover the mip range for the "view" makes much less sense - why a "view" should have it's own mip range if it is just a "view" to another texture?
    Actually, it makes a lot of sense. There is the object (the texture's storage), and there are views of it. A view of an object can theoretically see less of the object than actually exists, if something is in the way. It sees some of the object, but not all of it.

    Thus, a texture view can see less of the texture than the original texture does.

Posting Permissions

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