kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

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)

-Jon

On Thu, Feb 1, 2018 at 6:05 AM, jp charras <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
> >>
> >> 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
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>