On 26 November 2016 at 19:55, Thiago Macieira <thiago.macie...@intel.com> wrote:
> On sábado, 26 de novembro de 2016 13:01:03 PST Ch'Gans wrote:
>> On 26 November 2016 at 11:57, Thiago Macieira <thiago.macie...@intel.com>
> wrote:
>> > That's a useless result. Your tool is telling you not the proper time of
>> > each function, but the aggregate time of that function and everything it
>> > called.
>> Well, I thought that maybe the role of _dl_runtime_resolv_avx was to
>> actually only resolve the function, not execute it as well...
>
> Yes, and after resolving that function, it calls that function.
>
>> > It's like saying that your application spends most of its time in main. We
>> > knew that... Drill down and find out what's happening. Very likely, the
>> > effect you turned on is too slow for your CPU or GPU, or in combination
>> > with some other system-dependent use.
>>
>> /proc/cpu tells me that the CPU supports AVX (no trace of AVX2). So
>> could it be a bug somewhere. basically the wrong implementation is
>> called, or my CPU is not good enough, well it's a modern AMD: "AMD
>> FX(tm)-8320 Eight-Core Processor".
>
> That explains why _dl_runtime_resolve_avx was used, as opposed to the non-AVX
> version of it.
>
> Note that I can't find that function in glibc's source code. If it really is a
> problem, then your distribution caused it by applying a patch and you should
> complain to them. But I don't think that this the problem. Stop looking at
> _dl_runtime_resolve_avx, that's a red herring. Your problem is elsewhere.
It's in linux-ld.so. Anyway I gave up about the AVX2, i think you are
right, it was just a red herring.
But I gave another go at running valgrind, this time i started with
event logging off, then started the test app, start zooming until the
app slows down, then switched event logging on, zommed in a few times,
switched logging off and closed the test app.
I think i have now better data to analise.
If i sort the data by "Incl. Cost: Ir", then the top one is
QEventLoop::exec, called 1.2E9 times, then lot of event processing
related functions, then the first event handler:
QGraphicsView::paintEvent, then scene drawItem, quickly follow by the
drop shadow effect draw(), the drop shadow filter draw(),
qt_blurImage() followed by expblur<>(), after that the cost drop
drastically, so to resume roughly:
| Cost , function
|
1,212,124,165, QEventLoop::exec()
...
1,169,460,682, QGraphicsView::paintEvent()
...
1,123,576,248, QPixmapDropShadowFilter::draw()
0,907,246,806, qt_blurImage()
0,861,710,958, expblur<>()
0,181,757,861, fillRect_normalized()
...
What i'm trying to say here, is that almost all the events seem to be
targeted at repainting the drop shadow, and I can tell you that the
test app ran for only a couple of seconds during which i was
wheel-zooming, and the GraphicsView had visually changed only 4 or 5
times.
So something tells me that, for some reasons, the drop shadow is
repainted way too many times, yet the app on the screen is updated
only once every second or so.
Maybe the event loop is going crazy recursive or something like that?
In term of self cost, expblur<>() is the top one, with a score of
698,479,995, the second one is far behind with "only" 112,862,101
(comp_func_solid_SourceIn)
Last thing, if i disable valgrind "cycle detection", the the top
function becomes QWidgetPrivate::drawWidget, with in incl. cost of
2,043,925,229...
Chris
>
>> What I'm trying to find out, is that is it a Qt problem (relying on
>> AVX2 on a CPU that doesn't support it), or is it a KUbuntu problem, or
>> ...
>
> I'll take the "..." as the problem.
>
>> As well, is there a simple way to disable AVX2 within Qt?
>
> Yes. But it's already disabled. And that's not the problem.
>
>> I find it a bit crazy that Qt graphics performance are that bad on a
>> modern desktop computer using latest (or almost) AMD CPU.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
