From pub...@ Tue Sep 10 21:32:41 2019 From: pub...@ (Won Chun (...@...)) Date: Wed, 11 Sep 2019 00:32:41 -0400 Subject: [Public WebGL] feedback on Multi Draw extension Message-ID: tl;dr: maybe the inspiration for multi-draw-style interfaces should be inspired by more modern extensions and APIs to avoid future headache? I have spent a long time away from WebGL, but I am back, with a new email address. I am pretty excited by anything that improves draw call submission, even in the specific use case enabled by https://www.khronos.org/registry/webgl/extensions/WEBGL_multi_draw/ But I find the interface to this call a little odd. It appears to be based on the fairly ancient https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multi_draw_arrays.txt Ancient-ness is well and good, and probably means that implementations are probably mature and widespread. Excellent! But please indulge me as I proffer an alternative. One of the benefits of living in the graphics time capsule of WebGL is that we can operate with a great deal of foresight. What are related drawing APIs that would likely be supported in the future? Possible sources of inspiration include drawElementsIndirect, which is included in webgl2-compute: https://www.khronos.org/registry/OpenGL-Refpages/es3.1/html/glDrawElementsIndirect.xhtml And the multi-draw version of this, in GL4: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMultiDrawElementsIndirect.xhtml And there are similar APIs in Vulkan, Metal, and D3D12. The difference between the old and new multi-draw styles is that instead of parallel arrays, the newer APIs use an array of structs. This seems like a largely cosmetic change, but the important difference is that these APIs allow the structs to originate from GPU memory (i.e. from a compute shader). Not that this is a common thing! But the point is that maybe there is not much downside to supporting this style now, with a subset of the total capability, and layering additional functionality (indirect buffers, base instance support, etc) by introducing extensions that relax the constraints. The benefit would be to establish a best practice very early and ease future migration confusion. I think this would likely extend to future APIs -- consider the indirect structures used in Vulkan, Metal and D3D12: https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkDrawIndexedIndirectCommand.html https://developer.apple.com/documentation/metal/mtldrawindexedprimitivesindirectarguments https://docs.microsoft.com/en-us/windows/win32/api/d3d12/ns-d3d12-d3d12_draw_indexed_arguments They are all essentially: typedef struct D3D12_DRAW_INDEXED_ARGUMENTS { UINT IndexCountPerInstance; UINT InstanceCount; UINT StartIndexLocation; INT BaseVertexLocation; UINT StartInstanceLocation; } D3D12_DRAW_INDEXED_ARGUMENTS; An issue with the modern-API approach is dealing with this array-of-structs situation. Namely, it would be terribly inefficient to use a JS array of JS objects for this API. But notice that all the fields in the indirect structs are just 32-bit integers (admittedly, of mixed sign). That means it is totally reasonable to just use a Uint32Array most of the time, and sticklers that need those sign bits could use DataView. Another alternative would be to disallow negative (or non-zero) vertex offsets (and this restriction could be lifted by extension). Another issue is validation. It would be nice if the indirect array didn't need to be walked each time. A possible solution to that would be if, like WebGL vertex arrays, you always interacted this API with a bound indirect buffer. Until computer shaders were availble, these indirect buffers would always be created (and probably stored) on the CPU, but the WebGL/ANGLE benefit would be that there would be an encapsulated thing where validation can be cached. Whew, this was a long one. Thoughts? -Won -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Wed Sep 11 16:23:15 2019 From: pub...@ (Ken Russell (...@...)) Date: Wed, 11 Sep 2019 16:23:15 -0700 Subject: [Public WebGL] feedback on Multi Draw extension In-Reply-To: References: Message-ID: Hi Won, We gave this a great deal of thought during the design of these extensions. Unfortunately it was impractical to phrase them as indirect calls because that would have mandated that the data be uploaded to the GPU and/or read back to the CPU implicitly, and that would have made the implementation so complex that the extensions never would have shipped. We felt that phrasing these draw calls as generalizing the single integer arguments into arrays (or typed arrays) of integers was a fairly small and natural step forward, which is why they aren't phrased as an array of client-side structs. Our colleague Shrek (CC'd) is now adding BaseVertex and BaseInstance versions of these draw calls as new extensions. If the original extensions had been phrased as an array of client-side structs, the addition of new fields would have presented a problem. As it stands, these extensions can actually be emulated under the JavaScript layer and still provide a significant performance boost. One of our partners, Fraunhofer, tested them in their real-world instant3DHub CAD/CAM application. On lower end hardware, the multi-draw extension improved batching so much they were able to see a 17% improvement in framerate. Even larger CPU cost reductions have been seen on draw-call-heavy workloads. CC'ing Austin and Kai who designed and implemented these extensions for any further thoughts that they may have. Please give these extensions a try in your application (they're behind the --enable-webgl-draft-extensions flag in Chrome) and tell us how they're working. Also, if you have any ideas about other simple extensions that could be built on top of these - for example, needing to update a uniform in each of these draw calls - please post here. For the record, the working group is not intending to start building fully general display list extensions for WebGL at this point. -Ken On Tue, Sep 10, 2019 at 9:33 PM Won Chun (won...@) < public_webgl...@> wrote: > tl;dr: maybe the inspiration for multi-draw-style interfaces should be > inspired by more modern extensions and APIs to avoid future headache? > > I have spent a long time away from WebGL, but I am back, with a new email > address. > > I am pretty excited by anything that improves draw call submission, even > in the specific use case enabled by > https://www.khronos.org/registry/webgl/extensions/WEBGL_multi_draw/ > > But I find the interface to this call a little odd. It appears to be based > on the fairly ancient > https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multi_draw_arrays.txt > > Ancient-ness is well and good, and probably means that implementations are > probably mature and widespread. Excellent! But please indulge me as I > proffer an alternative. > > One of the benefits of living in the graphics time capsule of WebGL is > that we can operate with a great deal of foresight. What are related > drawing APIs that would likely be supported in the future? Possible > sources of inspiration include drawElementsIndirect, which is included in > webgl2-compute: > https://www.khronos.org/registry/OpenGL-Refpages/es3.1/html/glDrawElementsIndirect.xhtml > > And the multi-draw version of this, in GL4: > https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMultiDrawElementsIndirect.xhtml > > And there are similar APIs in Vulkan, Metal, and D3D12. > > The difference between the old and new multi-draw styles is that instead > of parallel arrays, the newer APIs use an array of structs. This seems like > a largely cosmetic change, but the important difference is that these APIs > allow the structs to originate from GPU memory (i.e. from a compute > shader). Not that this is a common thing! But the point is that maybe there > is not much downside to supporting this style now, with a subset of the > total capability, and layering additional functionality (indirect buffers, > base instance support, etc) by introducing extensions that relax the > constraints. The benefit would be to establish a best practice very early > and ease future migration confusion. I think this would likely extend to > future APIs -- consider the indirect structures used in Vulkan, Metal and > D3D12: > > > https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkDrawIndexedIndirectCommand.html > > > https://developer.apple.com/documentation/metal/mtldrawindexedprimitivesindirectarguments > > > https://docs.microsoft.com/en-us/windows/win32/api/d3d12/ns-d3d12-d3d12_draw_indexed_arguments > > They are all essentially: > > typedef struct D3D12_DRAW_INDEXED_ARGUMENTS { > UINT IndexCountPerInstance; > UINT InstanceCount; > UINT StartIndexLocation; > INT BaseVertexLocation; > UINT StartInstanceLocation; > } D3D12_DRAW_INDEXED_ARGUMENTS; > > An issue with the modern-API approach is dealing with this > array-of-structs situation. Namely, it would be terribly inefficient to use > a JS array of JS objects for this API. But notice that all the fields in > the indirect structs are just 32-bit integers (admittedly, of mixed sign). > That means it is totally reasonable to just use a Uint32Array most of the > time, and sticklers that need those sign bits could use DataView. Another > alternative would be to disallow negative (or non-zero) vertex offsets (and > this restriction could be lifted by extension). > > Another issue is validation. It would be nice if the indirect array didn't > need to be walked each time. A possible solution to that would be if, like > WebGL vertex arrays, you always interacted this API with a bound indirect > buffer. Until computer shaders were availble, these indirect buffers would > always be created (and probably stored) on the CPU, but the WebGL/ANGLE > benefit would be that there would be an encapsulated thing where validation > can be cached. > > Whew, this was a long one. Thoughts? > > -Won > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Wed Sep 11 18:37:55 2019 From: pub...@ (Won Chun (...@...)) Date: Wed, 11 Sep 2019 21:37:55 -0400 Subject: [Public WebGL] feedback on Multi Draw extension In-Reply-To: References: Message-ID: Hi Ken, My thoughts on these extensions are not meant to imply any shortage of thought on the part of anyone involved. And thank you for giving my drive-by commenting some fair consideration. I think some of what you say is beyond dispute: I 100% believe that as written that WEBGL_multi works as advertised and was a relatively straightforward way to achieve this particular goal (one of many, I'm sure, that you and your team juggles). And I am not surprised that this is a win even without hardware support since you can amortize validation and various overheads. I am interested it trying out this extensions, but of course it means our engine would first have to do a significant amount of work to atlas and group vertex data -- work we'd frankly benefit from without this extension. One case where the win is likely significant would be shadow map rendering, since there is no shader/uniform variety across draw calls in that case. So, yes, I'm an interested customer. And of course it would be nice to be able to update shader and uniform bindings per draw call, but would that ever be supported directly be hardware? There was all the bindless texture/AZDO efforts prior to Mantle/Vulkan (details escape me), but is that the API we'd want to encourage? As someone who is currently managing a production WebGL renderer that will have to maintain compatibility with WebGL1 as we migrate to 2 and beyond, I'd rather not to have to deal with a whole zoo of drawing APIs. My contention is that ARB_multi_draw_indirect can grow from WebGL1 all the way to WebGL2-compute, and conceptually maps to the modern APIs. It is not a coincidence that they all share the same indirect structure! It is also a very simple structure that can be manually packed into a single Uint32Array. It already supports all the relevant fields, so I don't understand the point about difficulties layering extensions for baseVertex/Instance. I feel like this approach could only simplify things, but perhaps I'm not understanding. I think one point that I wasn't very clear about was the notion of introducing a new kind of buffer, indirect buffers. I think one point of confusion is that these indirect buffers would have to live in the GPU. Certainly not! Buffer[Sub]Data and friends have usage hints, and these hints could determine the actual memory placement. For STATIC_DRAW on GPUs that support it, maybe they do live on the GPU, but otherwise it could just be on the CPU. The purpose of introducing indirect buffers is analogous to eschewing client-side vertex arrays in WebGL. Instead of sometimes transacting in CPU arrays, keep the API interface uniform and transact in opaque blobs. In WebGL, this gives a convenient place to cache input validation because it provides the opportunity to inspect changes (it is difficult to get this with raw memory-style interfaces). I would hypothesize that this combination of factors: the ability to cache input validation and the fact that ARB_multi_draw_indirect is closer than EXT_multi_draw to what the GPU wants means that this, the indirect struct approach. But even besides that, I find it a better long-term interface. -Won PS if someone is pressuring you to implement display lists, as someone who has written a display list compiler I applaud you for pushing back. WebGL doesn't even have the begin/end drawing API so this request wouldn't even really make much sense to me. On Wed, Sep 11, 2019 at 7:24 PM Ken Russell (kbr...@) < public_webgl...@> wrote: > Hi Won, > > We gave this a great deal of thought during the design of these > extensions. Unfortunately it was impractical to phrase them as indirect > calls because that would have mandated that the data be uploaded to the GPU > and/or read back to the CPU implicitly, and that would have made the > implementation so complex that the extensions never would have shipped. We > felt that phrasing these draw calls as generalizing the single integer > arguments into arrays (or typed arrays) of integers was a fairly small and > natural step forward, which is why they aren't phrased as an array of > client-side structs. Our colleague Shrek (CC'd) is now adding BaseVertex > and BaseInstance versions of these draw calls as new extensions. If the > original extensions had been phrased as an array of client-side structs, > the addition of new fields would have presented a problem. > > As it stands, these extensions can actually be emulated under the > JavaScript layer and still provide a significant performance boost. > > One of our partners, Fraunhofer, tested them in their real-world > instant3DHub CAD/CAM application. On lower end hardware, the multi-draw > extension improved batching so much they were able to see a 17% improvement > in framerate. Even larger CPU cost reductions have been seen on > draw-call-heavy workloads. > > CC'ing Austin and Kai who designed and implemented these extensions for > any further thoughts that they may have. > > Please give these extensions a try in your application (they're behind the > --enable-webgl-draft-extensions flag in Chrome) and tell us how they're > working. Also, if you have any ideas about other simple extensions that > could be built on top of these - for example, needing to update a uniform > in each of these draw calls - please post here. > > For the record, the working group is not intending to start building fully > general display list extensions for WebGL at this point. > > -Ken > > > On Tue, Sep 10, 2019 at 9:33 PM Won Chun (won...@) < > public_webgl...@> wrote: > >> tl;dr: maybe the inspiration for multi-draw-style interfaces should be >> inspired by more modern extensions and APIs to avoid future headache? >> >> I have spent a long time away from WebGL, but I am back, with a new email >> address. >> >> I am pretty excited by anything that improves draw call submission, even >> in the specific use case enabled by >> https://www.khronos.org/registry/webgl/extensions/WEBGL_multi_draw/ >> >> But I find the interface to this call a little odd. It appears to be >> based on the fairly ancient >> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multi_draw_arrays.txt >> >> Ancient-ness is well and good, and probably means that implementations >> are probably mature and widespread. Excellent! But please indulge me as I >> proffer an alternative. >> >> One of the benefits of living in the graphics time capsule of WebGL is >> that we can operate with a great deal of foresight. What are related >> drawing APIs that would likely be supported in the future? Possible >> sources of inspiration include drawElementsIndirect, which is included in >> webgl2-compute: >> https://www.khronos.org/registry/OpenGL-Refpages/es3.1/html/glDrawElementsIndirect.xhtml >> >> And the multi-draw version of this, in GL4: >> https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMultiDrawElementsIndirect.xhtml >> >> And there are similar APIs in Vulkan, Metal, and D3D12. >> >> The difference between the old and new multi-draw styles is that instead >> of parallel arrays, the newer APIs use an array of structs. This seems like >> a largely cosmetic change, but the important difference is that these APIs >> allow the structs to originate from GPU memory (i.e. from a compute >> shader). Not that this is a common thing! But the point is that maybe there >> is not much downside to supporting this style now, with a subset of the >> total capability, and layering additional functionality (indirect buffers, >> base instance support, etc) by introducing extensions that relax the >> constraints. The benefit would be to establish a best practice very early >> and ease future migration confusion. I think this would likely extend to >> future APIs -- consider the indirect structures used in Vulkan, Metal and >> D3D12: >> >> >> https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkDrawIndexedIndirectCommand.html >> >> >> https://developer.apple.com/documentation/metal/mtldrawindexedprimitivesindirectarguments >> >> >> https://docs.microsoft.com/en-us/windows/win32/api/d3d12/ns-d3d12-d3d12_draw_indexed_arguments >> >> They are all essentially: >> >> typedef struct D3D12_DRAW_INDEXED_ARGUMENTS { >> UINT IndexCountPerInstance; >> UINT InstanceCount; >> UINT StartIndexLocation; >> INT BaseVertexLocation; >> UINT StartInstanceLocation; >> } D3D12_DRAW_INDEXED_ARGUMENTS; >> >> An issue with the modern-API approach is dealing with this >> array-of-structs situation. Namely, it would be terribly inefficient to use >> a JS array of JS objects for this API. But notice that all the fields in >> the indirect structs are just 32-bit integers (admittedly, of mixed sign). >> That means it is totally reasonable to just use a Uint32Array most of the >> time, and sticklers that need those sign bits could use DataView. Another >> alternative would be to disallow negative (or non-zero) vertex offsets (and >> this restriction could be lifted by extension). >> >> Another issue is validation. It would be nice if the indirect array >> didn't need to be walked each time. A possible solution to that would be >> if, like WebGL vertex arrays, you always interacted this API with a bound >> indirect buffer. Until computer shaders were availble, these indirect >> buffers would always be created (and probably stored) on the CPU, but the >> WebGL/ANGLE benefit would be that there would be an encapsulated thing >> where validation can be cached. >> >> Whew, this was a long one. Thoughts? >> >> -Won >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Thu Sep 12 10:35:27 2019 From: pub...@ (Ken Russell (...@...)) Date: Thu, 12 Sep 2019 10:35:27 -0700 Subject: [Public WebGL] feedback on Multi Draw extension In-Reply-To: References: Message-ID: Hi Won, To clarify my statement about layering extensions for baseVertex / baseInstance, note that the initial ARB_draw_indirect extension contained "reservedMustBeZero" fields in the struct, presumably to support instancing later on: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_draw_indirect.txt If WebGL had phrased multi-draw support in terms of the indirect draw calls, there would be essentially zero coverage on Android. Unfortunately, EXT_multi_draw_indirect is only supported by NVIDIA. I wish their chipsets were more widely used in Android devices. https://opengles.gpuinfo.org/listreports.php?extension=GL_EXT_multi_draw_indirect Emulating indirect buffers with CPU-backed storage in WebGL implementations would have been much more complex than the current approach which takes client-side data every time. -Ken On Wed, Sep 11, 2019 at 6:38 PM Won Chun (won...@) < public_webgl...@> wrote: > Hi Ken, > > My thoughts on these extensions are not meant to imply any shortage of > thought on the part of anyone involved. And thank you for giving my > drive-by commenting some fair consideration. I think some of what you say > is beyond dispute: I 100% believe that as written that WEBGL_multi works as > advertised and was a relatively straightforward way to achieve this > particular goal (one of many, I'm sure, that you and your team juggles). > And I am not surprised that this is a win even without hardware support > since you can amortize validation and various overheads. I am interested it > trying out this extensions, but of course it means our engine would first > have to do a significant amount of work to atlas and group vertex data -- > work we'd frankly benefit from without this extension. One case where the > win is likely significant would be shadow map rendering, since there is no > shader/uniform variety across draw calls in that case. > > So, yes, I'm an interested customer. And of course it would be nice to be > able to update shader and uniform bindings per draw call, but would that > ever be supported directly be hardware? There was all the bindless > texture/AZDO efforts prior to Mantle/Vulkan (details escape me), but is > that the API we'd want to encourage? As someone who is currently managing a > production WebGL renderer that will have to maintain compatibility with > WebGL1 as we migrate to 2 and beyond, I'd rather not to have to deal with a > whole zoo of drawing APIs. My contention is that ARB_multi_draw_indirect > can grow from WebGL1 all the way to WebGL2-compute, and conceptually maps > to the modern APIs. > > It is not a coincidence that they all share the same indirect structure! > It is also a very simple structure that can be manually packed into a > single Uint32Array. It already supports all the relevant fields, so I don't > understand the point about difficulties layering extensions for > baseVertex/Instance. I feel like this approach could only simplify things, > but perhaps I'm not understanding. > > I think one point that I wasn't very clear about was the notion of > introducing a new kind of buffer, indirect buffers. I think one point of > confusion is that these indirect buffers would have to live in the GPU. > Certainly not! Buffer[Sub]Data and friends have usage hints, and these > hints could determine the actual memory placement. For STATIC_DRAW on GPUs > that support it, maybe they do live on the GPU, but otherwise it could just > be on the CPU. The purpose of introducing indirect buffers is analogous to > eschewing client-side vertex arrays in WebGL. Instead of sometimes > transacting in CPU arrays, keep the API interface uniform and transact in > opaque blobs. In WebGL, this gives a convenient place to cache input > validation because it provides the opportunity to inspect changes (it is > difficult to get this with raw memory-style interfaces). > > I would hypothesize that this combination of factors: the ability to cache > input validation and the fact that ARB_multi_draw_indirect is closer than > EXT_multi_draw to what the GPU wants means that this, the indirect struct > approach. But even besides that, I find it a better long-term interface. > > -Won > > PS if someone is pressuring you to implement display lists, as someone who > has written a display list compiler I applaud you for pushing back. WebGL > doesn't even have the begin/end drawing API so this request wouldn't even > really make much sense to me. > > > > > On Wed, Sep 11, 2019 at 7:24 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > >> Hi Won, >> >> We gave this a great deal of thought during the design of these >> extensions. Unfortunately it was impractical to phrase them as indirect >> calls because that would have mandated that the data be uploaded to the GPU >> and/or read back to the CPU implicitly, and that would have made the >> implementation so complex that the extensions never would have shipped. We >> felt that phrasing these draw calls as generalizing the single integer >> arguments into arrays (or typed arrays) of integers was a fairly small and >> natural step forward, which is why they aren't phrased as an array of >> client-side structs. Our colleague Shrek (CC'd) is now adding BaseVertex >> and BaseInstance versions of these draw calls as new extensions. If the >> original extensions had been phrased as an array of client-side structs, >> the addition of new fields would have presented a problem. >> >> As it stands, these extensions can actually be emulated under the >> JavaScript layer and still provide a significant performance boost. >> >> One of our partners, Fraunhofer, tested them in their real-world >> instant3DHub CAD/CAM application. On lower end hardware, the multi-draw >> extension improved batching so much they were able to see a 17% improvement >> in framerate. Even larger CPU cost reductions have been seen on >> draw-call-heavy workloads. >> >> CC'ing Austin and Kai who designed and implemented these extensions for >> any further thoughts that they may have. >> >> Please give these extensions a try in your application (they're behind >> the --enable-webgl-draft-extensions flag in Chrome) and tell us how they're >> working. Also, if you have any ideas about other simple extensions that >> could be built on top of these - for example, needing to update a uniform >> in each of these draw calls - please post here. >> >> For the record, the working group is not intending to start building >> fully general display list extensions for WebGL at this point. >> >> -Ken >> >> >> On Tue, Sep 10, 2019 at 9:33 PM Won Chun (won...@) < >> public_webgl...@> wrote: >> >>> tl;dr: maybe the inspiration for multi-draw-style interfaces should be >>> inspired by more modern extensions and APIs to avoid future headache? >>> >>> I have spent a long time away from WebGL, but I am back, with a new >>> email address. >>> >>> I am pretty excited by anything that improves draw call submission, even >>> in the specific use case enabled by >>> https://www.khronos.org/registry/webgl/extensions/WEBGL_multi_draw/ >>> >>> But I find the interface to this call a little odd. It appears to be >>> based on the fairly ancient >>> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multi_draw_arrays.txt >>> >>> Ancient-ness is well and good, and probably means that implementations >>> are probably mature and widespread. Excellent! But please indulge me as I >>> proffer an alternative. >>> >>> One of the benefits of living in the graphics time capsule of WebGL is >>> that we can operate with a great deal of foresight. What are related >>> drawing APIs that would likely be supported in the future? Possible >>> sources of inspiration include drawElementsIndirect, which is included in >>> webgl2-compute: >>> https://www.khronos.org/registry/OpenGL-Refpages/es3.1/html/glDrawElementsIndirect.xhtml >>> >>> And the multi-draw version of this, in GL4: >>> https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMultiDrawElementsIndirect.xhtml >>> >>> And there are similar APIs in Vulkan, Metal, and D3D12. >>> >>> The difference between the old and new multi-draw styles is that instead >>> of parallel arrays, the newer APIs use an array of structs. This seems like >>> a largely cosmetic change, but the important difference is that these APIs >>> allow the structs to originate from GPU memory (i.e. from a compute >>> shader). Not that this is a common thing! But the point is that maybe there >>> is not much downside to supporting this style now, with a subset of the >>> total capability, and layering additional functionality (indirect buffers, >>> base instance support, etc) by introducing extensions that relax the >>> constraints. The benefit would be to establish a best practice very early >>> and ease future migration confusion. I think this would likely extend to >>> future APIs -- consider the indirect structures used in Vulkan, Metal and >>> D3D12: >>> >>> >>> https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkDrawIndexedIndirectCommand.html >>> >>> >>> https://developer.apple.com/documentation/metal/mtldrawindexedprimitivesindirectarguments >>> >>> >>> https://docs.microsoft.com/en-us/windows/win32/api/d3d12/ns-d3d12-d3d12_draw_indexed_arguments >>> >>> They are all essentially: >>> >>> typedef struct D3D12_DRAW_INDEXED_ARGUMENTS { >>> UINT IndexCountPerInstance; >>> UINT InstanceCount; >>> UINT StartIndexLocation; >>> INT BaseVertexLocation; >>> UINT StartInstanceLocation; >>> } D3D12_DRAW_INDEXED_ARGUMENTS; >>> >>> An issue with the modern-API approach is dealing with this >>> array-of-structs situation. Namely, it would be terribly inefficient to use >>> a JS array of JS objects for this API. But notice that all the fields in >>> the indirect structs are just 32-bit integers (admittedly, of mixed sign). >>> That means it is totally reasonable to just use a Uint32Array most of the >>> time, and sticklers that need those sign bits could use DataView. Another >>> alternative would be to disallow negative (or non-zero) vertex offsets (and >>> this restriction could be lifted by extension). >>> >>> Another issue is validation. It would be nice if the indirect array >>> didn't need to be walked each time. A possible solution to that would be >>> if, like WebGL vertex arrays, you always interacted this API with a bound >>> indirect buffer. Until computer shaders were availble, these indirect >>> buffers would always be created (and probably stored) on the CPU, but the >>> WebGL/ANGLE benefit would be that there would be an encapsulated thing >>> where validation can be cached. >>> >>> Whew, this was a long one. Thoughts? >>> >>> -Won >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Wed Sep 18 07:44:38 2019 From: pub...@ (Won Chun (...@...)) Date: Wed, 18 Sep 2019 10:44:38 -0400 Subject: [Public WebGL] feedback on Multi Draw extension In-Reply-To: References: Message-ID: Replies inline. On Thu, Sep 12, 2019 at 1:36 PM Ken Russell (kbr...@) < public_webgl...@> wrote: > Hi Won, > > To clarify my statement about layering extensions for baseVertex / > baseInstance, note that the initial ARB_draw_indirect extension contained > "reservedMustBeZero" fields in the struct, presumably to support instancing > later on: > > > https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_draw_indirect.txt > Yes. Also Note that the indirect structs are all compatible with the one that I pointed out, which in turn are even compatible across APIs (apparently also DX11, not just DX12). Also I don't think you need baseVertex for instancing; I think it just means you don't have to rewrite your elements based on how you laid out your vertex buffers (which might be useful in case you have a low max element). > > If WebGL had phrased multi-draw support in terms of the indirect draw > calls, there would be essentially zero coverage on Android. Unfortunately, > EXT_multi_draw_indirect is only supported by NVIDIA. I wish their chipsets > were more widely used in Android devices. > > > https://opengles.gpuinfo.org/listreports.php?extension=GL_EXT_multi_draw_indirect > Hey, gpuinfo looks pretty cool! The coverage is not entirely convincing to me however. Only 3000+ GLES entries? You must have access to far better data? But point taken: Android support isn't great (unsurprising). But, note that indirect drawing is part of core ES 3.1 (which, I don't need to tell you, is one reason why it is part of WebGL2-compute) so "support" isn't necessarily expressed via extension! On the other hand, you would have close to 100% support on Windows and Linux desktops. Also macOS in some dreamland future where ANGLE has Metal support. > > > Emulating indirect buffers with CPU-backed storage in WebGL > implementations would have been much more complex than the current approach > which takes client-side data every time. > "Much more" is a little surprising. Are you also tacitly suggest that pre-validating buffers isn't very valuable? Because you give that up by taking client-side data every time. -Won > > -Ken > > > On Wed, Sep 11, 2019 at 6:38 PM Won Chun (won...@) < > public_webgl...@> wrote: > >> Hi Ken, >> >> My thoughts on these extensions are not meant to imply any shortage of >> thought on the part of anyone involved. And thank you for giving my >> drive-by commenting some fair consideration. I think some of what you say >> is beyond dispute: I 100% believe that as written that WEBGL_multi works as >> advertised and was a relatively straightforward way to achieve this >> particular goal (one of many, I'm sure, that you and your team juggles). >> And I am not surprised that this is a win even without hardware support >> since you can amortize validation and various overheads. I am interested it >> trying out this extensions, but of course it means our engine would first >> have to do a significant amount of work to atlas and group vertex data -- >> work we'd frankly benefit from without this extension. One case where the >> win is likely significant would be shadow map rendering, since there is no >> shader/uniform variety across draw calls in that case. >> >> So, yes, I'm an interested customer. And of course it would be nice to be >> able to update shader and uniform bindings per draw call, but would that >> ever be supported directly be hardware? There was all the bindless >> texture/AZDO efforts prior to Mantle/Vulkan (details escape me), but is >> that the API we'd want to encourage? As someone who is currently managing a >> production WebGL renderer that will have to maintain compatibility with >> WebGL1 as we migrate to 2 and beyond, I'd rather not to have to deal with a >> whole zoo of drawing APIs. My contention is that ARB_multi_draw_indirect >> can grow from WebGL1 all the way to WebGL2-compute, and conceptually maps >> to the modern APIs. >> >> It is not a coincidence that they all share the same indirect structure! >> It is also a very simple structure that can be manually packed into a >> single Uint32Array. It already supports all the relevant fields, so I don't >> understand the point about difficulties layering extensions for >> baseVertex/Instance. I feel like this approach could only simplify things, >> but perhaps I'm not understanding. >> >> I think one point that I wasn't very clear about was the notion of >> introducing a new kind of buffer, indirect buffers. I think one point of >> confusion is that these indirect buffers would have to live in the GPU. >> Certainly not! Buffer[Sub]Data and friends have usage hints, and these >> hints could determine the actual memory placement. For STATIC_DRAW on GPUs >> that support it, maybe they do live on the GPU, but otherwise it could just >> be on the CPU. The purpose of introducing indirect buffers is analogous to >> eschewing client-side vertex arrays in WebGL. Instead of sometimes >> transacting in CPU arrays, keep the API interface uniform and transact in >> opaque blobs. In WebGL, this gives a convenient place to cache input >> validation because it provides the opportunity to inspect changes (it is >> difficult to get this with raw memory-style interfaces). >> >> I would hypothesize that this combination of factors: the ability to >> cache input validation and the fact that ARB_multi_draw_indirect is closer >> than EXT_multi_draw to what the GPU wants means that this, the indirect >> struct approach. But even besides that, I find it a better long-term >> interface. >> >> -Won >> >> PS if someone is pressuring you to implement display lists, as someone >> who has written a display list compiler I applaud you for pushing back. >> WebGL doesn't even have the begin/end drawing API so this request wouldn't >> even really make much sense to me. >> >> >> >> >> On Wed, Sep 11, 2019 at 7:24 PM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >>> Hi Won, >>> >>> We gave this a great deal of thought during the design of these >>> extensions. Unfortunately it was impractical to phrase them as indirect >>> calls because that would have mandated that the data be uploaded to the GPU >>> and/or read back to the CPU implicitly, and that would have made the >>> implementation so complex that the extensions never would have shipped. We >>> felt that phrasing these draw calls as generalizing the single integer >>> arguments into arrays (or typed arrays) of integers was a fairly small and >>> natural step forward, which is why they aren't phrased as an array of >>> client-side structs. Our colleague Shrek (CC'd) is now adding BaseVertex >>> and BaseInstance versions of these draw calls as new extensions. If the >>> original extensions had been phrased as an array of client-side structs, >>> the addition of new fields would have presented a problem. >>> >>> As it stands, these extensions can actually be emulated under the >>> JavaScript layer and still provide a significant performance boost. >>> >>> One of our partners, Fraunhofer, tested them in their real-world >>> instant3DHub CAD/CAM application. On lower end hardware, the multi-draw >>> extension improved batching so much they were able to see a 17% improvement >>> in framerate. Even larger CPU cost reductions have been seen on >>> draw-call-heavy workloads. >>> >>> CC'ing Austin and Kai who designed and implemented these extensions for >>> any further thoughts that they may have. >>> >>> Please give these extensions a try in your application (they're behind >>> the --enable-webgl-draft-extensions flag in Chrome) and tell us how they're >>> working. Also, if you have any ideas about other simple extensions that >>> could be built on top of these - for example, needing to update a uniform >>> in each of these draw calls - please post here. >>> >>> For the record, the working group is not intending to start building >>> fully general display list extensions for WebGL at this point. >>> >>> -Ken >>> >>> >>> On Tue, Sep 10, 2019 at 9:33 PM Won Chun (won...@) < >>> public_webgl...@> wrote: >>> >>>> tl;dr: maybe the inspiration for multi-draw-style interfaces should be >>>> inspired by more modern extensions and APIs to avoid future headache? >>>> >>>> I have spent a long time away from WebGL, but I am back, with a new >>>> email address. >>>> >>>> I am pretty excited by anything that improves draw call submission, >>>> even in the specific use case enabled by >>>> https://www.khronos.org/registry/webgl/extensions/WEBGL_multi_draw/ >>>> >>>> But I find the interface to this call a little odd. It appears to be >>>> based on the fairly ancient >>>> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multi_draw_arrays.txt >>>> >>>> Ancient-ness is well and good, and probably means that implementations >>>> are probably mature and widespread. Excellent! But please indulge me as I >>>> proffer an alternative. >>>> >>>> One of the benefits of living in the graphics time capsule of WebGL is >>>> that we can operate with a great deal of foresight. What are related >>>> drawing APIs that would likely be supported in the future? Possible >>>> sources of inspiration include drawElementsIndirect, which is included in >>>> webgl2-compute: >>>> https://www.khronos.org/registry/OpenGL-Refpages/es3.1/html/glDrawElementsIndirect.xhtml >>>> >>>> And the multi-draw version of this, in GL4: >>>> https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMultiDrawElementsIndirect.xhtml >>>> >>>> And there are similar APIs in Vulkan, Metal, and D3D12. >>>> >>>> The difference between the old and new multi-draw styles is that >>>> instead of parallel arrays, the newer APIs use an array of structs. This >>>> seems like a largely cosmetic change, but the important difference is that >>>> these APIs allow the structs to originate from GPU memory (i.e. from a >>>> compute shader). Not that this is a common thing! But the point is that >>>> maybe there is not much downside to supporting this style now, with a >>>> subset of the total capability, and layering additional functionality >>>> (indirect buffers, base instance support, etc) by introducing extensions >>>> that relax the constraints. The benefit would be to establish a best >>>> practice very early and ease future migration confusion. I think this would >>>> likely extend to future APIs -- consider the indirect structures used in >>>> Vulkan, Metal and D3D12: >>>> >>>> >>>> https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkDrawIndexedIndirectCommand.html >>>> >>>> >>>> https://developer.apple.com/documentation/metal/mtldrawindexedprimitivesindirectarguments >>>> >>>> >>>> https://docs.microsoft.com/en-us/windows/win32/api/d3d12/ns-d3d12-d3d12_draw_indexed_arguments >>>> >>>> They are all essentially: >>>> >>>> typedef struct D3D12_DRAW_INDEXED_ARGUMENTS { >>>> UINT IndexCountPerInstance; >>>> UINT InstanceCount; >>>> UINT StartIndexLocation; >>>> INT BaseVertexLocation; >>>> UINT StartInstanceLocation; >>>> } D3D12_DRAW_INDEXED_ARGUMENTS; >>>> >>>> An issue with the modern-API approach is dealing with this >>>> array-of-structs situation. Namely, it would be terribly inefficient to use >>>> a JS array of JS objects for this API. But notice that all the fields in >>>> the indirect structs are just 32-bit integers (admittedly, of mixed sign). >>>> That means it is totally reasonable to just use a Uint32Array most of the >>>> time, and sticklers that need those sign bits could use DataView. Another >>>> alternative would be to disallow negative (or non-zero) vertex offsets (and >>>> this restriction could be lifted by extension). >>>> >>>> Another issue is validation. It would be nice if the indirect array >>>> didn't need to be walked each time. A possible solution to that would be >>>> if, like WebGL vertex arrays, you always interacted this API with a bound >>>> indirect buffer. Until computer shaders were availble, these indirect >>>> buffers would always be created (and probably stored) on the CPU, but the >>>> WebGL/ANGLE benefit would be that there would be an encapsulated thing >>>> where validation can be cached. >>>> >>>> Whew, this was a long one. Thoughts? >>>> >>>> -Won >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Wed Sep 18 14:22:18 2019 From: pub...@ (Ken Russell (...@...)) Date: Wed, 18 Sep 2019 14:22:18 -0700 Subject: [Public WebGL] feedback on Multi Draw extension In-Reply-To: References: Message-ID: On Wed, Sep 18, 2019 at 7:45 AM Won Chun (won...@) < public_webgl...@> wrote: > Replies inline. > > On Thu, Sep 12, 2019 at 1:36 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > >> Hi Won, >> >> To clarify my statement about layering extensions for baseVertex / >> baseInstance, note that the initial ARB_draw_indirect extension contained >> "reservedMustBeZero" fields in the struct, presumably to support instancing >> later on: >> >> >> https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_draw_indirect.txt >> > > Yes. Also Note that the indirect structs are all compatible with the one > that I pointed out, which in turn are even compatible across APIs > (apparently also DX11, not just DX12). Also I don't think you need > baseVertex for instancing; I think it just means you don't have to rewrite > your elements based on how you laid out your vertex buffers (which might be > useful in case you have a low max element). > > >> >> If WebGL had phrased multi-draw support in terms of the indirect draw >> calls, there would be essentially zero coverage on Android. Unfortunately, >> EXT_multi_draw_indirect is only supported by NVIDIA. I wish their chipsets >> were more widely used in Android devices. >> >> >> https://opengles.gpuinfo.org/listreports.php?extension=GL_EXT_multi_draw_indirect >> > > Hey, gpuinfo looks pretty cool! The coverage is not entirely convincing to > me however. Only 3000+ GLES entries? You must have access to far better > data? But point taken: Android support isn't great (unsurprising). But, > note that indirect drawing is part of core ES 3.1 (which, I don't need to > tell you, is one reason why it is part of WebGL2-compute) so "support" > isn't necessarily expressed via extension! > > On the other hand, you would have close to 100% support on Windows and > Linux desktops. Also macOS in some dreamland future where ANGLE has Metal > support. > >> >> >> Emulating indirect buffers with CPU-backed storage in WebGL >> implementations would have been much more complex than the current approach >> which takes client-side data every time. >> > > "Much more" is a little surprising. Are you also tacitly suggest that > pre-validating buffers isn't very valuable? Because you give that up by > taking client-side data every time. > I'm not implying that at all. The difficulty with the approach you're proposing is that the implementation would have to specially treat indirect buffers to keep their data on the CPU because of the need for emulation on so many platforms, so they would be very different from all of the other types of buffers, and have to be handled specially in many places in the WebGL implementation and ANGLE. This would be definitively more complex than the current approach - which is already somewhat complex, especially handling emulation, instancing, BaseVertex/BaseInstance, and workarounds for driver bugs which still exist on some commonly-used platforms. The current approach trades off multiple draw calls from JavaScript for the ability to pass their arguments down in one call via typed arrays, which has been measured as beneficial in multiple scenarios. The working group doesn't plan on pursuing phrasing these as indirect draw calls. -Ken > -Won > > >> >> -Ken >> >> >> On Wed, Sep 11, 2019 at 6:38 PM Won Chun (won...@) < >> public_webgl...@> wrote: >> >>> Hi Ken, >>> >>> My thoughts on these extensions are not meant to imply any shortage of >>> thought on the part of anyone involved. And thank you for giving my >>> drive-by commenting some fair consideration. I think some of what you say >>> is beyond dispute: I 100% believe that as written that WEBGL_multi works as >>> advertised and was a relatively straightforward way to achieve this >>> particular goal (one of many, I'm sure, that you and your team juggles). >>> And I am not surprised that this is a win even without hardware support >>> since you can amortize validation and various overheads. I am interested it >>> trying out this extensions, but of course it means our engine would first >>> have to do a significant amount of work to atlas and group vertex data -- >>> work we'd frankly benefit from without this extension. One case where the >>> win is likely significant would be shadow map rendering, since there is no >>> shader/uniform variety across draw calls in that case. >>> >>> So, yes, I'm an interested customer. And of course it would be nice to >>> be able to update shader and uniform bindings per draw call, but would that >>> ever be supported directly be hardware? There was all the bindless >>> texture/AZDO efforts prior to Mantle/Vulkan (details escape me), but is >>> that the API we'd want to encourage? As someone who is currently managing a >>> production WebGL renderer that will have to maintain compatibility with >>> WebGL1 as we migrate to 2 and beyond, I'd rather not to have to deal with a >>> whole zoo of drawing APIs. My contention is that ARB_multi_draw_indirect >>> can grow from WebGL1 all the way to WebGL2-compute, and conceptually maps >>> to the modern APIs. >>> >>> It is not a coincidence that they all share the same indirect structure! >>> It is also a very simple structure that can be manually packed into a >>> single Uint32Array. It already supports all the relevant fields, so I don't >>> understand the point about difficulties layering extensions for >>> baseVertex/Instance. I feel like this approach could only simplify things, >>> but perhaps I'm not understanding. >>> >>> I think one point that I wasn't very clear about was the notion of >>> introducing a new kind of buffer, indirect buffers. I think one point of >>> confusion is that these indirect buffers would have to live in the GPU. >>> Certainly not! Buffer[Sub]Data and friends have usage hints, and these >>> hints could determine the actual memory placement. For STATIC_DRAW on GPUs >>> that support it, maybe they do live on the GPU, but otherwise it could just >>> be on the CPU. The purpose of introducing indirect buffers is analogous to >>> eschewing client-side vertex arrays in WebGL. Instead of sometimes >>> transacting in CPU arrays, keep the API interface uniform and transact in >>> opaque blobs. In WebGL, this gives a convenient place to cache input >>> validation because it provides the opportunity to inspect changes (it is >>> difficult to get this with raw memory-style interfaces). >>> >>> I would hypothesize that this combination of factors: the ability to >>> cache input validation and the fact that ARB_multi_draw_indirect is closer >>> than EXT_multi_draw to what the GPU wants means that this, the indirect >>> struct approach. But even besides that, I find it a better long-term >>> interface. >>> >>> -Won >>> >>> PS if someone is pressuring you to implement display lists, as someone >>> who has written a display list compiler I applaud you for pushing back. >>> WebGL doesn't even have the begin/end drawing API so this request wouldn't >>> even really make much sense to me. >>> >>> >>> >>> >>> On Wed, Sep 11, 2019 at 7:24 PM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>>> Hi Won, >>>> >>>> We gave this a great deal of thought during the design of these >>>> extensions. Unfortunately it was impractical to phrase them as indirect >>>> calls because that would have mandated that the data be uploaded to the GPU >>>> and/or read back to the CPU implicitly, and that would have made the >>>> implementation so complex that the extensions never would have shipped. We >>>> felt that phrasing these draw calls as generalizing the single integer >>>> arguments into arrays (or typed arrays) of integers was a fairly small and >>>> natural step forward, which is why they aren't phrased as an array of >>>> client-side structs. Our colleague Shrek (CC'd) is now adding BaseVertex >>>> and BaseInstance versions of these draw calls as new extensions. If the >>>> original extensions had been phrased as an array of client-side structs, >>>> the addition of new fields would have presented a problem. >>>> >>>> As it stands, these extensions can actually be emulated under the >>>> JavaScript layer and still provide a significant performance boost. >>>> >>>> One of our partners, Fraunhofer, tested them in their real-world >>>> instant3DHub CAD/CAM application. On lower end hardware, the multi-draw >>>> extension improved batching so much they were able to see a 17% improvement >>>> in framerate. Even larger CPU cost reductions have been seen on >>>> draw-call-heavy workloads. >>>> >>>> CC'ing Austin and Kai who designed and implemented these extensions for >>>> any further thoughts that they may have. >>>> >>>> Please give these extensions a try in your application (they're behind >>>> the --enable-webgl-draft-extensions flag in Chrome) and tell us how they're >>>> working. Also, if you have any ideas about other simple extensions that >>>> could be built on top of these - for example, needing to update a uniform >>>> in each of these draw calls - please post here. >>>> >>>> For the record, the working group is not intending to start building >>>> fully general display list extensions for WebGL at this point. >>>> >>>> -Ken >>>> >>>> >>>> On Tue, Sep 10, 2019 at 9:33 PM Won Chun (won...@) < >>>> public_webgl...@> wrote: >>>> >>>>> tl;dr: maybe the inspiration for multi-draw-style interfaces should be >>>>> inspired by more modern extensions and APIs to avoid future headache? >>>>> >>>>> I have spent a long time away from WebGL, but I am back, with a new >>>>> email address. >>>>> >>>>> I am pretty excited by anything that improves draw call submission, >>>>> even in the specific use case enabled by >>>>> https://www.khronos.org/registry/webgl/extensions/WEBGL_multi_draw/ >>>>> >>>>> But I find the interface to this call a little odd. It appears to be >>>>> based on the fairly ancient >>>>> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multi_draw_arrays.txt >>>>> >>>>> Ancient-ness is well and good, and probably means that implementations >>>>> are probably mature and widespread. Excellent! But please indulge me as I >>>>> proffer an alternative. >>>>> >>>>> One of the benefits of living in the graphics time capsule of WebGL is >>>>> that we can operate with a great deal of foresight. What are related >>>>> drawing APIs that would likely be supported in the future? Possible >>>>> sources of inspiration include drawElementsIndirect, which is included in >>>>> webgl2-compute: >>>>> https://www.khronos.org/registry/OpenGL-Refpages/es3.1/html/glDrawElementsIndirect.xhtml >>>>> >>>>> And the multi-draw version of this, in GL4: >>>>> https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMultiDrawElementsIndirect.xhtml >>>>> >>>>> And there are similar APIs in Vulkan, Metal, and D3D12. >>>>> >>>>> The difference between the old and new multi-draw styles is that >>>>> instead of parallel arrays, the newer APIs use an array of structs. This >>>>> seems like a largely cosmetic change, but the important difference is that >>>>> these APIs allow the structs to originate from GPU memory (i.e. from a >>>>> compute shader). Not that this is a common thing! But the point is that >>>>> maybe there is not much downside to supporting this style now, with a >>>>> subset of the total capability, and layering additional functionality >>>>> (indirect buffers, base instance support, etc) by introducing extensions >>>>> that relax the constraints. The benefit would be to establish a best >>>>> practice very early and ease future migration confusion. I think this would >>>>> likely extend to future APIs -- consider the indirect structures used in >>>>> Vulkan, Metal and D3D12: >>>>> >>>>> >>>>> https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkDrawIndexedIndirectCommand.html >>>>> >>>>> >>>>> https://developer.apple.com/documentation/metal/mtldrawindexedprimitivesindirectarguments >>>>> >>>>> >>>>> https://docs.microsoft.com/en-us/windows/win32/api/d3d12/ns-d3d12-d3d12_draw_indexed_arguments >>>>> >>>>> They are all essentially: >>>>> >>>>> typedef struct D3D12_DRAW_INDEXED_ARGUMENTS { >>>>> UINT IndexCountPerInstance; >>>>> UINT InstanceCount; >>>>> UINT StartIndexLocation; >>>>> INT BaseVertexLocation; >>>>> UINT StartInstanceLocation; >>>>> } D3D12_DRAW_INDEXED_ARGUMENTS; >>>>> >>>>> An issue with the modern-API approach is dealing with this >>>>> array-of-structs situation. Namely, it would be terribly inefficient to use >>>>> a JS array of JS objects for this API. But notice that all the fields in >>>>> the indirect structs are just 32-bit integers (admittedly, of mixed sign). >>>>> That means it is totally reasonable to just use a Uint32Array most of the >>>>> time, and sticklers that need those sign bits could use DataView. Another >>>>> alternative would be to disallow negative (or non-zero) vertex offsets (and >>>>> this restriction could be lifted by extension). >>>>> >>>>> Another issue is validation. It would be nice if the indirect array >>>>> didn't need to be walked each time. A possible solution to that would be >>>>> if, like WebGL vertex arrays, you always interacted this API with a bound >>>>> indirect buffer. Until computer shaders were availble, these indirect >>>>> buffers would always be created (and probably stored) on the CPU, but the >>>>> WebGL/ANGLE benefit would be that there would be an encapsulated thing >>>>> where validation can be cached. >>>>> >>>>> Whew, this was a long one. Thoughts? >>>>> >>>>> -Won >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: