51–60 of 60 posts
Earlier quoted context omitted.
I mean you can release it with loads of parts untested and just _hope_ there aren’t bugs there, it’s definitely an option. It’s risk vs reward there.
few days ago there was thread here about Valve and 20 years FPU bug... https://news.ycombinator.com/item?id=46009962 WoW was released 21 years ago AFAIK
Earlier quoted context omitted.
> Surely many parts of the game won't likely have bits of code that interact with architecture in unique ways. I came across a performance-killing bug that made the game unplayable (less than 1fps on a Mac Studio). It happened in a couple of dungeons (I spotted 2). From my tests it was caused by a specific texture in the field of view at a certain distance. There was no problem on Intel Macs, AFAICT. My old MBP was t…
> From my tests it was caused by a specific texture in the field of view at a certain distance. Surely that's a GPU thing and not an CPU thing, yea? Or was something about the texture processing architecture-dependent?
The core issue is that something slipped through the cracks. I don’t blame them, it’s a huge game and testing takes quite a lot of time. But testing does matter.
I wish ARM wasn't so messy for Linux, with out of date device trees etc. All I want is something like a Macbook Air, but running Linux - long battery life, acceptable performance, an OS that respects me.
Does WoW still use Blizzard's in house anti-cheat engine (Warden)? Interesting how the emulated version did not trip this.
Earlier quoted context omitted.
The anti-cheat streams executable code into the client, and that code is mostly for detecting tampering with the game, injected modules, etc. Not sure they care about it running in an emulated environment. They do effectively allocate an executable memory region, copy the machine code that was streamed into it, and jump to it. I guess in this case the emulation is an actual vm, rather than "rewrite x86 instructions i…
Rosetta 2 rewrites x86 instructions into ARM, but it does this on the fly for generated instructions too. When you put x86 machine code into a buffer and then jump to execute it, Rosetta 2 dynamically translates those generated instructions into arm before executing them. At least that's what I gathered around the time it was released. It seems to hold up; JITed x86 applications work great under Rosetta 2.
Earlier quoted context omitted.
Linux had the chance to fight against what GNU called "TiVoisation" but Linus said TiVo did nothing wrong. So now we have a world full of devices running open software but which are locked down. And a Linux foundation run by corporates. To me it is clear this was indeed a huge problem. Linux might not have become as big as it is now if it had taken GPL3 on board but it would have made it a lot harder for manufacturer…
So they took gpl3, and manufactures all licensed windows. Does this help Linux or FOSS?
It should have, IMO. Because now we're stuck with all these locked devices. Even PCs are becoming more locked now. FOSS (at least on the OS level) can't really exist without open devices to run it on. Otherwise you're dependent on the gatekeepers of big tech and there's nothing 'free' about it anymore then.
The emulated version beats the native version some times. Either the emulator is very good or the ARM build isn't optimized too much.
I’m curious if WoW is using any newer x86 instruction sets like AVX. I’ve been testing some math benchmarks on ARM emulating x64, and saw very little performance improvement with the AVX2+FMA builds, compared to the SSE4.x level. (X64 v2 to v3.) It was unexpected. It’s the first Windows build with Prism and the first time they’ve introduced AVX(2) support, so I wonder simply if the performance isn’t there yet. I’ve f…
I'd expect more of a gain from enabling FMA, but that's assuming the program actually got built to use FMA -- it needs to either use it explicitly or have relaxations to allow the contraction. Oryon has 4 x 128-bit NEON pipes with 3c latency fadd and 4c latency fmul/fma, so it easily ends up latency bottlenecked unless there are plenty of independent calculations.
Earlier quoted context omitted.
So they took gpl3, and manufactures all licensed windows. Does this help Linux or FOSS?
No the Linux kernel didn't move to gpl3 for this reason. It should have, IMO. Because now we're stuck with all these locked devices. Even PCs are becoming more locked now. FOSS (at least on the OS level) can't really exist without open devices to run it on. Otherwise you're dependent on the gatekeepers of big tech and there's nothing 'free' about it anymore then.
Maybe, but even if they wanted to, it would be almost impossible. In Linux, the license of contributed code says "GPLv2", period. Not "GPLv2 or higher" like a lot of other projects do. If you are not the rights holder, you can't "re-license" a piece of GPLv2 code as GPLv3 as you could with for example a BSD license piece of code. Simply because the GPLV2 is too restrictive. So that would mean getting in touch with all current and past right holders / contributors (and maybe even people who inherited the rights of contributed code if the contributor passed away?) and get permission to re-license to GPLv3.