kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Thanks for the data, Seth.

I'm curious, has anyone tried my other patch (changing from bitset to
vector) to see if it has any performance impact on your machines?

-Jon

On Thu, Feb 1, 2018 at 11:58 AM, Seth Hillbrand <seth.hillbrand@xxxxxxxxx>
wrote:

> Hi Jon-
>
> I see a similar situation to JP (although my machine is not so fast).
> Loading all layers is fast.  Changing the dcode display takes about 40s on
> my machine and no difference in the patch.  Interestingly, it is faster for
> me to close all layers, change the dcode display and re-open the files than
> it is to change the display with the files open.
>
> I also tried the halftone image from https://bugs.launchpad.
> net/kicad/+bug/1745050 in pcbnew.  Without the patch, it takes about 30
> seconds to re-draw the vertices.  With the patch, it takes about 25s.  By
> making the new size a power of two (right now it is 2^20, so if we make it
> 2^24), I get a 20s load time.  However, increasing beyond my GPU's memory
> (2^26) results in no image whatsoever.  So I suspect that more limited GPUs
> may see a similar issue sooner.
>
> -S
>
> 2018-02-01 7:48 GMT-08:00 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
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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
>
>