Vik

I suppose some instances cut others off as well (I see only 6 total) so you have a fair point

And despite that, if was still newsworthy enough to be posted like 6 times in total 😅

I’ve been using the nightly releases for element X android for some time.

Sliding sync means messages are fetched quite a bit quicker, though it’s not yet feature complete relative to regular element android.

I’ve not yet tested element call on EXA, however, but it’s worked very nicely for me via web.

deleted by creator

Worth noting from the original article

Fedora is working around this in their latest packages by beginning to probe SimpleDRM immediately. Fedora / Red Hat though isn’t the only ones using Plymouth but is largely in use by all major Linux distributions of the past decade. But in recent years the AMDGPU driver has only continued to grow much larger in supporting newer GPUs and tacking on additional features and optimizations.

For basic parts / geometry, I think FreeCAD will serve you decently well. There are several nice tutorial series for FC on YouTube and adjacent platforms.

Def stick to dedicated CAD software for your use case, though. You can technically use something like Inkscape for technical illustrations but I think it would become a bit of a battle. If all you need is 2D design, maybe LibreCAD or QCAD will work?

I’ve not come across anything with that sort of free form, intuitive (for vector artists) control paradigm.

For functional modelling, I’d recommend a parametric app (like FreeCAD, as you’ve mentioned), though it can be a bit trickier to use. You may feel as if the workflow has some gaps compared to something like SolidWorks.

I’m not sure either understand how this statement relates to the article, it seems that zen5 performs favorably on Ubuntu compared to Windows in the majority of Michaels tests?

Does the presence of legacy hw support verifiably hurt performance for newer products?

This is true for me on NV21 + VermeerX3D. Same goes for other d3d12 titles, like halo infinte, apex legends dx12. I haven’t tested this extensively but it happens to be the case for a few setups.

I suppose if zluda interpreting native cuda code on other IHV platforms is “illegal”, whereas HIP can legally be used to translate CUDA to ROCm at runtime, I would equate WINE to HIP, as it translates Windows API calls to POSIX for linux and Unix systems.

I’m not sure Microsoft have a leg to stand on with a move like this given their legal troubles in the past around becoming a monopoly. Maybe they don’t see as much threat given the low share of linux and unix (including mac) desktops

There’s still a bit of friction around actually leveraging WINE on non-Windows systems, with Proton being a relatively recent outlier as it offers you a mostly plug and play experience via steam, lutris and others.

For nvidia, zluda can allow other IHVs with significantly cheaper DC solutions to undercut them with no friction whatsoever.

…or it was found to violate CUDA’s EULA and taken down as a precaution https://www.tomshardware.com/pc-components/gpus/nvidia-bans-using-translation-layers-for-cuda-software-to-run-on-other-chips-new-restriction-apparently-targets-zluda-and-some-chinese-gpu-makers

I’m aware of this and alluded to it in my other reply

I’m familiar with the timeline of events, it’s just that this post title is intentionally obscure. As for why, it could be due to a recent enforcement by NVIDIA of a specific part in their EULA

Nvidia has banned running CUDA-based software on other hardware platforms using translation layers in its licensing terms listed online since 2021, but the warning previously wasn’t included in the documentation placed on a host system during the installation process. This language has been added to the EULA that’s included when installing CUDA 11.6 and newer versions.

The restriction appears to be designed to prevent initiatives like ZLUDA, which both Intel and AMD have recently participated, and, perhaps more critically, some Chinese GPU makers from utilizing CUDA code with translation layers.

My guess is that either AMD were directly contacted or preemptively closed off a legal loophole.

E: I was wondering where I recognised this username from

Did you editorialise this title and description? How did AMD take down an Intel specific project? Are you intentionally missing out the amd-backed development for zluda on amd gfx? If Zluda can run unmodified CUDA code, where does ROCm factor in?

To be real I have had a similar experience with data loss and broken links on an install drive, requiring the reinstallation of impacted apps. Honesty it’s probably not a great idea for me to keep using that disk lol. Reason it comes to mind is that my Firefox install was impacted in exactly the same way as on your end. It was also caused by an interrupted update.

I hope you find that you have everything you need on the other side. People here might be able to help fill in the gaps if not.

Appreciate the context

will need to check it out. Thank you for the tip

Oh neat. Hope it works for your needs. Let us know how it goes.

Have been keeping an eye on https://fcast.org/ but haven’t gotten involved yet.

Since this is GCN based, you may be able to use the newer AMDGPU kernel driver? I’m not sure about that specific SKU, however. I remember that using AMDGPU on, for example, Hawaii (like the R9 290) was particularly finicky