<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: glMapBuffer, how I mock thee</title>
	<atom:link href="http://www.stevestreeting.com/2007/03/16/glmapbuffer-how-i-mock-thee/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.stevestreeting.com/2007/03/16/glmapbuffer-how-i-mock-thee/</link>
	<description>Man bites Ogre</description>
	<lastBuildDate>Thu, 09 Feb 2012 08:49:11 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.4</generator>
	<item>
		<title>By: SteveStreeting.com &#187; Buffer access modes in DirectX10</title>
		<link>http://www.stevestreeting.com/2007/03/16/glmapbuffer-how-i-mock-thee/comment-page-1/#comment-44724</link>
		<dc:creator>SteveStreeting.com &#187; Buffer access modes in DirectX10</dc:creator>
		<pubDate>Thu, 11 Oct 2007 22:10:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.stevestreeting.com/?p=489#comment-44724</guid>
		<description>[...] It&#8217;s resolvable of course, in our classes I will just have to detect this kind of condition (and there are others with write modes, and now there&#8217;s a GPU write mode too for stream out and I assume RTT uses it too) and cope with it internally. Whilst mapping or reading / writing data from a buffer which has an incompatible mode, we&#8217;ll just have to perform the copy internally and map the shadow copy. We already have the concept of shadow buffers in our code, but that&#8217;s more for when you want a permanent readable copy that&#8217;s fast, not for one-off locks. For the one-off cases I think I&#8217;ll use a dynamic scratch buffer pool - I already wrote one of these for GL in fact to resolve some GL buffer locking performance oddities earlier this year. [...]</description>
		<content:encoded><![CDATA[<p>[...] It&#8217;s resolvable of course, in our classes I will just have to detect this kind of condition (and there are others with write modes, and now there&#8217;s a GPU write mode too for stream out and I assume RTT uses it too) and cope with it internally. Whilst mapping or reading / writing data from a buffer which has an incompatible mode, we&#8217;ll just have to perform the copy internally and map the shadow copy. We already have the concept of shadow buffers in our code, but that&#8217;s more for when you want a permanent readable copy that&#8217;s fast, not for one-off locks. For the one-off cases I think I&#8217;ll use a dynamic scratch buffer pool &#8211; I already wrote one of these for GL in fact to resolve some GL buffer locking performance oddities earlier this year. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://www.stevestreeting.com/2007/03/16/glmapbuffer-how-i-mock-thee/comment-page-1/#comment-14425</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Sat, 17 Mar 2007 12:25:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.stevestreeting.com/?p=489#comment-14425</guid>
		<description>@Arseny: Yep, that&#039;s what they say, but it doesn&#039;t work. I went through all the papers and tips articles I could find and tried all combinations of glBufferData with NULL pointers, all the access modes. Nada. 

@tau:odd, because nfz is on ATI and RC2 provided a workaround for the main ATI GL driver bug. There are further ATI GL optimisations in CVS since then but the demos should work in RC2, they have for others. But then, I gave up on ATI&#039;s GL support some time ago ;)</description>
		<content:encoded><![CDATA[<p>@Arseny: Yep, that&#8217;s what they say, but it doesn&#8217;t work. I went through all the papers and tips articles I could find and tried all combinations of glBufferData with NULL pointers, all the access modes. Nada. </p>
<p>@tau:odd, because nfz is on ATI and RC2 provided a workaround for the main ATI GL driver bug. There are further ATI GL optimisations in CVS since then but the demos should work in RC2, they have for others. But then, I gave up on ATI&#8217;s GL support some time ago <img src='http://www.stevestreeting.com/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tau</title>
		<link>http://www.stevestreeting.com/2007/03/16/glmapbuffer-how-i-mock-thee/comment-page-1/#comment-14378</link>
		<dc:creator>tau</dc:creator>
		<pubDate>Fri, 16 Mar 2007 20:33:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.stevestreeting.com/?p=489#comment-14378</guid>
		<description>Great read, Steve and Kudos to you guys to sort that out. That&#039;s serious.

I also noticed something strange while testing new 1.4.0RC1-2 demos: it works fine on my dev machine in D3D mode, but every single demo fails to run under GL. I have updated drivers (ATI x800 GTO), all the Dagon demos still work fine in GL.</description>
		<content:encoded><![CDATA[<p>Great read, Steve and Kudos to you guys to sort that out. That&#8217;s serious.</p>
<p>I also noticed something strange while testing new 1.4.0RC1-2 demos: it works fine on my dev machine in D3D mode, but every single demo fails to run under GL. I have updated drivers (ATI x800 GTO), all the Dagon demos still work fine in GL.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arseny Kapoulkine</title>
		<link>http://www.stevestreeting.com/2007/03/16/glmapbuffer-how-i-mock-thee/comment-page-1/#comment-14377</link>
		<dc:creator>Arseny Kapoulkine</dc:creator>
		<pubDate>Fri, 16 Mar 2007 20:29:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.stevestreeting.com/?p=489#comment-14377</guid>
		<description>IIRC, if you want a D3DLOCK_DISCARD-like behaviour, you have to explicitly discard your buffer (calling glBufferData or glBufferSubData with NULL as data, I forgot which) and then call map.

Though I agree, this is a very weak point in OpenGL - it&#039;s strange how some parts of OpenGL are so much closer to hardware than in Direct3D and some are so far from it.</description>
		<content:encoded><![CDATA[<p>IIRC, if you want a D3DLOCK_DISCARD-like behaviour, you have to explicitly discard your buffer (calling glBufferData or glBufferSubData with NULL as data, I forgot which) and then call map.</p>
<p>Though I agree, this is a very weak point in OpenGL &#8211; it&#8217;s strange how some parts of OpenGL are so much closer to hardware than in Direct3D and some are so far from it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

