Comments on: glMapBuffer vs glBufferSubData, the return http://www.stevestreeting.com/2007/03/17/glmapbuffer-vs-glbuffersubdata-the-return/ Man bites Ogre Thu, 09 Feb 2012 08:49:11 +0000 hourly 1 http://wordpress.org/?v=3.1.4 By: Steve http://www.stevestreeting.com/2007/03/17/glmapbuffer-vs-glbuffersubdata-the-return/comment-page-1/#comment-29358 Steve Sun, 24 Jun 2007 14:27:35 +0000 http://www.stevestreeting.com/?p=491#comment-29358 Not at the moment, our goal really is to try to make that unnecessary for the user - it's nasty to have to be concerned about that at the application / content creator level. However, it might happen as part of the Summer of Code 'hardware emulation' project, it's being discussed right now. Not at the moment, our goal really is to try to make that unnecessary for the user – it’s nasty to have to be concerned about that at the application / content creator level. However, it might happen as part of the Summer of Code ‘hardware emulation’ project, it’s being discussed right now.

]]> By: Lee Sandberg http://www.stevestreeting.com/2007/03/17/glmapbuffer-vs-glbuffersubdata-the-return/comment-page-1/#comment-29293 Lee Sandberg Sun, 24 Jun 2007 08:44:37 +0000 http://www.stevestreeting.com/?p=491#comment-29293 Hi Steve and all Yes I think this was a good catch and making sure different cards (or perhaps different drivers) are handled the right way is important. Ogre doesn't have any way to handle implementing different driver/cards implementations does it? Like a standard way? Hi Steve and all

Yes I think this was a good catch and making sure different cards (or perhaps different drivers) are handled the right way is important.

Ogre doesn’t have any way to handle implementing different driver/cards implementations does it?

Like a standard way?

]]> By: SteveStreeting.com » OpenGL Long Peaks and buffer improvements http://www.stevestreeting.com/2007/03/17/glmapbuffer-vs-glbuffersubdata-the-return/comment-page-1/#comment-28694 SteveStreeting.com » OpenGL Long Peaks and buffer improvements Thu, 21 Jun 2007 19:25:36 +0000 http://www.stevestreeting.com/?p=491#comment-28694 [...] Finally, GL buffer objects are due to get some of the functionality we’ve taken for granted in Direct3D for years, as described in this article. Things like explicit write-only interaction modes and sub-region optimisation. About damn time is all I can say, it’s because of GL’s far too generic buffer object management that we have to bend over backwards and use esoteric scratch buffer thresholds in GL to get decent performance under varying buffer conditions. D3D may have one of the more butt-ugly APIs in the known world (mostly because it’s influenced by the similarly butt-ugly Win32 API), but at least it gives you the control when you need it in these areas. [...] [...] Finally, GL buffer objects are due to get some of the functionality we’ve taken for granted in Direct3D for years, as described in this article. Things like explicit write-only interaction modes and sub-region optimisation. About damn time is all I can say, it’s because of GL’s far too generic buffer object management that we have to bend over backwards and use esoteric scratch buffer thresholds in GL to get decent performance under varying buffer conditions. D3D may have one of the more butt-ugly APIs in the known world (mostly because it’s influenced by the similarly butt-ugly Win32 API), but at least it gives you the control when you need it in these areas. [...]

]]> By: Lost in the Triangles » Blog Archive » ARB_vertex_buffer_object is stupid http://www.stevestreeting.com/2007/03/17/glmapbuffer-vs-glbuffersubdata-the-return/comment-page-1/#comment-15204 Lost in the Triangles » Blog Archive » ARB_vertex_buffer_object is stupid Sun, 25 Mar 2007 22:52:46 +0000 http://www.stevestreeting.com/?p=491#comment-15204 [...] What I don’t get is: D3D has had a buffer model that is simple to understand and actually works for, like, 6 years now! Why ARB_vertex_buffer_object guys couldn’t just copy that? The world would be a better place! No, instead they make a way to map only whole buffer; updating chunks is extra memory copy; there are confusing usage parameters (when should I use STREAM and when DYNAMIC?); performance costs are unclear (when is glBufferSubData faster than glMapBuffer?) etc. And in the end when an OpenGL noob like me tries to actually make them work - he can’t! It’s slow! [...] [...] What I don’t get is: D3D has had a buffer model that is simple to understand and actually works for, like, 6 years now! Why ARB_vertex_buffer_object guys couldn’t just copy that? The world would be a better place! No, instead they make a way to map only whole buffer; updating chunks is extra memory copy; there are confusing usage parameters (when should I use STREAM and when DYNAMIC?); performance costs are unclear (when is glBufferSubData faster than glMapBuffer?) etc. And in the end when an OpenGL noob like me tries to actually make them work – he can’t! It’s slow! [...]

]]>