The only PC desktop accelerator that could be considered early depth testing would be tile based 1996 PowerVR. ATI introduced HyperZ in 2000 Radeon DDR (R100), Nvidia followed in 2001 with GeForce 3 LMA. From what I remember Radeon compressed Z gains were surprisingly minimal, like 10-20% when turning it on/off, but Im sure it became crucial later on when real shaders (2.0) started being used.
The idea that we should ever allow companies to gate how we use hardware is a joke. The sustainability here is just wildly off the charts impressive. We as a species have blanket legal right to fix things we buy. Any legal monkeying that that from is us an affront to all of us, and if applicable whatever god or gods that made us.
There's no good reason to get emotionally attached to obsolete hardware unless you are running a museum or just doing something cool. AMD doesn't hack on a Radeon R100 for the same reason everyone else doesn't: it's obsolete. It makes more sense to get a modern bargain-bin $30 fanless graphics card than to make your R100 work in any modern computer.
I agree that this is more silly than practical or useful. It's just that old. It's ridiculous.
Reciprocally though 10 even 15 year old GPUs (half as old) are actually often pretty good and useful, for a lot of people. And they're what some people have. Many have multiple 100's of GB/s of memory bandwidth, which is pretty potent even today! That they can be so much better and that they do keep getting better is pretty amazing.
The biggest downside imo is power efficiency. A lot of these cards are on older hotter processes. They lack modern instructions and have to brute force various features. Some signficiant downclocking, undervolting can help a lot for this!
Consumer GPUs have really slowed in progress a lot, especially since 3xxx. With the pressure to upgrade diminishing significantly, I feel like there's an increasing need to have good long term support and care. I don't see anyone but open source as willing able or interested in putting in long term care for products in general. And the broader hope of open source: those willing able and eager to keep making sure the street can find its own use for things. That we can go as far as we might dream.
Not require, just recommends Pentium 60 minimum. Like Quake Tomb Raider loves pipelined FPU, 30 fps on Pentium 60 vs 15 fps on 486DX2@66 and 20 on DX4@100.
> The FDIV bug affects the 60 and 66 MHz Pentium P5 800 in stepping levels prior to D1, and the 75, 90, and 100 MHz Pentium P54C 600 in steppings prior to B5. The 120 MHz P54C and P54CQS CPUs are unaffected.
Iirc the only way of getting near 30fps on a socket 3 board is by bumping the bus to 50mhz, having fast cache and a 5x86 and enabling branch prediction and the fpu optimisations. And then wait for it to fault out. Never tried it with an Pentium overdrive though, maybe that will work but those do not like higher bus speeds. Might also be a nice difference in DX4s since the amd and cyrix parts have different fpu implementations to the intel ones.
Last week we had four train-truck collisions at Polish level crossings resulting in derailment and passenger death, and afaik 2 or 3 involved foreign truck drivers.
This is one of the the cases where “the language model won't necessarily respect IP law” is really relevant. Individual users may be able to get away with this because they're too scattershot to sue, and users in some jurisdictions may actually be fine regardless, but broadly, the patent licensing around things like H.264 is not something BMD can afford to ignore. AFAIK the biggest reason Google was pushing WebM in the first place was because they, a huge corporation, were balking at being under the thumb of the MPEG LA!
I appreciate that it can be confusing for users that patents can still apply to techniques where implementations exist that are both libre and gratis from a copyright perspective, but this has been an issue for Linux-adjacent software distribution for ages—like, see how Debian used to put certain stuff that was encumbered by patents in the US but not in other jurisdictions in special “non-US” repository sections, that sort of thing. It's not Black Magic's doing that the codec space is like this. I wish people wouldn't make so many mocking assumptions sometimes.
Linux Vivaldi builds use libffmpeg.so from chromium-ffmpeg, which includes decoders for most codecs used on the web (no h265/mpeg2 tho), and VA-API which will handle all hardware accelerated codecs on particular platform.
This looks similar to using Microsoft provided Media Foundation codecs. No idea why Black Magic doesnt do it like Linux Chromium browsers.
Do you have any information on how the actual patent licensing is set up for Vivaldi? I wasn't able to find much on it, though I see the note in https://wiki.archlinux.org/title/Vivaldi that it “automatically downloads” the relevant files, which is at least suggestive that they can't just redistribute the binaries normally. The other closest thing I was able to find was https://github.com/chromiumembedded/cef/issues/3559 which describes a specific proprietary_codecs option in CEF, which is not quite the same thing but ought in some sense to be related… the way they describe having to set ffmpeg_brand=Chrome normally for that to be available doesn't sound promising?
I would be moderately surprised if whatever arrangement is going on there allows full use of the codecs for video editing software and not just for consumer decode of Web resources.
That doesn't sound right to me at all. I'm pretty hazy on the specifics of VA-API, but I wasn't under the impression that the graphics hardware carries 100% of the decode implementation nor had codec licenses attached to it, and this Phoronix article from 2022 describing Fedora having to back off from having accidentally shipped H.264 via VA-API without appropriate licensing seems to be evidence in the direction I expected. https://www.phoronix.com/news/Fedora-Disable-Bad-VA-API
If there were definitely no legal encumbrances, surely they'd want to keep shipping the version with the proprietary codecs in, because that would make them a superior option for users who need those? AFAICT someone upstream thought that having the toggle to avoid patent issues was important, which if true nixes the idea that VA-API just gives you an automatic unencumbered route and you don't have to worry about it after that.
I'm not really sure what actual claim you're making regarding the relevance of “pro-patent views”, but I might interpret it as something like “Red Hat is more likely to play it safe, whereas less IBM-enculturated distributions are more likely to bet on interpretations that let the users take on the risk”. Which I think is probably true; for instance, https://www.reddit.com/r/linux/comments/xqn20n/comment/iqbmv... describes how other distributions chose differently and moved to re-enable the proprietary codecs by default. (Some of them seem to be based in friendlier jurisdictions, mind. I'm not completely sure where BMD is, and I'm not sure how much it matters given they want to sell worldwide, but their full corporate name resolves most strongly to Australia: https://opengovau.com/business/30098098287 and Australia doesn't seem to exclude software from patentability: https://www.ipaustralia.gov.au/patents/what-are-patents/what...)
Anyway, if that's what you meant, I don't think that distinction is nearly as applicable to the situation with Resolve. BMD isn't a producer of a Linux distribution containing a broad variety of stuff, where “users happen to do stuff with the open source software we provide that violates some patents” can maybe be waved off as not their responsibility. BMD is very obviously directly operating in the commercially-distributed professional video tooling market, so codec licensing will be something they have to deal with as a keystone part of their business. Adding something to their software to actively enable people to do professional-style encoding for those codecs without the patent licenses would be playing with fire.
reply