| ID: | 5973 |
| From: | rn...@igor2.repo.hu |
| Date: | Sun, 5 Mar 2023 11:29:51 +0100 (CET) |
| Subject: | [pcb-rnd] project state update |
Hi all, a quick project state update, mostly on the progress in February. 1. sch-rnd Objective: first stable release We've got a lot of bugreports on IRC; the most productive reporter is Erich at the moment. I've managed to fix all the bugs reported, plus the critical bugs we had from before librnd4. At the moment sch-rnd is rather usable with only low prio bugs known. So it is very close to what we'd have as 1.0.0 eventually. It's a good time to start using sch-rnd on small boards in production (the tutorial videos can teach you the basics quickly). Our next release, probably the last beta-test release, is end of March. Then there'd be a short dev cycle, mostly as a safety margin, to be able to fix critical bugs then our target for 1.0.0 is early May. (I do not plan to implement new features in sch-rnd before 1.0.0 to avoid adding more bugs.) 2. pcb-rnd Objective: polygon lib rewrite Meanwhile I've started to work on the poly lib rewrite (also nlnet sponsored). So far: - I've written a tester so I can easily compare the original code to the new code to make sure I don't change behavior - I've found an English translation of the original paper that describes most of the algorithm; it's a bit broken, but usable - I am done with the first iteration of the function-by-function rewrite; I have to keep the original API and I decided to mostly keep the original internal structure as well for now, for easier comparison/debug (but this will change later, as one of the reasons for the rewrite is to clean these things up). So far the new code gives the same output as the old code on the test bench. - I did some profiling and I've identified a bottleneck. With a few hours invested I changed a critical code path and now the code is 2x faster on a test case that is relevant to us. The test case is drawing a large rectangular polygon the subtracting a lot of smaller, pseudo-random generated polygons from it. (This emulates the clearance cutout process that happens when you load a board with a large "ground plane" or move a such a polygon). - Because I've read the paper a few times and because rewrote the code, I almost fully understand the algorithm now. With this understanding there are three things getting unlocked: - I have a smallish nlnet task for later on, checking whether using the GPU for speeding up polygon clipping is possible; now that I know more about the algo, I am less optimistic about this. The algorithm is rather smart and is very much topological, converting the whole problem from 2d to 1d mostly. And GPU is not very efficient on 1d problems. But I may be able to find some part that can be translated into a 2d or 3d problem. - our constant struggle in pcb-rnd with polygons becoming invalid on unexpected normal-looking situation; during the testing I've figured a few root causes of this so I will have a chance to debug and fix them. - I see adding one of the critical features the whole effort was started for, "arc in contour", is feasible. For most parts it's not even hard, just a lot of code. There are a few trickier parts, but nothing that's too complicated to implement. If I can add arcs, that will be a major speedup because we will be able to use 1..3 arc objects instead of a few dozens to few hundreds line segments (in arc approximation now). Since the performance of the algrotihm mostly depends on the "number of objects in the polygon contour", worse than linearly, that reduction would also cause a major speedup in every operation. Best regards, Igor2
Reply subtree:
5973 [pcb-rnd] project state update from rn...@igor2.repo.hu