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 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: FBO performance: who is right?

  1. #11
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153
    Quote Originally Posted by aqnuep View Post
    Why? You think the NV driver has optimized every single feature to the level that it cannot be improved any further? That's a pretty naive assumption.
    No, but VAO is obvious optimization and Valve is rather important client. I am sure NVIDIA got reports from Valve about slow VAO, but new drivers still aren't faster in this area.
    Other optimizations requested by Valve has been implemented by NVIDIA (http://www.phoronix.com/scan.php?pag...tem&px=MTIwNzQ).
    Last edited by randall; 04-19-2013 at 12:35 PM.

  2. #12
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    Quote Originally Posted by randall
    [..]but new drivers still aren't faster in this area.
    If they theoretically could and should be but still aren't, do you really think it's because the driver is already fully optimized? Valve is one AAA client on Linux. One.

  3. #13
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153
    One and only one on Linux.

  4. #14
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    There is and there will be ever a fully optimized OpenGL driver in the same way there are no perfect things in world in general. In software engineering this is even more true, there doesn't exist any sufficiently large application that is 100% complete and optimal. It's just how things are. Once again, assuming something is fully optimized is rather naive.

    Also, it doesn't take to be a rocket scientist to figure out that if something is done with 2 or more API calls then the same thing can be definitely done faster with a single API call (if the underlying implementation is optimal, then the additional function calls would definitely make the former slightly slower).
    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/

  5. #15
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153
    What I am saying is that VAO design and NV driver design just don't work well together. This is why GL_NV_vertex_buffer_unified_memory extension has been developed, this is why NVIDIA isn't using VAOs in code samples, and this is why NVIDIA employees do not recommend using it.

  6. #16
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,198
    If a company is prepared to put their balls on the chopping block over this, if that company has millions of dollars at stake over this, if that company has a priority of a working program that runs well rather than taking sides in a religious war - I'm inclined to believe them.

  7. #17
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    If a company is prepared to put their balls on the chopping block over this, if that company has millions of dollars at stake over this, if that company has a priority of a working program that runs well rather than taking sides in a religious war - I'm inclined to believe them.
    Fair enough, so let's analyze this on those grounds.

    NVIDIA does indeed have "millions of dollars at stake over this". But what exactly is "this"? They're basically saying, "Don't use the standard method; use our proprietary extension." Or put another way, "Don't use the standard method; make your code only work on our hardware."

    How does NVIDIA not have a stake in "taking sides in a religious war?" NVIDIA has financial reasons to want people to use their proprietary extensions, and financial reasons to encourage people to not use similar core functionality. With AMD being less competitive and having financial troubles... why should we expect what NVIDIA says to be on the level here?

    What would NVIDIA have to gain by putting effort into making VAOs more performant? The more they push their proprietary extensions, the more people buy into it. Which puts people in their ecosystem. This puts pressure on some developers, who then start wanting their customers to buy NVIDIA because that's what they write their code for. Thus pushing sales of NVIDIA hardware. Which in turn increases NVIDIA's marketshare, thus encouraging other developers to make the switch, which causes more sales, etc.

    NVIDIA doesn't make more money by having fast VAO code. NVIDIA makes more money by encouranging more people to write NVIDIA-GL code instead of OpenGL code. Does this mean that they have convinced their developers not to work on VAO performance? Well, someone told them to write the bindless graphics extensions to begin with. Whether that someone was on the driver team, pushing for a performance extension, or was someone in marketing wanting to differentiate their performance from others, I can't say.

    But you cannot reject the very real possibility that they're not on the level here. I see no reason to blindly trust an organization who has a direct financial stake in getting people to not use cross-platform OpenGL code.

    There's no way to know for certain because NVIDIA guards their hardware specifications vigorously. We only have the word of someone who has plenty of reasons to lie.

  8. #18
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,209
    Quote Originally Posted by randall View Post
    What I am saying is that VAO design and NV driver design just don't work well together. This is why GL_NV_vertex_buffer_unified_memory extension has been developed, this is why NVIDIA isn't using VAOs in code samples, and this is why NVIDIA employees do not recommend using it.
    No. VAOs are a half-way bandaid (that can improve perf on NV BTW). But bindless vtx attribs are a faster/cleaner solution for the problem, on NV at least. No bazillion VAO blocks floating around in driver memory to cause cache misses.

    That said, it does make assumptions on the underlying implementation, which may be an obstacle for wider adoption. Would like to see some discussion on that. If so, perhaps there's an intermediate approach that bridges the gap -- such as storing the "content" of VAOs in "client" memory. That gets you part way there.
    Last edited by Dark Photon; 04-20-2013 at 11:35 AM.

  9. #19
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,198
    Quote Originally Posted by Alfonse Reinheart View Post
    <snip>
    That's all lovely but I was talking about Valve.

  10. #20
    Junior Member Regular Contributor
    Join Date
    Jan 2004
    Location
    .dk
    Posts
    129
    Quote Originally Posted by dv View Post
    years ago, I saw Simon Green's presentation<snip>He recommends to use one FBO and switch between textures.
    <snip>
    But then, Valve comes, and tells a very different story. It says "Do not create a single FBO and then swap out attachments on it."
    As far as I am aware, both are right, they are talking about two different scenarios.

    If you switch between fewer rendertextures (of same size) than the maximum number of FBO-attachments, you can attach them to a single FBO to switch quickly between them. This is a static attachment, typically done at init-time, it never changes.

    What Valve are talking about, is swapping out the attachments, which does not apply to the situation described above.

Posting Permissions

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