i915-sriov-dkms VS solvespace

The i915 driver doesn't have SR-IOV mainlined just yet, so you need to build a dkms module to get it going.

Then I tried the SR-IOV approach, installed the latest proxmox kernel which had this module already patched in and followed the instructions on the page but lspci | grep VGA reports 00:02.0 VGA compatible controller: Intel Corporation Alder Lake-UP3 GT1 [UHD Graphics] (rev 0c) as before. This is the output of dmesg | grep i915:

For specifics: Up until last month, for gpu passthrough in Proxmox you have to use this random driver : https://github.com/strongtz/i915-sriov-dkms/tree/master With new Proxmox 8, it should have worked, but I still had to install this driver to even begin working on passthrough. Now I passed it to a UbuntuVM. Now Ubuntu by default doesn't support Alder lake iGPU completely. I installed kernel 6 somthing and the previous mentioned github driver. Now guess what, Plex doesn't support this GPU. This is the thread where I finally stopped. https://forums.plex.tv/t/movie-corruption-when-plex-decodes-4k-hdr/834529/45

There’s actually 2, theres the intel lts one, which i guess they did do something it just never amounted to anything, explained here:

https://github.com/intel/linux-intel-lts/issues/33

The ongoing development:

https://github.com/strongtz/i915-sriov-dkms

DKMS module from /u/strongtz github

SR-IOV does allow sharing the iGPU between a host and a guest but mainline linux doesn't support it yet. Intel is planning to mainline it later this year though and there's this dkms module if you know what you're doing and wanna try it.

dnf install -y @development-tools git dkms git clone https://github.com/strongtz/i915-sriov-dkms

Hello, everyone! I've been trying to pass through my dedicated graphics card on my optimus XPS 15 9510 for... quite a while. I was advised by [this blog post](https://lantian.pub/en/article/modify-computer/laptop-intel-nvidia-optimus-passthrough.lantian) that I need to pass through both my integrated graphics card and the dedicated graphics card in order to use the dedicated graphics card on the host, by my 11th Gen Intel i7-11800H doesn't support GVT-g, only SR-IOV. So, I installed [this kernel module](https://github.com/strongtz/i915-sriov-dkms) which allowed me to seemingly successfully create a VF and pass it through alongside my dedicated graphics card.

Can second this!

However, I would recommend https://solvespace.com! It hits a sweet spot between features vs complexity/learning effort.

We use rebase on solvespace, along with sensible squashing so most commits along master are pretty self contained. You can see the clean history here:

https://github.com/solvespace/solvespace/commits/master/

I changed a behavior to the "more standard" one because it felt obviously right. This was a 3 line change. But the was enough backlash right there in the pull request. So I spent a couple hours remembering how to add a configuration option to keep the old way for those guys:

https://github.com/solvespace/solvespace/pull/1425

> If you like Linkage, you might also like Solvespace.

No, I mean Brent Curry's Linkage[1] bicycle design software, not David Rector's Linkage Mechanism Designer and Simulator[2].

You should read Wikipedia article.[0]

N.B. About SolveSpace, as I'm its experienced user[youtube,patreon], I may say next: yes, it could be used for bike mockup, as any other CAD, but it still has a lot of limitations and even does not export correct STEP files yet[3], and in FreeCAD such STEP could fixed only partially.[video]

So, for serious 3D CAD work I highly recommend use FreeCAD (and LibreCAD for 2D CAD work) instead of SolveSpace, and use SolveSpace only as a helper tool like a calc or as a notepad for noting ideas.

About Linkage Mechanism Designer and Simulator, it is only useful for planar (2D) kinematics analyze, and if You are looking an alternative for it take a look on Pyslvs[4], that is in part based on SolveSpace's solver.

[0] https://en.wikipedia.org/wiki/rattleCAD#History

[1] https://bikechecker.com/

[2] https://blog.rectorsquid.com/linkage-mechanism-designer-and-...

[3] https://github.com/solvespace/solvespace/issues/206

[4] https://github.com/KmolYuan/Pyslvs-UI

[video] https://www.youtube.com/watch?v=F3LJMeqUDrU

[youtube] https://www.youtube.com/@appsoft

[patreon] https://patreon.com/app4soft

C++ this file covers all the math for working with NURBS curves and surfaces:

https://github.com/solvespace/solvespace/blob/master/src/srf...

There is a lot more in other files - triangulation, booleans, creation - but the core math functions are there in very readable form.

>> Maybe somebody has statistical survey of how much of the existing deployed CPU core count is typically used?

My guess is very few cores are used on average. I did some testing with Solvespace to see which build options contributed most to performance:

https://github.com/solvespace/solvespace/issues/972

Obviously using OpenMP for multi-core was the big win. But what's not shown is that in typical usage (not the test I ran) if you're dragging some geometry around it will use all cores (in my case 4 cores / 8 threads) at about 50 percent utilization. That percentage probably drops as more cores are thrown at it due to Amdahl's Law. In other words, throwing double the cores at it will give a good boost to a lot of code that is already taking less than half the time (wall clock time, not CPU time).

We added OpenMP to a number of functions for significant performance gains. And in fact, any remining single-thread operation that gets the parallel treatment is likely to have a significant impact on overall performance since that is where most of the time is spent now. At this point we're more focused on features and bugs.

Algorithmic improvements are possible and I'd like to do those in the future, but they are much harder to do than sprinkling some #pragmas around critical loops. That will improve the scalability though, where multithreading really did not.