On 11.06.2015 15:50, Gunnar Sletta wrote: > Hi Thomas, > > You are hitting one of the less ideal code paths with this testcase, see my > comments below. I think the core problems are already outlined in > https://bugreports.qt.io/browse/QTBUG-42853. > >> On 11 Jun 2015, at 14:32, Thomas Senyk <thomas.se...@pelagicore.com> wrote: >> >> Hi, >> >> currently trying to debug a weird behavior on a TI chip (armv7 with a >> SGX GPU). >> >> >> I have a fairly simple QML with a simple GridView with model:200 and >> delegate:Text{text: "T#"+index}. >> (it's a tiny bit more then that, but for argument sake this should be >> enough) >> >> Then an animation scrolling up and down (on "contentY", without items >> leaving the screen to avoid item creation in performance debugging). >> >> So far so good .. plain 60fps, all frames ~16ms >> >> But when I do >> color: Qt.rgba(Math.random(), 1, 1,1); [4] >> on the Text-delegate, then I get very bad performance (<20fps). >> >> Looking closer at the frame times it's good performance for a couple of >> frames (~16ms) and then one terrible frame with >200ms. >> >> That in mind I dug further .. and found that it's: >> In every "bad" frame >> Updater::visitGeometryNode [1] >> this is called with m_added==1 >> >> And this causes (because e->root==0 [2]) >> renderer->m_rebuild |= Renderer::FullRebuild; >> >> Then nearly all the frame time (>200ms) is spend uploading the new >> batches in Renderer::uploadBatch [3] >> >> >> Comparing all that with the "black"-case I see: >> - Batch 0 0x281f58 upload root: 0x1a4a58 >> - element: 0x27ad18 Rect( -0.833333 0.576389 27.4661 13.5365 ) >> node: GeometryNode( 0x27ab30 triangles #V: 12 #I: 18 x1= -0.833333 y1= >> 0.576389 x2= 27.4661 y2= 13.5365 materialtype= 0xb6fad3c4 ) order: 1 >> - element: 0x279ca0 Rect( 79.1667 0.732639 107.666 13.3889 ) node: >> GeometryNode( 0x279ab8 triangles #V: 12 #I: 18 x1= -0.833333 y1= >> 0.732639 x2= 27.6658 y2= 13.3889 materialtype= 0xb6fad3c4 ) order: 2 >> - element: 0x278c28 Rect( 159.167 0.576389 187.327 13.3889 ) node: >> GeometryNode( 0x278a40 triangles #V: 12 #I: 18 x1= -0.833333 y1= >> 0.576389 x2= 27.3273 y2= 13.3889 materialtype= 0xb6fad3c4 ) order: 3 >> >> ...all in one Batch. >> >> For color: >> - Batch 0 0x2845f8 upload root: 0x16bd58 >> - element: 0x283a20 Rect( -0.833333 0.576389 27.4661 13.5365 ) >> node: GeometryNode( 0x283838 triangles #V: 12 #I: 18 x1= -0.833333 y1= >> 0.576389 x2= 27.4661 y2= 13.5365 materialtype= 0xb6f583c4 ) order: 1 >> - Batch 1 0x1702c8 upload root: 0x16bd58 >> - element: 0x2829a8 Rect( 79.1667 0.732639 107.666 13.3889 ) node: >> GeometryNode( 0x2827c0 triangles #V: 12 #I: 18 x1= -0.833333 y1= >> 0.732639 x2= 27.6658 y2= 13.3889 materialtype= 0xb6f583c4 ) order: 2 >> - Batch 2 0x2853a0 upload root: 0x16bd58 >> - element: 0x281930 Rect( 159.167 0.576389 187.327 13.3889 ) node: >> GeometryNode( 0x281748 triangles #V: 12 #I: 18 x1= -0.833333 y1= >> 0.576389 x2= 27.3273 y2= 13.3889 materialtype= 0xb6f583c4 ) order: 3 >> >> ... one node one batch [4]. >> >> So batching can't work on differently colored elements/text/..? >> ... is color a uniform per draw call? >> >> >> >> From the past I know that my test-case had good performance on older >> SoCs .. so the question I have right now are: >> >> [1]: There shouldn't be a new Node .. nothing new is created? > > I don’t understand the question.
Nothing in the UI is entering/leaving screen or explicitly created/destroyed ... so I wonder where the new Node comes from. I'll look closer at what the Node is. > >> >> [2]: Should one simple node cause all batches to be re-uploaded? >> .. or better: why do I get Renderer::FullRebuild? > > It depends, but when you are adding and removing nodes it may happen. If this > is combined with plenty of batches this will kill performance. More than 100 > discrete glMap/Unmap/Draw calls per frame is likely to not be feasible on > embedded hardware. And the renderer is also adding some overhead when the > number of batches go up. > Got it .. so somehow the above mentioned "new Node" causes all the restruct/data-re-upload .. we'll look into it. >> [3]: If all above is normal, then maybe it's the data upload that's to >> long? glBufferData in unmap is 300-400us on average (with ~200 of them >> in each "bad" frame) .. is that "normal"? sounds rather long for a >> couple of vertices (if it's only a couple of vertices?) > > Uploading and scheduling drawing is slow. This is why we want things to be > batched so we minimise the overhead. You are currently hitting a worst case. > >> [4]: And again: I guess batching on non color-sharing elements is >> supposed to not work? > > Text elements are only batched if they have the same color. > > The Rectangle node uses vertex-coloring which is batchable. The Image nodes > use a texture atlas which means they share state, so small-medium sizes > images are also batchable. We could have fixed the text node by putting the > text color into the text vertices, but I have not done that as it would make > the already significant memory footprint even higher. And most text elements > are black, gray or white anyway, so in practice it hasn’t been that bad. But > as you see, it doesn’t cover everything. > > As the task indicates, I'v been toying with the idea of putting the glyphs > into point sprites, so we could get away with one vertex per glyph and that > way make it cheap and sensible to make it per-vertex colored which would > allow batching across colors, but I haven’t gotten around to that yet. > Got it! So random (/many) colors on fonts are a no-go for now! Fair enough given the overall good performance of font rendering in Quick2. FYI: The "real" case is possible not even using many colors .. it was just me initial debug-case to work with. .. and I wanted to unterstand what's going on Thanks! > cheers, > Gunnar > >> >> >> >> Greets >> Thomas >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
