We used to perform uniform minization between adjacent render commands all the time.
Since this can yield to a higher CPU usages (but more efficient rendering submission),
we now make this step optional.
[ChangeLog] QSortPolicy add Uniform mode (to control whether uniform minization
should be performed)
Change-Id: I5c0e0dba22400a9884ee1d75426fd76b073fdcb5
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Work was done in postFrame() in main thread anyway, so reduce
amount of jobs slightly
Change-Id: I8bbb3efcaf9246eb8df1033bde133bc16233f889
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
Removes the jobs who's only purpose was to send a message to the frontend.
Now added a jobsDone() call to render which is called from main thread
when jobs are completed, so it's safe to sync data to frontend.
Added a task trace for the backend to front end synching.
Change-Id: I587462bea353c5d5a0065b542adcacef4dedb05f
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
Previous fix was not closing the loop on every primitive,
just the last one.
Task-number: QTBUG-71919
Change-Id: I22d52258477b0c4777118ee36a0b3868da982885
Reviewed-by: Volker Enderlein <volker.enderlein@ifm-chemnitz.de>
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
Deprecates the message classes and the public APIs to send/receive them.
(deprecates the constructors as deprecating classes breaks syncqt)
Change-Id: I4908f15c3c5f1d63969a0f2e11f6ecb22e2e3748
Reviewed-by: Mike Krus <mike.krus@kdab.com>
When using OnDemand rendering, Scene3D would lock if nothing in
the scene were to change. By being blocked, it would also not
process jobs for other aspects (input, logics). That would prevent
things like a CameraController from running, which in turn would
make it impossible to move the camera and trigger a change in the
scene to request rendering.
Additionally, Scene3D would ignore whether the Qt3D renderer actually
needed rendering or not as it was watching on its own the changeArbiter
for changes to decide whether rendering was required or not. This would
ignore the case where Qt3D needs multiple frames to render a correct frame
(e.g loading buffers, shaders at frame n, rebuilding commands at frame n+1)
Scene3D now asks the Qt3D renderer by calling the shouldRender() function
to decide whether rendering is needed or not, in addition to watching the
changeArbiter.
Regardless of whether rendering is needed, it now let each aspect process
jobs. This ensures things like FrameAction/Input are processed.
Then, Scene3D decides whether full rendering is required or whether
it only has to be called to allow the Qt3D simulation loop to proceed for the
next frame. If the latter, it does it so as not to have QtQuick trigger a
redraw.
Change-Id: I870f773c224286d6b7ec0f6045319e51e09cbf8e
Task-number: QTBUG-80521
Reviewed-by: Mike Krus <mike.krus@kdab.com>
Surprisingly it's hard to notice its effect in the speed of execution,
frame preparation looks to be more or less the same with the profiler.
However with vtune, the profiling traces show a huge difference with
QHash, mainly in time spent allocating memory. It shows a noticeable
reduction in CPU usage.
On bigscene-cpp with 600 entities
QHash -> On a 158s run, CPU time is 112s (70%)
free accounts for 26s (23%), malloc 24s (21%)
QVector -> On a 190s run, CPU time is 110s (58%)
free accounts for 5s (4.5%), malloc 4.7s (4.2%)
Change-Id: I880d44b1acf7f051e479ed356864c3caf407f23f
Reviewed-by: Mike Krus <mike.krus@kdab.com>
Which is only very rarely required by user applications.
Avoid useless memory allocations every frame
Change-Id: I69ea73ebfffdbe928f99333b4d1dd90cf4ada430
Reviewed-by: Mike Krus <mike.krus@kdab.com>
This otherwise yield for lots of reallocations that could be avoided.
The gains seem to be about 2/3% of cpu usage according the analysis
with vTune.
It does indeed mean that for smaller uniforms vec4, float, sampler
we are wasting a bit of memory. The impact of this is likely to be
unsignificant though.
Change-Id: Id72c81a795bf9326ef48b170bb0806de9b430412
Reviewed-by: Mike Krus <mike.krus@kdab.com>
All RV end up using exactly the same vector before filtering it down
on per RV specifics. No point in compute RV times the same thing.
Change-Id: Ia674095627771c8e9ada090fa47623cbbbd8a3f8
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
In most cases, we can generate the RenderCommands once and reuse them in
subsequent frames only updating the uniforms. We still have to copy the
RenderCommands as the renderer renders while we start preparing the next frame.
This is still faster than regenerating them entirely.
Regenerating the entire commands will happen only when FrameGraph or Scene
structure changes. That should rarely be happening on a per frame basis.
Next step could be to look at how to only update commands for Entity with Parameters
that have changed.
Change-Id: I202870850a46fcd3946f81bffddb7027d192f374
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
Remove useless includes, clear up commented out or unused code
Change-Id: Id3382b16108d79f1e2522d43463c8d70aef8fcb2
Reviewed-by: Mike Krus <mike.krus@kdab.com>
Otherwise the FG cache is not rebuilt and we might have dangling
pointers around.
Change-Id: Id97de41092617acbf067fcac4cf7805c2eb715da
Reviewed-by: Mike Krus <mike.krus@kdab.com>
We otherwise assert in the case we create an empty buffer
that is empty but referenced by Attributes.
This is still a valid case as buffer data can be set later
on.
Change-Id: Ida198f5815f6cbb488b6b27436c4238146c3ae39
Reviewed-by: Mike Krus <mike.krus@kdab.com>
Also removes last couple of messages updating backend to frontend.
Change-Id: I65056c7cf5ff06efab9c9a205f843ed882f9c0be
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
Introduce mechanism to notify backend nodes of changes in relationship
between nodes. If a component is added or removed from an entity,
or if a node is added or removed from a property of another node, then
just rely on the node being marked as dirty when syncing takes place.
For nodes that do not support syncing, messages are delivered as before
but allocated on the stack rather than the heap.
Change-Id: I06affac77e42a9998d9c7f44e231c7724c52b320
Reviewed-by: Mike Krus <mike.krus@kdab.com>
Lead to a regression where some uniforms wouldn't have the expected
value following destruction/reconstruction of the backend Parameter.
Change-Id: Id747cb2903f25a4a5cc0c5d479a09805d317f380
Reviewed-by: Mike Krus <mike.krus@kdab.com>
When the job is complete and we're back in the main thread,
the job can look up the frontend node and deliver the hits
directly. This saves allocating messages.
Unit test changed quite a bit as it needs an aspect engine &
manager to pass to the job for looking up nodes.
Change-Id: I09d88c5e478fa387690af522c5798a37f3f2d9a6
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>