kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

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):

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
> 
> 
> 
> _______________________________________________
> 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
>

Attachment: signature.asc
Description: OpenPGP digital signature