kicad-developers team mailing list archive

[Jon Evans <cdawzrd@xxxxxxxxx>]

I will look into the layer sorting, I haven't profiled that extensively
yet. I do see improvement in showing DCodes with this patch on my machine
at least, it takes about 40% less time (it's still too long for good user
experience though)

On Feb 1, 2018 10:48, "jp charras" <jp.charras@xxxxxxxxxx> wrote:

Le 01/02/2018 à 15:34, Jon Evans a écrit :
> Thanks for feedback Orson and JP, I will definitely keep investigating.
> FYI I only see a big speed change in GerbView when loading all of the
test files (not just a single
> layer) from the bug report.
> I also see no difference in pcbnew (which tends to have much fewer
vertices)

Exactly, loading all files is fast.

This is only running "Sort Layers if X2 Mode" (or Show / hide DCodes) that
takes a while.
(25s with or without the patch)

>
> -Jon
>
> On Thu, Feb 1, 2018 at 6:05 AM, jp charras <jp.charras@xxxxxxxxxx <mailto:
jp.charras@xxxxxxxxxx>> wrote:
>
>     Le 01/02/2018 à 10:43, Maciej Sumiński a écrit :
>     > Hi Jon,
>     >
>     > TL;DR: I have no idea why it boosts the performance. I would love
to see
>     > some extra input from others, to see if patch helps on other
systems or
>     > at least does not decrease performance on low-spec cards.
>     >
>     >
>     > It is hard to explain why do you see a performance boost. I tried
it on
>     > my machine (integrated Intel GPU), it takes the same time to load
the
>     > files attached to the bug report. You can set WXTRACE environmental
>     > variable to trace vertex allocation (only for debug builds):
>
>     I have a similar result: no significant performance boost.
>     I loaded only one test file "acquire-PWM-F.Cu.gbr".
>     It is fast to load, but takes 12 - 13 seconds to redraw when I run
"Sort Layers if X2 Mode"
>
>     >
>     > WXTRACE=GAL_CACHED_CONTAINER_GPU ./gerbview/gerbview
>     > 10:20:00 AM: Trace: (GAL_CACHED_CONTAINER_GPU) Resizing &
defragmenting
>     > container from 1048576 to 2097152
>     > 10:20:00 AM: Trace: (GAL_CACHED_CONTAINER_GPU) Defragmented
container
>     > storing 1048576 vertices / 44.6 ms
>     > 10:20:04 AM: Trace: (GAL_CACHED_CONTAINER_GPU) Resizing &
defragmenting
>     > container from 2097152 to 4194304
>     > 10:20:04 AM: Trace: (GAL_CACHED_CONTAINER_GPU) Defragmented
container
>     > storing 2097147 vertices / 80.1 ms
>     > 10:20:11 AM: Trace: (GAL_CACHED_CONTAINER_GPU) Resizing &
defragmenting
>     > container from 4194304 to 8388608
>     > 10:20:11 AM: Trace: (GAL_CACHED_CONTAINER_GPU) Defragmented
container
>     > storing 4194300 vertices / 144.7 ms
>     >
>     > It is true that once your patch is applied there are no resize &
>     > defragment operations, but it looks as if it saved only several
hundred
>     > msecs. Maybe it is different for nVidia cards.
>     >
>     > Regarding low-end GPUs: each vertex is 32 bytes, so resizing the
initial
>     > container size from 1048576 to 10485760, changes the initial
occupied
>     > video memory (or RAM if GPU cannot cope with video memory mapping)
from
>     > 32 MB to 320 MB. I traced the container code and it turns out only
very
>     > complex boards (A64-OLinuXino and Chris's motherboard) require 2M
or 4M
>     > vertices in pcbnew, so the majority of the allocated memory stays
unused
>     > for most cases. I think we should look for performance improvements
>     > elsewhere.
>     >
>     > One of ideas I never had the time to implement is to reduce vertex
size
>     > (struct VERTEX) by replacing full color information with an index
to a
>     > color palette stored in an uniform object.
>     >
>     > Another possible modification is to get rid of shader parameters for
>     > vertices that do not use them. It would require two cached
containers -
>     > one for plain vertices, the other for vertices with parameters.
>     >
>     > Cheers,
>     > Orson
>     >
>     > On 02/01/2018 04:29 AM, Jon Evans wrote:
>     >> Next in the series of OpenGL performance work related to this bug:
>     >> https://bugs.launchpad.net/kicad/+bug/1745203 <
https://bugs.launchpad.net/kicad/+bug/1745203>
>     >>
>     >> In the scenario of this bug report (load lots of gerber files,
each with
>     >> lots of items) we struggle with vertex allocation.
>     >> On my Linux system with NVIDIA GPU, the attached patch speeds up
>     >> load/display of the file (and showing of Dcodes) by 50%.
>     >>
>     >> This patch feels kind of like a hack; and I'm not sure if it would
cause
>     >> any issues on low-spec systems.
>     >> I'm curious for input from Orson/Tom and anyone else who has
looked at our
>     >> OpenGL system.
>     >>
>     >> But, if it is safe, it could be a nice one-line speed improvement
for
>     >> scenarios where we throw tons of items at the OpenGL GAL.
>     >>
>     >> Maybe a longer-term fix would be to take a look at the vertex
container
>     >> algorithms and see if we can be more intelligent about when and
how much we
>     >> allocate memory to reduce this overhead without having such a huge
initial
>     >> size.
>     >>
>     >> -Jon
>     >>
>
>
>     --
>     Jean-Pierre CHARRAS
>
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers <
https://launchpad.net/%7Ekicad-developers>
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:
kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers <
https://launchpad.net/%7Ekicad-developers>
>     More help   : https://help.launchpad.net/ListHelp <
https://help.launchpad.net/ListHelp>
>
>


--
Jean-Pierre CHARRAS

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp