Keith Packard wrote:
> On Mon, 2008-05-19 at 10:25 -0700, Ian Romanick wrote:
>
>   
>>      glBindBuffer(GL_ARRAY_BUFFER, my_buf);
>>      GLfloat *data = glMapBufferData(GL_ARRAY_BUFFER, GL_READ_WRITE);
>>      if (data == NULL) {
>>              /* fail */
>>      }
>>
>>      /* Fill in buffer data */
>>
>>      glUnmapBuffer(GL_ARRAY_BUFFER);
>>
>> Over:
>>
>>      GLfloat *data = malloc(buffer_size);
>>      if (data == NULL) {
>>              /* fail */
>>      }
>>
>>      /* Fill in buffer data */
>>
>>      glBindBuffer(GL_ARRAY_BUFFER, my_buf);
>>      glBufferSubData(GL_ARRAY_BUFFER, 0, buffer_size, data);
>>      free(data);
>>     
>
> In terms of system performance, that 'extra copy' is not a problem
> though; the only cost is the traffic to the graphics chip, and these
> both do precisely the same amount of work. The benefit to the latter
> approach is that we get to use cache-aware copy code. The former can't
> do this as easily when updating only a portion of the data.
>
>   
>> The second version obviously has extra overhead and takes a performance
>> hit. 
>>     
>
> My measurements show that doing a cache-aware copy is a net performance
> win over using cache-ignorant word-at-a-time writes.
>   
I think the point here is when the buffer in 1) is mapped write-combined 
which IMHO is the obvious approach,
the caches aren't affected at all.

In 2) you have two opportunities to completely fill the cache with data 
that shouldn't need to be reused. With cache-aware copy code you can 
reduce the impact of one of those opportunities.

/Thomas

>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>   




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to