We have check the sematic of GL_DYANMIC_DRAW,
seems that it the Skia usage of GZL_DYNAMIC_DRAW is wrong.
Thanks
Zou Nanhai
From: Zou, Nanhai [mailto:nanhai....@intel.com]
Sent: Tuesday, July 24, 2012 11:25 AM
To: mesa3d-dev (Mesa3d-dev@lists.sourceforge.net)
Cc: Versace, Chad; Ian Romanick (i...@freedesktop.org)
Subject: [Mesa3d-dev] Correct behavior of GL_DYNAMIC_DRAW in glBufferData?
Hi,
I have notice that in current driver implementation.
When GL_DYNAMIC_DRAW flag is set in glBufferData, driver will not upload data to
Graphics memory.
Instead it will upload the _entire_ vertex/index buffer when
glDrawElements/glDrawArray was called.
This sometimes brings a huge bottleneck ,
e.g. in Skia.
Skia allocate a 256k vertexdata buffer and a 64k indexdata buffer as pools, and
use glBufferData to upload the pools.
Most of the Skia draw operations will only use a few vertexes in the pool, but
driver will upload the _entire_
buffer each operation.
This becomes No 1 bottleneck for Skia bench with GPU.
I have tested if reduce the pool size to 1k, many tests in Skia bench get 3x to
>10x performance improvement...
Per my understanding. Even GL_DYNAMIC_DRAW is set in glBufferData, driver
should not copy the entire buffer
When glDrawElements/glDrawArray is called, it should copy only used
vertex/index.
Otherwise this is too heavy in Skia like usage scenario.
Thanks
Zou Nanhai
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
