[Development] QSceneGraph debugging

Thu Jun 11 16:16:55 CEST 2015

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.senyk at 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 at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>