kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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