›

Enabling Multi-Threading in Klayout for Improved Rendering Performance

holoeyeholoeye
in KLayout Support

Hello everyone,
I'm currently working with Klayout and facing a challenge regarding performance, especially when dealing with larger .gds or .oas files. I experience significant delays in rendering when opening these files for the first time and also when changing the view (zooming or shifting the focus point).
My query is twofold:
1. Is there a way to enable multi-threading in Klayout to enhance the rendering speed? If so, how can I activate this feature?
2. Is the image rendering in Klayout limited by GPU capabilities? In this case, I'd like to understand if utilizing CPU multi-threading would make any difference, or should I be looking for alternative solutions?
Any help or insight on this matter would be greatly appreciated. Thank you in advance!
Best regards, Jacob

Comments

  • RawrRangerRawrRanger

    Hi holoeye,

    You can tried to tweek around these paramters, generally I found drop cell with size smaller than certain size helps alot.

  • MatthiasMatthias
    edited November 2023

    @holoeye Like RawRanger shows above you can enable multiple threads for rendering.

    GPU is not involved at all and does not help. The performance comes from smart optimization that is beyond GPU capabilities.

    There is a know issue with particular instance arrays, specifically ones generated for dummy fill by a particular $$$ flow. These instance arrays manifest itself in large and seemingly random iterated OASIS arrays which often don't paint efficiently. That is one issue I know of, but there may be others. My daily experience does not offer challenges beyond what KLayout can deal with with very acceptable performance.

    So without analysis of your case it is very difficult to say what options there are. I understand that large testcases cannot be shared, but that is a real show stopper for open source development in the high performance domain. It's not the algorithms or the optimization potential.

    Matthias

  • dick_freebirddick_freebird

    The people with large test cases might be able to
    "strategically mung the design" such that it's of no
    value or threat, but still a useful challenge. If they
    wanted to help.

  • holoeyeholoeye
    edited November 2023

    Hi @RawRanger, hi @Matthias, thank you indeed for your advice. But unfortunately, the Setup/Display/Optimization settings did not noticably change the performance. It sounds like providing a sample file would be helpful ?
    Of course, we really appreciate KLayout 'as is'. But if the rendering could be faster by changing some settings (or the way we structure our files) it would be even better.
    Thus, I think we would be willing to provide a sample file - but just out of curiosity, where would it end up ? In any case, we will think about how to select one that will give most flexibility in that respect, and be glad if someone takes the time to look at it.

  • MatthiasMatthias
    edited November 2023

    Hi @holoeye,

    I can promise to keep sample files private and not publish them or share them with anyone else, but I cannot give warranties beyond that and specifically I cannot sign an NDA. So exchanging test data needs a certain level of trust, but on the positive side there is something you can gain in that process.

    It is usually possible to strip a layout down to some interesting parts and leave away or obfuscate anything that might reveal details of your design. For example I assume that you will find one layer to be specifically slow (multithreading acts on layers, so that may explain why do don't see an effect). You can now try to remove layers that are not interesting. A quick way to remove layers is to save with "visible layers only". You can also choose not to write empty cells.

    Next thing is to obfuscate cell names to hide more details, changing the database unit to something that does not allow to identify a technology node, change layer number or names, remove texts etc.

    Maybe it is also possible to identify pieces that are responsible for the the bad performance, e.g. a specific memory block or something else and you can reduce you test case to that part only.

    In the end you may end up with something that does not reveal functional details and can be shared - not in public, but privately with me. This is when I can start debugging the issue.

    It needs some effort from your side and I cannot promise there will be success, but so far I mostly managed to significantly improve performance.

    Synthetic samples are usually not reproducing the exact problem. I had some frustrating experiences where I debugged a problem and optimized it just to find out the user's issue was something entirely different.

    Best regards,

    Matthias

  • holoeyeholoeye

    @Matthias Thank you indeed for the reply and the explanations and hints. We will try to find a case that is not synthetic and can be shared, and of course without any legal procedure like an NDA. I fully understand this will be based on trust and we would be glad if this helps us and hopefully also others in terms of performance.

  • MatthiasMatthias

    Very good! Thanks for you efforts.

    I'm looking forward to debugging things. I really appreciate getting real-world cases - synthetic ones suck.

    Best regards,

    Matthias

Sign In or Register to comment.
Powered by Vanilla