It makes sense. Are we sure that the current Emscripten OpenGL to WebGL bindings do not imply this kind of behavior despite the fact it's not used in the original OpenGL code? There might be some kind of restriction (or faulty implem) that would cause all index buffers to be considered dirty/dynamic. How can we check?
On Wed, Aug 20, 2014 at 3:56 PM, Floh <flo...@gmail.com> wrote: > Both I guess, but mainly (a): > > (a) if indices are dynamically written every frame then the index buffer > (or a range of it) is marked as dirty and must be re-validated (I guess > this range check happens later at draw-call-time, and the actual details > heavily between Firefox and Chrome as far as I know), but the important > thing is that every time indices are updated a fairly expensive operation > needs to take place > > (b) I guess this(putting indices not into buffer objects but into raw > client-side memory) means that the WebGL implementation has to assume that > the index data is different for each call, but I am not sure of the > implementation details > > The take-away is that dynamic index updates are much more expensive then > on desktop GL and should be avoided at all cost (I usually pre-allocate a > big index buffer and fill it with as many triangle indices as I am > rendering at maximum, and then render a part of it, depending on how many > primitives I want to render). > > -Floh. > > Am Mittwoch, 20. August 2014 15:37:58 UTC+2 schrieb Jean-Marc Le Roux: >> >> Another thing that should be avoided in WebGL at all cost (also in PNaCl) >>> is to upload dynamic indices, since these must be checked for out-of-bounds >>> indices, and the code behind this is surprisingly complex (Firefox build a >>> binary tree structure from the indices to speed up future range checks for >>> instance). >> >> >> By dynamic indices, you mean: >> a) creating the index buffer with GL_DYNAMIC_DRAW >> or b) calling glDrawElements() with an actual int* for the "indices" >> argument? >> >> >> On Wed, Aug 20, 2014 at 3:33 PM, Floh <flo...@gmail.com> wrote: >> >>> Yes of course, everything is in buffer objects, there are no client-side >>> arrays at all in the engine. The buffers for the dynamic vertex data are >>> double-buffered to avoid locks (however in the native case there still >>> seems to be a lock where OpenGL has to wait, so maybe I'll even try triple >>> buffering next). >>> >>> Also, the demos which use minimal draw calls have basically identical >>> performance between WebGL and native (e.g. the instancing demo only has one >>> draw call for the scene, and the GPU particle demo has 2 draw calls, plus >>> one more for the debug text output). >>> >>> Another thing that should be avoided in WebGL at all cost (also in >>> PNaCl) is to upload dynamic indices, since these must be checked for >>> out-of-bounds indices, and the code behind this is surprisingly complex >>> (Firefox build a binary tree structure from the indices to speed up future >>> range checks for instance). >>> >>> Cheers, >>> -Floh. >>> >>> Am Dienstag, 19. August 2014 21:52:47 UTC+2 schrieb msc: >>>> >>>> On 2014/08/18 9:30, Floh wrote: >>>> >>>> >>>> >>>> So in conclusion: >>>> - JS performance is perfectly fine, both in Chrome and FF (even IE11 >>>> and the latest Safari) >>>> - WebGL is the bottleneck, try to minimize calling into WebGL as much >>>> as possible >>>> - OSX OpenGL sucks ass, especially with an Intel GPU >>>> >>>> It sounds like you are modifying the vertices for each draw call. If >>>> that is the case then to determine webgl vs. native performance you should >>>> compare WebGL drawing with drawing using buffer objects in native OpenGL It >>>> is not clear you did that in all cases you cited. Comparing client-side >>>> array draws with WebGL draws (which use buffer objects) will incorrectly >>>> assign "overhead" to WebGL. >>>> >>>> Regards >>>> >>>> -Mark >>>> -- >>>> 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 >>>> 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます. >>>> >>>> NOTE: This electronic mail message may contain confidential and >>>> privileged information from HI Corporation. If you are not the intended >>>> recipient, any disclosure, photocopying, distribution or use of the >>>> contents of the received information is prohibited. If you have received >>>> this e-mail in error, please notify the sender immediately and permanently >>>> delete this message and all related copies. >>>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "emscripten-discuss" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>> topic/emscripten-discuss/HH86_XDgLj4/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> emscripten-discuss+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> *Jean-Marc Le Roux* >> >> >> Founder and CEO of Aerys (http://aerys.in) >> >> Blog: http://blogs.aerys.in/jeanmarc-leroux >> Cell: (+33)6 20 56 45 78 >> Phone: (+33)9 72 40 17 58 >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "emscripten-discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/emscripten-discuss/HH86_XDgLj4/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > emscripten-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Jean-Marc Le Roux* Founder and CEO of Aerys (http://aerys.in) Blog: http://blogs.aerys.in/jeanmarc-leroux Cell: (+33)6 20 56 45 78 Phone: (+33)9 72 40 17 58 -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
