Hacker News Reader

Comment by can16358p | Hacker News Reader

Perhaps the easier option would be DRM software and anything that needs instructions that are only on a specific core type, stick to those cores.

It might reinvolve changes to DRM software but looking at the current compromises, looks like a better deal.

Of course Intel should have thought of this and didn't pick this route. I'd love to see the reasoning though.

View on HN

Intel is in general heavily constrained by whatever Microsoft chooses to do with Windows. It's not like Apple where they can introduce a new hw feature and then immediately use it in the operating system. For example the M1 Macs have the big little architecture integrated with Grand Central Dispatch. Many, many interesting Hardware features have died in the Intel world because the Windows team simply did not add good enough support for it and there was nothing Intel could do.

In this case detecting DRM software and scheduling it differently would require sophisticated support in the operating system, or even ideally DRM support implemented by the operating system. However these things are probably beyond Microsoft's capabilities in its current state.

I see your point.

Well it would be nice if Microsoft found a way to implement them and coordinate with Intel, with backwards compatibility of course (which is the key point of Windows).

Then this brings another question to my mind: if Intel is so contrained by Microsoft's decisions (which make sense) they should have been in a good relationship designing things that work nice together. Why did they design their CPU in a way that would break in Windows usage in the first place?

They must have much more R&D than saying "let's design this hybrid CPU and put a new instruction set on some cores and see if it works on Windows and DRM software else we disable those features" kind of approach.

I would rather say that if such a CPU breaks DRM software, this should be considered a feature.

Reply on news.ycombinator.com