Don't most of these games have custom code for rendering and lighting? How is this able to fit into that custom code automatically?
Or is the automation here very limited and you just have to reverse engineer these and find the right hookpoints, while this project just provides the code that you can hook into the games?
This is the reason it only works with directx 8 or 9: they have a pretty rigid render path with a clearly separated vertex and pixel shader pipeline.
For directx 8, you would for example specify light sources as part of special draw calls to the directx API, which makes it easier to translate them to a ray traced scene graph.
Shader tools like reshare also use heuristics to detect which of the framebuffers contains a depth map to add effects like SSAO to older games.
I imagine that rtx remix can to similar things to detect where in a shader the light coordinates are stored: after all most shaders look pretty similar when it comes to implementing a Phong shader etc.
For everything over it, nvidia would have to expose the byzantine monstrosity that is the drivers they wrote, that detect games and hotswap the buggy developer shadercode out for working nvidia shader code. And they could do that for older titles. It just wouldnt be neat.
It hooks into the DirectX fixed-function pipeline used back in the day (i.e. where you set up model/view/projection matrices and lightsource coordinates and surface materials and sent to OpenGL/Direct3D), so it knows what the programmer wanted to do, and from there it's "easy" to replace everything.
Excerpt: "Scene manager, which uses information coming through the D3D9 fixed function API to create a representation of the original scene, track game objects frame to frame, and set up the scene to be path traced."
This is such a good way to make these old games look really spectacular. 2d graphics of the era haven't aged particularly badly but old 3d games usually look pretty janky (imo!). Being able to literally see them in a new light is wonderful.
There is increasing newfound appreciation for that early 3d visual look though. You can see that in new games being clearly inspired by that look, for example Dusk (with "overwhelmingly positive" rating): https://store.steampowered.com/app/519860/DUSK/
Childhood trauma bonded acquired taste, like enjoying Surströmming or raw oysters. Same goes for people fondly remembering original Playstation glitchfest.
It's very interesting to see this new wave of games that are now evoking the childhood (or the "retro" feeling) of a new generation, in the same way pixelated games did for us not so long ago.
Much like fashion or music, the state of the art of a period consolidates into a style that becomes a design choice.
I also feel like cranking up the quality of scenes like this is just gonna make it more jarring when you talk to an NPC, the world freezes, and their cold, dead eyes stare into your soul as their mouth awkwardly wiggles around and corny voice acting is played at you.
I'm pretty sure that's the only example because it's made by Nvidia themselves as a showcase for this tech because they were the only ones with access to it until today.
It has not been available, it was just released, hence the news being submitted here. Before this the only way to use it was to just take the dll from Portal RTX and try to throw it at old games hoping it would work.
From the workflow shown in the video it might even make sense to build a low-res game now with DirectX 9 and "mod it up"? The texture upscaling and material inference as well as the direct modification capabilities look amazing!
For Morrowind it didn't just upgrade the rendering, it completely changed the aesthetic of the scene. Is that on purpose? At that point you can't call the results better, only different.
It seems you'd certainly be able to go in and just tweak the lighting without doing all the AI touchups, texture upscaling, and model swaps as they did in the video. Pretty wild stuff, either way.
It seems like the big change is that the light sources now actually emit light so the scene becomes a lot brighter. Maybe part of the process should be turning down global illumination? That might make dark corners even more dark however, and "hidden" clues that were supposed to be difficult to see may become outright invisible.
According to the user guide [0], it's as simple as dragging the provided DLL into the game folder.
I'm going to try this out with one of my old favorites today, I doubt it'll be quite this easy.
I believe the DLL alone only makes the game moddable. Thereafter, there's still a lot of work to do to swap out low resolution and poly-count assets for more detailed ones.
Yeah, but not live at runtime. It's still a pre-process that needs to be applied per game. Maybe just dropping the DLL into the game folder will upgrade the lighting automatically, in the rare cases these older games used real-time lighting. But real-time lighting, as far as I remember, was a pretty rare technique, opting instead to bake lighting into textures during asset compilation.
I loaded up HL2 with this, it's the only game I've tested so far that actually loads the DLL correctly. I can toogle the overlay menu and I've gotten one of the menu screens to look somewhat OK. After loading into Route Canal or Sandtraps, it's pitch black, aside from the weapon and the buggy. Spent like half an hour messing with the settings but I couldn't get it to work well.
NFS:U2 and GTA:SA do not start at all with the DLL present.
It is technically GPU agnostic, the injected renderer should run on any hardware that supports Vulkan raytracing. The design of the renderer certainly plays to the strengths of Nvidia's architectures though, so performance is quite bad on AMD cards.
performance is terrible on just about everything. even a 4090 doesn't get above 30 fps on rtx portal without dlss helping out at 4k. A 4090!
Honestly, this seems to be nvidia's way of making everything look slightly better while requiring massively stronger hardware. It feels like this was purposely done to disadvantage amd and intel
The PS5 runs most games at 4k 60. Granted, it's scaled on some games, but that really doesn't matter when it's being outputted to a TV sitting 10 feet or more away from the viewer.
I get why they did what they did, because most TVs now days are 4k, but if you know enough about the limits of human vision, it's pretty clear that 4k is a waste for console gaming. It makes much more sense on PC, but even there the biggest noticeable difference is reading text, not playing games.
It was only this latest generation of consoles that started giving a shit about framerates again because they basically hit diminishing returns on pumping more triangles into every mole of every NPC, and resolutions were good enough at 4k, so framerates were suddenly something important enough to care about.
But the PS4/Xbone/Switch and prior 3D consoles certainly treated 30fps (sometimes less) as a standard in most cases. There's a reason people want to get Bloodborne ported somewhere else, because currently the only way to play it (PS4) is locked at 30fps.
Remember when they came out with slightly stronger tessellation unit? The result was Nvidia paying developers to do this:
"Unnecessary geometric detail slows down all GPUs, of course, but it just so happens to have a much larger effect on DX11-capable AMD Radeons than it does on DX11-capable Nvidia GeForces. The Fermi architecture underlying all DX11-class GeForce GPUs dedicates more attention (and transistors) to achieving high geometry processing throughput than the competing Radeon GPU architectures."
I wonder if certain sponsor didnt suggest removing images to techreport. Sounds preposterous until one remembers Intel commissioned tomshardware story from 2001 https://www.tomshardware.com/reviews/hot-spot,365-4.html Turned out it was mostly a lie of omission and tomshardware published a retraction, but neither that retraction http://www.tomshardware.com/column/01q4/011029/index.html or its archive.org copy are available anymore. archive.org returns "Sorry. This URL has been excluded from the Wayback Machine." for that one single retraction link. Curiously original now confirmed to be wrong story is still there for everyone to read 22 years later, imagine that.
Perhaps a stupid question, but with all the recent advances in computer graphics, why do I still see polygons everywhere in computer games? Is it really that hard to round those corners?
I think we are optimizing the wrong thing. I think I'm not alone in wanting round objects more than perfectly ray-traced but polygonal objects.
Short answer? It depends, but “yes” is more generally going to be true than not.
The smoother the edges the more polygons there are. The more polygons there are the more work the processor has to do to render them. In a very basic sense.
Now, it is absolutely possible to round the corners without incurring heavy processing cost but then you’re probably not going to get good collision, instead you’ll get incredibly obvious clipping (when one seemingly solid object passes through another without triggering collision).
So game developers have to make a choice: look good in still photos or look good in gameplay? (Clipping is a jarring experience while playing). Bonus benefit: if you do it right the lower polygon count and less fancy graphic stuff means your game runs on a wider variety of hardware (smartphones, switch, Xbox/PlayStation, PC, specialty stuff).
And that’s all not even getting into the cost of paying an artist to round those corners. Do you balloon your art payroll and have dozens of artists working on a few hundred “perfect” assets or would you rather they work on thousands of assets that are styled consistently and damn the real world verisimilitude? Games are a passion for many but capitalism invokes a cost when making them.
Ok so instead of paying an artist to round those corners why not pay them to make round assets, then let the computer approximate them with polygons when and where appropriate?
Those require NURBS, Non-uniform rational basis spline, and (almost) no one does NURBS assets, because it is most of the time it is a unnecessary pain to use and manipulate them directly.
There have been attempts to go that route from both the hardware (eg Nvidia NV1, 1995) and software side (eg Quake 3 Area, 1999) and many attempts to render curved surfaces since. Generally triangles have remained dominant because they are easier to model, easier to manipulate and are rendered extremely optimally on hardware.
The approximation to polygons when rendering is a non trivial task. Individual curved patches can be easily approximated to triangles but once you connect those patches together you have to ensure that the tessellated triangle edges match between neighboring patches. For the most part it is just easier and more performant to model with triangles and brute-force render them. One day curved surfaces may be a better choice but currently triangles are dominant.
There really hasn't been great automatic mesh detail scaling techniques outside of tesselation shaders and they're not super easy for an artist to work with.
Unreal 5's Nanite system is a big step up but it's brand new and unique. Not many games are out yet and no other big engines have a competitor technology.
Pretty much Eunreal Engine 5 is going to completelyt fix this, but it's pretty new. Other engine's will pick up the same techniques. In 5ish years, this problem will be long gone.
- "Infinite" detail, like models that would be described by curves and others are mathematically absurdly expensive. And when you need your entire frame to be out in 16ms, there really isn't much space to keep both the advancements _and_ new very expensive math. It's done for some things like font rendering (see Slug), but it would be horrible for everything to be done that way.
- All of the tooling is still made around triangles and exporting meshes made out of triangles, because that's how everyone works.
- It's how everyone works because your GPU is good at one thing: triangles. It has dedicated units for that single goal: take triangles, and rasterize them to the screen. So, even if you made a brand new GPU with a Bézier Engine :tm: in there to make it efficient... well you still have to support all of the GPUs that only know how to do triangles, and you're back to doing math to transform these into triangles.
- Even if you do that, surprise, your screens don't do curves either, nor do your framebuffers! They're a bunch of pixels, so you just transferred your aliasing problems from "triangles along a grid don't look good" to "you need to match your curve to your grid", and if your detail becomes small enough, you now also have aliasing there.
- There's nothing that we have in this world that is round and we can't do a convincing job of with triangles. Sure, maybe something that has absurd scale, like a planet you can both see from outer space and up close: that'd be a lot of triangles to make it look smooth at all angles. It would be kind of performance wasting, but you can do it. And techniques like Nanite would actually even fix the problem a little bit.
First off: lol it doesn't. It's currently running at 0.4FPS on a Galaxy Note 10.
Secondly, raymarching usually involves something different than NURBS, which are Signed Distance Functions (which Inigo,the author, is quite fond of). These have no proper authoring tools to support them. The few games that I know of that uses them are Dreams and Claybook, and that's only as a descriptor of geometry. Dreams then transforms those SDF Into point clouds, then into triangles. And Dreams has basically been the research project of an employee they went through every possible failure before reaching something tolerable.
They are unlikely to ever be 'round'. Perhaps when the entire scene, and not just reflections is rendered by raytracers. That way one can represent mathematically correct curves. At that point we'll basically be throwing away all advancements in GPU tech.
Besides, it's utterly unnecessary when we can fake roundness by increasing the number of polygons and by clever illumination.
Is Nvidia making good on its promise to Open Source it's drivers a d stuff? They may not give us everything but this must be the third or fourth announcement from Nvidia on some open source they are providing I have seen in the past year or so.
Nvidia really hurt themselves with their long-standing closed source driver position. In many circles (like HN) they burned a lot of goodwill and mindshare because of their driver stance and effect it has had on Linux desktop users. It is an extremely tiny population (in terms of numbers) BUT those users (like the HN users) have an outsized impact due to the tendency for them to be in technical and decision making positions.
However, Nvidia (other than the driver) has a TON of open source work. In addition to contributions all over the place in the relevant open source ecosystems/projects they have 349 repos on Github[0]. They also have a variety of different organizations on Github (for some reason) like Triton Inference Server that has another 30 repos[1]. If you start wandering through these repos these aren't small efforts either - it's clear Nvidia puts a TON of resources and investment in open source.
At the risk of making this another Nvidia vs AMD thread, AMD (the open source desktop darling) by comparison has 39 repos on Github[2]. Their entire project for ML has a total of another 39 repos[3].
If it weren't for the proprietary closed-source desktop driver souring people it would be clear and obvious how much of a supporter of open source Nvidia is.
Your comment is exactly what I'm talking about "Nvidia has millions of lines of open source" "Yeah but their driver though - they hate open source and I hate them". It's not that simple.
I never said they hate open source or that I hate them. I just don't care how much open source they do if the the driver for only product that matters to me isn't open source. Their competitors' drivers are so it makes my decision easy.
I'm not sure why it would bother anyone else that I find their lack of open source graphic drivers problematic.
AMDGPU-pro is closed and there's a lot of features like raytracing that don't work on the open version at all. HDMI 2.1 doesn't work on either open or closed versions afaik (there is a long-running ticket complaining about it). And they also still have blobs too despite all that.
Nobody's drivers are totally open, if you use HDMI then you aren't allowed to be fully open because HDMI Forum won't let you, that's the brightline. You have to have some blobs to deal with them and similar ultimatums from other vendors.
If you are ok with something working, as long as it's open, and major features being broken doesn't bother you... might I suggest nouveau? AFAIK NVIDIA has even started addressing the reclocking issue on the newer gens.
I'm not entirely sure what point you're trying to make here. I didn't suggest the entire stack has to be open source, nor am I looking for a reason to use NVIDIA on Linux. I just think it would be great if NVIDIA open sourced whatever portions of their graphics driver to make the Mesa implementation competitive.
Counting github repos is too dependent on how projects or organized to be anywhere near a useful metric - especially as one of the major advantages of open source is integration to the corresponding open source projects, like the linux kernel and mesa, which aren't under AMD's github.
It is in NVidia's best interest to foster the ecosystem around their closed system after all, so long as it's all built upon a foundation they control (Their closed source driver, and proprietary interfaces like CUDA). Nobody thought '90s microsoft was an open source beacon, yet they "gave away" a large amount of code - mainly win32 examples and the like.
For someone who claims to be trying to avoid some "Which corporation that doesn't know you exist is the best" fight you have chosen a rather specific unbalanced comparison.
> Counting github repos is too dependent on how projects or organized to be anywhere near a useful metric
Agreed. Nvidia have a lot of abandoned Github repos where they dumped code and ran away. This lets them obey the letter of the law and release code without anybody being able to make use of it.
Not sure why or how this is a “fight” other than (as stated in my first comment) it’s one of the more ridiculous religious wars that seems to erupt on HN for reasons I’ll never understand.
I’m not going to do a full LoC analysis for an HN comment or analyze recent commits. It was a sixty second way to say “Nvidia has a lot of open source and the reductive HN take/experience from Linux desktop users solely based on their experience with drivers is a tiny piece of the picture”.
That said I would bet a dinner that a full analysis of Nvidia open source vs anyone else in the field would favor Nvidia handily.
> That said I would bet a dinner that a full analysis of Nvidia open source vs anyone else in the field would favor Nvidia handily.
It feels a bit weird to agree that any attempt at comparing is silly, and even agreeing on how to compare impossible to define, immediately followed by "But I bet I'd win anyway".
> Nvidia really hurt themselves with their long-standing closed source driver position
> In many circles (like HN) they burned a lot of goodwill and mindshare
I think Nvidia couldn’t really care less about ‘goodwill and mindshare’ (from HN users, of all places) and I’m sure it is really sad at how badly it is hurt by its closed-source driver position, all while rolling in its tens of billions of profit from its gaming and compute divisions.
Oh, and it still has ~90% of the discrete GPU market share.
It's too bad this is a no-go for online/competitive games, which tbh are a decent number of the DX9 games still worth playing. I'd love to use this on Team Fortress 2 but I don't want to risk it on my account with all my items without some kind of explicit approval, since this hooking/injection probably looks just like a hack to VAC.
It might be fine. If it's just messing with the way DXVK is being presented, it's not very different from the "hacking" people use to get DirectX games working on Linux. AFAIK, games aren't really picky about graphics API calls as long as everything behaves as-expected.
115 comments
[ 2.6 ms ] story [ 193 ms ] threadDon't most of these games have custom code for rendering and lighting? How is this able to fit into that custom code automatically?
Or is the automation here very limited and you just have to reverse engineer these and find the right hookpoints, while this project just provides the code that you can hook into the games?
For directx 8, you would for example specify light sources as part of special draw calls to the directx API, which makes it easier to translate them to a ray traced scene graph.
Shader tools like reshare also use heuristics to detect which of the framebuffers contains a depth map to add effects like SSAO to older games.
I imagine that rtx remix can to similar things to detect where in a shader the light coordinates are stored: after all most shaders look pretty similar when it comes to implementing a Phong shader etc.
Excerpt: "Scene manager, which uses information coming through the D3D9 fixed function API to create a representation of the original scene, track game objects frame to frame, and set up the scene to be path traced."
Much like fashion or music, the state of the art of a period consolidates into a style that becomes a design choice.
Anything interesting has been released with it? Any mod.
I haven't heard/seen anything.
https://www.youtube.com/watch?v=AZHBl5yWqJk
What a shame it can only be used on older DX 7 and 8 games.
i.e. it hasn't been available until today.
hehe
Someone at Nvidia of all places uploads YT video with gameplay footage at 1080 30fps with bad frame pacing and stuttering.
Cool technology. Dont know what game publishers are going to say about it, Rockstar sued for less.
The only authority here would be the original designers.
But the old rendering pipeline still exists I guess, and the new one look wicked cool.
https://www.remedygames.com/games/max-payne-remake/
[0] https://github.com/NVIDIAGameWorks/rtx-remix/wiki/runtime-us...
NFS:U2 and GTA:SA do not start at all with the DLL present.
Honestly, this seems to be nvidia's way of making everything look slightly better while requiring massively stronger hardware. It feels like this was purposely done to disadvantage amd and intel
Now now, lets not forget consoles exist.
I get why they did what they did, because most TVs now days are 4k, but if you know enough about the limits of human vision, it's pretty clear that 4k is a waste for console gaming. It makes much more sense on PC, but even there the biggest noticeable difference is reading text, not playing games.
But the PS4/Xbone/Switch and prior 3D consoles certainly treated 30fps (sometimes less) as a standard in most cases. There's a reason people want to get Bloodborne ported somewhere else, because currently the only way to play it (PS4) is locked at 30fps.
hmm, yeah, i just tried turning off DLSS on a 3080. that went very poorly.
> It feels like this was purposely done to disadvantage amd and intel
they're competitors? "have some free stuff, p.s. we only spent time optimizing it for things we sell" seems pretty ok to me.
The funny part is, that's exactly what Intel did with their C++ compiler.
https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler
Did NVIDIA cripple its CPU gaming physics library to spite Intel? https://arstechnica.com/gaming/2010/07/did-nvidia-cripple-it... https://www.realworldtech.com/physx87/3/
Ubisoft comments on Assassin’s Creed DX10.1 controversy https://techreport.com/news/14707/ubisoft-comments-on-assass...
AMD says Nvidia’s GameWorks “completely sabotaged” Witcher 3 performance https://arstechnica.com/gaming/2015/05/amd-says-nvidias-game...
AMD Dubs Nvidia’s GameWorks Tragic And Damaging, Fight Over The Developer Program Continues https://wccftech.com/fight-nvidias-gameworks-continues-amd-c...
"Unnecessary geometric detail slows down all GPUs, of course, but it just so happens to have a much larger effect on DX11-capable AMD Radeons than it does on DX11-capable Nvidia GeForces. The Fermi architecture underlying all DX11-class GeForce GPUs dedicates more attention (and transistors) to achieving high geometry processing throughput than the competing Radeon GPU architectures."
https://techreport.com/review/21404/crysis-2-tessellation-to...
conveniently techreport "lost" images, but we still have archive.org https://web.archive.org/web/20121002034311/http://techreport...
I wonder if certain sponsor didnt suggest removing images to techreport. Sounds preposterous until one remembers Intel commissioned tomshardware story from 2001 https://www.tomshardware.com/reviews/hot-spot,365-4.html Turned out it was mostly a lie of omission and tomshardware published a retraction, but neither that retraction http://www.tomshardware.com/column/01q4/011029/index.html or its archive.org copy are available anymore. archive.org returns "Sorry. This URL has been excluded from the Wayback Machine." for that one single retraction link. Curiously original now confirmed to be wrong story is still there for everyone to read 22 years later, imagine that.
Also https://arstechnica.com/gaming/2010/07/did-nvidia-cripple-it...
I think we are optimizing the wrong thing. I think I'm not alone in wanting round objects more than perfectly ray-traced but polygonal objects.
The following article provides an in-depth exploration of how polygon count affects performance.
https://www.linkedin.com/pulse/polycount-understanding-model...
The smoother the edges the more polygons there are. The more polygons there are the more work the processor has to do to render them. In a very basic sense.
Now, it is absolutely possible to round the corners without incurring heavy processing cost but then you’re probably not going to get good collision, instead you’ll get incredibly obvious clipping (when one seemingly solid object passes through another without triggering collision).
So game developers have to make a choice: look good in still photos or look good in gameplay? (Clipping is a jarring experience while playing). Bonus benefit: if you do it right the lower polygon count and less fancy graphic stuff means your game runs on a wider variety of hardware (smartphones, switch, Xbox/PlayStation, PC, specialty stuff).
And that’s all not even getting into the cost of paying an artist to round those corners. Do you balloon your art payroll and have dozens of artists working on a few hundred “perfect” assets or would you rather they work on thousands of assets that are styled consistently and damn the real world verisimilitude? Games are a passion for many but capitalism invokes a cost when making them.
Those require NURBS, Non-uniform rational basis spline, and (almost) no one does NURBS assets, because it is most of the time it is a unnecessary pain to use and manipulate them directly.
The approximation to polygons when rendering is a non trivial task. Individual curved patches can be easily approximated to triangles but once you connect those patches together you have to ensure that the tessellated triangle edges match between neighboring patches. For the most part it is just easier and more performant to model with triangles and brute-force render them. One day curved surfaces may be a better choice but currently triangles are dominant.
Unreal 5's Nanite system is a big step up but it's brand new and unique. Not many games are out yet and no other big engines have a competitor technology.
- "Infinite" detail, like models that would be described by curves and others are mathematically absurdly expensive. And when you need your entire frame to be out in 16ms, there really isn't much space to keep both the advancements _and_ new very expensive math. It's done for some things like font rendering (see Slug), but it would be horrible for everything to be done that way.
- All of the tooling is still made around triangles and exporting meshes made out of triangles, because that's how everyone works.
- It's how everyone works because your GPU is good at one thing: triangles. It has dedicated units for that single goal: take triangles, and rasterize them to the screen. So, even if you made a brand new GPU with a Bézier Engine :tm: in there to make it efficient... well you still have to support all of the GPUs that only know how to do triangles, and you're back to doing math to transform these into triangles.
- Even if you do that, surprise, your screens don't do curves either, nor do your framebuffers! They're a bunch of pixels, so you just transferred your aliasing problems from "triangles along a grid don't look good" to "you need to match your curve to your grid", and if your detail becomes small enough, you now also have aliasing there.
- There's nothing that we have in this world that is round and we can't do a convincing job of with triangles. Sure, maybe something that has absurd scale, like a planet you can both see from outer space and up close: that'd be a lot of triangles to make it look smooth at all angles. It would be kind of performance wasting, but you can do it. And techniques like Nanite would actually even fix the problem a little bit.
Secondly, raymarching usually involves something different than NURBS, which are Signed Distance Functions (which Inigo,the author, is quite fond of). These have no proper authoring tools to support them. The few games that I know of that uses them are Dreams and Claybook, and that's only as a descriptor of geometry. Dreams then transforms those SDF Into point clouds, then into triangles. And Dreams has basically been the research project of an employee they went through every possible failure before reaching something tolerable.
Yes.
They are unlikely to ever be 'round'. Perhaps when the entire scene, and not just reflections is rendered by raytracers. That way one can represent mathematically correct curves. At that point we'll basically be throwing away all advancements in GPU tech.
Besides, it's utterly unnecessary when we can fake roundness by increasing the number of polygons and by clever illumination.
However, Nvidia (other than the driver) has a TON of open source work. In addition to contributions all over the place in the relevant open source ecosystems/projects they have 349 repos on Github[0]. They also have a variety of different organizations on Github (for some reason) like Triton Inference Server that has another 30 repos[1]. If you start wandering through these repos these aren't small efforts either - it's clear Nvidia puts a TON of resources and investment in open source.
At the risk of making this another Nvidia vs AMD thread, AMD (the open source desktop darling) by comparison has 39 repos on Github[2]. Their entire project for ML has a total of another 39 repos[3].
If it weren't for the proprietary closed-source desktop driver souring people it would be clear and obvious how much of a supporter of open source Nvidia is.
[0] - https://github.com/NVIDIA
[1] - https://github.com/triton-inference-server
[2] - https://github.com/amd
[3] - https://github.com/RadeonOpenCompute
Your comment is exactly what I'm talking about "Nvidia has millions of lines of open source" "Yeah but their driver though - they hate open source and I hate them". It's not that simple.
I'm not sure why it would bother anyone else that I find their lack of open source graphic drivers problematic.
https://gitlab.freedesktop.org/drm/amd/-/issues/1417
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
Nobody's drivers are totally open, if you use HDMI then you aren't allowed to be fully open because HDMI Forum won't let you, that's the brightline. You have to have some blobs to deal with them and similar ultimatums from other vendors.
If you are ok with something working, as long as it's open, and major features being broken doesn't bother you... might I suggest nouveau? AFAIK NVIDIA has even started addressing the reclocking issue on the newer gens.
[0] https://github.com/NVIDIA/open-gpu-kernel-modules#user-conte...
And even then that count misses a large number of projects, like things under OpenGPU (https://github.com/GPUOpen-Drivers and https://github.com/GPUOpen-LibrariesAndSDKs) for example.
It is in NVidia's best interest to foster the ecosystem around their closed system after all, so long as it's all built upon a foundation they control (Their closed source driver, and proprietary interfaces like CUDA). Nobody thought '90s microsoft was an open source beacon, yet they "gave away" a large amount of code - mainly win32 examples and the like.
For someone who claims to be trying to avoid some "Which corporation that doesn't know you exist is the best" fight you have chosen a rather specific unbalanced comparison.
Agreed. Nvidia have a lot of abandoned Github repos where they dumped code and ran away. This lets them obey the letter of the law and release code without anybody being able to make use of it.
I’m not going to do a full LoC analysis for an HN comment or analyze recent commits. It was a sixty second way to say “Nvidia has a lot of open source and the reductive HN take/experience from Linux desktop users solely based on their experience with drivers is a tiny piece of the picture”.
That said I would bet a dinner that a full analysis of Nvidia open source vs anyone else in the field would favor Nvidia handily.
It feels a bit weird to agree that any attempt at comparing is silly, and even agreeing on how to compare impossible to define, immediately followed by "But I bet I'd win anyway".
Many companies would dream to hurt themselves that bad.
> In many circles (like HN) they burned a lot of goodwill and mindshare
I think Nvidia couldn’t really care less about ‘goodwill and mindshare’ (from HN users, of all places) and I’m sure it is really sad at how badly it is hurt by its closed-source driver position, all while rolling in its tens of billions of profit from its gaming and compute divisions.
Oh, and it still has ~90% of the discrete GPU market share.
But path-traced TF2 would own lol.