http://www.paranormal-entertainment.com/idr/blog/posts/2010-07-28T22:12:37Z-SIGGRAPH_2010:_Day_3/ blogtest jkolb http://www.paranormal-entertainment.com/idr/blog/posts/2010-07-28T22:12:37Z-SIGGRAPH_2010:_Day_3/comment_2/ http://www.paranormal-entertainment.com/idr/blog/posts/2010-07-28T22:12:37Z-SIGGRAPH_2010:_Day_3/comment_2/ Thu, 12 Aug 2010 13:34:41 -0700 2010-08-18T20:21:04Z <p>"Nvidia (Mark Kilgard, more precisely) continues to spread mis-information about the compatibility profile, and that's really frustrating."</p> <p>Ian, can you elaborate on this?</p> IanRomanick http://www.paranormal-entertainment.com/idr/blog/posts/2010-07-28T22:12:37Z-SIGGRAPH_2010:_Day_3/comment_1/ http://www.paranormal-entertainment.com/idr/blog/posts/2010-07-28T22:12:37Z-SIGGRAPH_2010:_Day_3/comment_1/ Wed, 18 Aug 2010 13:41:57 -0700 2010-08-18T20:41:59Z <p>Sure. Mark has repeatedly said to never use the core (non-compatibility) profile. He has said that there is no reason for it to exist. He has said that it (paraphrasing) only removes really useful functionality that you really want to use. All of which is wrong. He then goes on to make derogatory comments about the motives of the other ARB members in creating the compatibility profile. I'd like to point out the idea of deprecating and removing functionality from OpenGL <strong>was Nvidia's idea</strong>. But the rest of us, apparently, are only trying to hurt developers by actually doing it. Because, you know, people really want <code>glBlendFunc</code> and <code>glBlendFuncSeparate</code>.</p> <p>The reality is quite the opposite of what Mark says. There <em>is</em> benefit to using the core profile. There are quite a few areas of the spec where we have, for example, intentionally not specified interactions with fixed-function. By not having fixed-function even available you can be sure that you're not accidentally string into undefined behavior territory. There's also the <em>potential</em> for improved performance. While there may be no performance benefit to using the core profile on Nvidia's implementation, that just means that Nvidia hasn't taken advantage of the optimizations afforded by removing 10 years of duplicated or broken interfaces. Admittedly neither has Mesa.</p> <p>The idea, and Mesa does this for OpenGL vs. OpenGL ES, is that the driver will load a different back-end depending on which profile is requested. There are so many state validation checks that just go away in a driver that doesn't have fixed-function, vertex arrays in client memory, or display lists.</p> <p>While I'm on the topic of OpenGL ES, Mark seems to forget that the vast majority of the things removed in the core profile are also removed in OpenGL ES. Ever want to port to ES? Use the core profile.</p>