| *** tpb has joined #symbiflow | 00:00 | |
| *** _whitelogger has quit IRC | 02:58 | |
| *** _whitelogger has joined #symbiflow | 03:01 | |
| *** OmniMancer has joined #symbiflow | 06:12 | |
| *** Bertl is now known as Bertl_zZ | 06:18 | |
| *** lopsided98 has quit IRC | 07:06 | |
| *** lopsided98 has joined #symbiflow | 07:08 | |
| *** kgugala has quit IRC | 08:18 | |
| *** citypw has joined #symbiflow | 10:05 | |
| duck2 | so i left `make buttons_basys3_bin` running overnight and woke up to frozen laptop and some corrupted files | 10:08 |
|---|---|---|
| sf-slack1 | <kgugala> it may consume a lot of RAM | 10:09 |
| sf-slack1 | <kgugala> how much memory do you have on your laptop? | 10:09 |
| duck2 | i think mem + swap were full so computer just went derp. how much RAM do i need to build the archs? | 10:09 |
| duck2 | 4gb :( | 10:10 |
| sf-slack1 | <kgugala> memory consumption depends on the project | 10:10 |
| sf-slack1 | <kgugala> but 4gb is way to low | 10:11 |
| sf-slack1 | <kgugala> we will optimize the flow to consume less memory | 10:11 |
| sf-slack1 | <kgugala> it's on the TODO list | 10:11 |
| sf-slack1 | <kgugala> duck2: do you want yo take a look on that? | 10:12 |
| duck2 | i think the .xml files are generated but vpr just makes all things break in seconds, and computer acts weird when rebooted unlike the other times i went oom | 10:21 |
| duck2 | i wonder if it tries to load a huge file into memory | 10:21 |
| duck2 | kgugala: the arch generation or vpr? arch generation also takes a lot of memory but it passes through when it's the only thing running. i also tried to run prjxray_routing_import.py with pypy and it was ok i think | 10:26 |
| sf-slack1 | <kgugala> vpr creates a lot of data structures in RAM | 10:27 |
| sf-slack1 | <kgugala> this could be the reason why your laptop cannot handle it | 10:27 |
| duck2 | i agree. i can try and profile it while restricting its memory. i know that pnr is a hard operation but it's the first time my laptop is humiliated like this and i'm offended :D | 10:32 |
| sf-slack1 | <kgugala> :slightly_smiling_face: | 10:33 |
| daveshah | The PnR part shouldn't be that memory intensive | 10:37 |
| daveshah | nextpnr can do PnR for an 85k logic element ECP5 in ~200MB | 10:37 |
| daveshah | Admittedly the database build is quite memory intensive, but that's a one-off operation | 10:37 |
| duck2 | i thought that too, most memory intensive processes fill up my ram and freeze the gui but don't corrupt my /usr/bin on a reboot. this is interesting | 10:42 |
| daveshah | I suspect that's more bad luck that anything VPR specific | 10:43 |
| daveshah | Perhaps because it was doing disk operations at the same time as running out of RAM | 10:43 |
| duck2 | looks like it. i really shouldn't have run it twice i think. will fix debian and give it another shot | 10:51 |
| litghost | duck2: Ya, the current XML read method in VPR consumes quiet a bit of RAM. I typically measure ~7 GB. This can be reduced in the future, but is what we have right now | 13:32 |
| *** Bertl_zZ is now known as Bertl | 14:23 | |
| *** citypw has quit IRC | 14:25 | |
| *** citypw has joined #symbiflow | 14:25 | |
| sf-slack1 | <acomodi> SLICEM modes update: I have finally managed to get slicem carrychain to be packed. I'll clean up and open a PR with WIP as I still need to test that everything else works fine and is not affected by the changes | 15:20 |
| *** OmniMancer has quit IRC | 15:22 | |
| litghost | acomodi: Awesome, what ended up changing? | 15:32 |
| sf-slack1 | <acomodi> The way in which `try_intra_lib_nets` computes `router_data`: every time there is a mode conflict between `lib_nets` I set as `illegal` the mode that cannot be selected by one of the childs of a pb (in our case the `SLICEM_MODES` pb_type) and try to route again, this time without considering the `illegal` mode (in our case the illegal mode was `DRAMs` as no {N}_LUT had to actually be set to DRAM mode, therefore, in | 15:37 |
| sf-slack1 | the end LUTs mode will be selected) | 15:37 |
| litghost | acomodi: Did you test packing a DRAM with a LUT with the new code? | 15:47 |
| litghost | acomodi: Otherwise sounds good | 15:47 |
| litghost | acomodi: One thing to start working on is a VPR only test case. As we are going to start upstreaming these changes, please add the smallest test case you can manage that tests this feature | 15:48 |
| sf-slack1 | <acomodi> litghost: Ok, so it will be necessary to use a small test architecture instead of a whole a7 right? | 15:50 |
| litghost | acomodi: Ya, that's the idea. Hopefully your mind is in this space enough to be able to create a reduced test case | 15:50 |
| litghost | acomodi: I'd put up the PR with the VPR changes when you can so we can start the review cycle, but I do want to start adding test cases for the VPR changes | 15:51 |
| sf-slack1 | <acomodi> litghost: Ok, sounds good, I'll start dealing with it then. Anyway, by packing DRAM with LUT you mean running one of the dram codes or having a SLICEM with both LUT and DRAMs? | 15:52 |
| litghost | acomodi: Later. You should be able to leverage the existing pack resource tests we have in xc7/tests/dram | 15:53 |
| litghost | acomodi: Just add a new test case | 15:53 |
| sf-slack1 | <acomodi> litghost: All right | 15:54 |
| *** GuzTech has quit IRC | 17:05 | |
| duck2 | hello from fresh install ^^ i plan to do the rest of the builds in a memory-limited container and hope only the container breaks on oom. then i should profile and see if there is a way to make it through except by downloading more ram or throwing swap at it. as for the XML arch generation and VPR, did anyone notice any obvious pain points of memory | 17:07 |
| duck2 | usage? so that i have somewhere to start | 17:07 |
| litghost | duck2: VPR currently loads the entire XML rr graph into memory, which is relatively wasteful: https://github.com/SymbiFlow/vtr-verilog-to-routing/blob/master%2Bwip/vpr/src/route/rr_graph_reader.cpp | 17:09 |
| tpb | Title: vtr-verilog-to-routing/rr_graph_reader.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com) | 17:09 |
| litghost | duck2: Switching to an incremental reader will likely save some memory | 17:09 |
| litghost | I believe to was significant | 17:09 |
| mithro | duck2: Plenty of room for memory optimization, but it is easier to optimize when you have a working solution - so correctness has been the priority | 18:36 |
| *** Bertl is now known as Bertl_oO | 21:03 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!