kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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