Conversation
|
I am interested in this. Can/may I help in some way? |
That would be great. I will try to provide some more context that would be helpful. This is related to #2288. We currently build the wheels with Vitis, which is closed source and not available for Windows natively with compiler support for AIE AFAIK. Therefore, I have been slowly been working on untangling our CMake build infrastructure to remove the dependences on Vitis and use Peano (llvm-aie). Peano releases wheels nightly compiled for Windows. We could then build and release wheels for mlir-aie compiled natively for Windows. |
|
I noticed there is an upstream bug in the llvm Windows nightlies that hard-paths the Visual Code On the topic of Windows I also, some time ago, started a 'universal' Python script to build on Windows/Linux/WSL, consolidating several of our scripts into one cross-platform beast. It relies a little bit on some env var emission black-magic, but I nearly had it working. I'll evaluate the state of that this weekend and show you what I have, and you can tell me if you'd be interested in that. Edit: Having just pulled it up, it appears I was running into the same issues you mentioned. Namely, getting the two |
|
This took me all weekend and I am up past my bedtime, so no PR just yet. Not even for a few more days. It's a load of spaghetti and lots of kludges. Plus several helper scripts, some sloppy syntax, a manual-sized bring-up list, manual env var pathing, plus it needs some suspension work and shocks, and brakes, brake pads, lining, steering box, transmission, rear-end... But it appears to work. I realize this cli output block isn't all that illustrative, but the whole thing compiled and ran, end-to-end, on Windows. And I mean the whole thing, including the mlir-aie wheel. This is just me testing that the wheel actually works. I had no idea how close I really was a few months ago. Almost all of the problems are upstream with llvm-aie. Right now I'm leaning on a Windows Vitis install for some executables (OpenSSL what giving me trouble on my system, so I'm not compiling bootgen just yet), but I think that can be dealt with as I iterate. A pure Windows user will still need to supply their own I was originally going to use MSYS2 to run the makefiles because vcpkg nmake doesn't work, but that was giving me trouble. So they are now scripts that take a 'best guess' at how to compile the examples. That ended up being a good thing, because it allowed me to alias around some issues with incorrectly named libraries in llvm-aie and a really nasty bug with improperly built Windows elfs pulling in Linux dependencies requires stripping the The problem really wasn't that much on our end after all. The only thing that gave me trouble there was us using |
|
Firstly, thanks for all the hard work on this and demonstrated results!! I am very excited to have a path towards getting Windows native compilation.
It would be great to see if we can completely rely on open-source. Please let me know if there are any particular tools/resources I can help find or ensure are in open-source repos. |
I 100% agree that open-source should be the target. The Vitis reliance was just a time-saving convenience on my part so I didn't have to get (further) distracted fussing with my broken OpenSSL install. That is definitely the first thing I am going to fix. I also agree that the user should be using the compiled XRT source, but I didn't mention that I have to submit a PR to them in order to get it to build properly on Windows (the current I haven't even investigated yet what is going on with Now that I know this works, I'm going to spend the rest of the week cleaning up my mess and consolidate it into ~6-7 files/file-edits. I'm hoping that I'll have something to give you guys by next Monday. By then I should have a better idea of the true requirements and a list of suggestions for ease of packaging. I'll also try to put together a list of things that need to be fixed in llvm-aie, so maybe somebody with more credibility than I on that project can get some movement there. That would save a few hundred lines of code. |
Heard.
This was from early days when the kernel driver wasn't included in Linux. At this point we can likely move on from that direction. And soon once XRT and xdna-driver are upstream in Linux we can definitely.
Please let us know on this side too. Thanks for the work and looking forward to your PR on ~Monday |
|
I'm still working on this. It's just taking me a little bit more time than I had hoped to get it in a form that I consider both presentable and appropriate. The last 10% are always takes 90% of the time. The extent of the aggravation that the XRT install is going to cause the average -- or even better-than-average -- user is becoming even more clear as I write the instructions. On the bright side, the XRT project accepted my PR to get Windows builds working (for the most part) without the user needing to tinker with the source. I also resolved the pyxrt.pyd issue (that was an error on my end), and bootgen works fine (just one little tweak added as a nice-to-have), so there is no need for Vitis to build Windows wheels. However, the install is so complicated that I am going to have to spin up a fresh Windows just to make sure my instructions are complete, correct, clear, and followable. This isn't a problem with mlir-aie; it's just about getting XRT, Windows, VS, vcpkg, and PowerShell all working together nicely. I also have not yet fully validated that any of the changes I've made won't negatively impact POSIX users (although I was careful about that, so I don't anticipate problems). Linux is still going to default to using xchesscc everywhere it did before unless the user passes a flag to switch to force Peano. Overall, this is going to take me several more days, but there is no point is issuing a PR if nobody can make the thing work due to lack of instructions. |
|
Also, because I'm sure you are curious, the 'magic bullet' on Windows is to make sure |
No description provided.