Quoting: ShmerlI don't think they can prevent anyone from implementing tensor flow in hardware? They didn't invent it.

Tensor Flow is an IA framework from google. And you don't write an accelerator for one toolkit only.

But yes, everyone is free to implement a convolution engine and other bits to accelerate inference and/or training. Now the main issue is, with HW accelerated inference, you tend to need to fine tune the network for each accelerator architecture. So it is unlikely you will have s one size fit it all network you can deploy everywhere directly.

View this comment - View article - View full comments

Quoting: damarrinDoes RT run well on older GPUs? If it's just a tick on the box it's a pretty useless thing to get hung up on.

Nvidia used to allow RT to run on older GPUs, it did not run well (which is very predictable, lacking the hw acceleration needed to make it run decently) so they stopped. In fact, I am not 100% sure they stopped, maybe the enabling library is still out there and just no one cares anymore.
DLSS obviously no, since the lack of HW here is more critical: a network tends to be fine tuned for an architecture, here Nvidia's tensor cores, so redoing the tuning to make it run on CUDA cores, only to see that it reduces perfs would be like throwing money out of the windows and - bad PR since people would try it and say that it sucks -.

View this comment - View article - View full comments

Quoting: x_wingYou can still create an Open standard in order to implement it, it's not about of what your competence can do with their current hw but how you allow to evolve the industry with your technology. Nvidia strategy is simply anti-competitive, they don't want to be the best they just want to keep you tied to their brand.

The saddest part is they have been doing time after time the same stupid proprietary strategy that always end up in failure. Lets hope that once again they fail (and looking on how they have been pushing more titles and this support on Proton, they are definitely in fear).

CUDA did/does work, physx for a long time too. When you invest so much R&D in something cutting edge, you will try to monetize it to death, and if a method worked before, you will try again.

Now, they did open source the APIs as far as I can tell, so everyone should be able to implement a source compatible solution. I agree they could have made some standard APIs from the start though, the best would be to make it a Vulkan extension.

View this comment - View article - View full comments

Quoting: Guest

Quoting: 3zekiel

Quoting: Guesti would be more excited if nvidia open sourced it. along with their drivers. rather than keeping everything behind proprietary, closed up source. especially considering they are not bothering adding support to older gpu's. which many of those older gpu's still offer amazing performance. like the 1080 ti., two generations old.

Supporting on pre RTX is not possible. DLSS heavily uses tensor cores, which are only present on RTX2000+ GPUs. The reasons why fidelity FX can work on older GPUs is because it is a good old upscale filter. It is NOT an equivalent of DLSS, even though they market it as such ... (We will see hands-on results, but I feel disappointment coming - Look also at the videos they gave during the presentation, you will see the blur and jaggies on the ones which are moving coming from "dumb" upscales). Upscale works well for static scenes, but as soon as you had movement, there is only so much you can do - and it will look bad -... Comparatively, Nvidia's solution uses a neural network to infer lost information/pixels, thus reconstructing much more precisely the image and movements, with little to no blur and jaggies.

Quoting: Guestits going to be interesting to see when AMD's alternative lands on linux. at least on windows their version will be cross compatible. their own demo was done on a 1060. software lockin's are extremely unethical.

Even if Nvidia wanted to port it over, they can not. AMD lacks the HW support for the feature. It is not a sw lock-in. It is just that they have an exclusive HW feature.
CUDA is a sw lock in on the other hand, since it theoretically could run on other GPU albeit it would likely then lose the advantage of being slimmer than openCL).

For DLSS, they could emulate it on older/amd GPUs, but it would most likely reduce performance instead of enhancing it (convolution and other inference methods are very heavy with no dedicated hw or customized ISA, and it would occupy normal cores for naught), which would make no sense.

there's no reason to keep it lock and key when they are specifically going out of their way to limit it to not only nvidia, but only rtx cards. even though older generation of nvidia's own cards are still high performing. but they wanted to leverage tensor cores for it, which i can understand. its why i mentioned:

rather than keeping everything behind proprietary, closed up source. especially considering they are not bothering adding support to older gpu's.

it doesn't work on amd. it doesn't even work on pascal, maxwell, etc. what is nvidia afraid of? its only going to work on nvidia cards still. it will still be limited to rtx cards. why keep it closed source?

there's a lot of stuff in mesa that's only limited to amd, but its open source. there can exist a world where nvidia has nvidia only stuff, but still be open source. open source doesn't necessarily mean cross compatible or cross vendor. open source doesn't even prevent you from capitalizing from your software. you can still sell it if you want to. but standards, the software, can still be open.

this is why i'm excited for amd's version because overtime it should be coming to mesa. with the added bonus of it not limited to only amd or only to amd's navi architecture.

I did not follow it all, but Nvidia did open source the API. So anyone is free to implement a compatible solution now. What else do you want ?

For the Neural network + training sets, that is never going to get open sourced, at least not before years. This has far too high value value:
It is very complicated to obtain the training sets, and the training itself is done by virtuosos of neural network tweaking, and these guys don't come cheap. These network could in particular be exploited directly by Intel which has its XeSS incoming, and the cash + servers + hw to exploit it. So potentially they would be making Intel save a billion or two in R&D (that's what the tech jump cost Nvidia according to their presentation at that time)... I am sure you can understand that no CEO/CTO in their right mind would allow that. In fact, even AMD could just spin off some AI/tensor cores and use it. It is something that is often misunderstood in the silicon industry, the HW act as an enabler, but the value ends up being in SW. So for cutting edge feature, you can not expect them to be open sourced right away.

For the AMD feature, just use VKbasalt + CAS/fxaa/smaa... You will get essentially the same result. What I was trying to explain is that AMD is not doing something new, or that enables anything new. Thus they are open sourcing something with little to no value ... It is better than keeping closed source I guess, but you can not compare open sourcing a low value algo VS high value training set and NN. I know that AMD marketing made it look like some shiny new thing, but except for the integration straight into the engine (which is already done in some games), there really is nothing new. Upscale is upscale in the end, no magic.

For tensor cores themselves, I am pretty sure Nvidia could licence it (even open source it if it was their kick), since it is indeed not something very exclusive nowadays (everyone can implement convolution engines, and cores with IA/DSP oriented ISAs). I guess the secret sauce lies more in the interconnect and even more likely in the SW around it. Overall, tooling/specialized SW for HW is often very precious, and thus rarely shared. This is where most of the value in fact lies. That is standard in the silicon industry, and not specific to Nvidia at all. AMD just has nothing of the sort to protect, hence they go open source. If they came to be a market leader and/or had a concurrent network that was better than Nvidia's you can be 100% sure they would not open source it either. Once again, too much value there.

Now, on the other I think Nvidia is making a big mistake by keeping the core driver itself closed source. This has very low value, and only make people cringe. But well ... With the big announcement we have been teased since forever, one can always hope.

View this comment - View article - View full comments

Quoting: Guesti would be more excited if nvidia open sourced it. along with their drivers. rather than keeping everything behind proprietary, closed up source. especially considering they are not bothering adding support to older gpu's. which many of those older gpu's still offer amazing performance. like the 1080 ti., two generations old.

Supporting on pre RTX is not possible. DLSS heavily uses tensor cores, which are only present on RTX2000+ GPUs. The reasons why fidelity FX can work on older GPUs is because it is a good old upscale filter. It is NOT an equivalent of DLSS, even though they market it as such ... (We will see hands-on results, but I feel disappointment coming - Look also at the videos they gave during the presentation, you will see the blur and jaggies on the ones which are moving coming from "dumb" upscales). Upscale works well for static scenes, but as soon as you had movement, there is only so much you can do - and it will look bad -... Comparatively, Nvidia's solution uses a neural network to infer lost information/pixels, thus reconstructing much more precisely the image and movements, with little to no blur and jaggies.

Quoting: Guestits going to be interesting to see when AMD's alternative lands on linux. at least on windows their version will be cross compatible. their own demo was done on a 1060. software lockin's are extremely unethical.

Even if Nvidia wanted to port it over, they can not. AMD lacks the HW support for the feature. It is not a sw lock-in. It is just that they have an exclusive HW feature.
CUDA is a sw lock in on the other hand, since it theoretically could run on other GPU albeit it would likely then lose the advantage of being slimmer than openCL).

For DLSS, they could emulate it on older/amd GPUs, but it would most likely reduce performance instead of enhancing it (convolution and other inference methods are very heavy with no dedicated hw or customized ISA, and it would occupy normal cores for naught), which would make no sense.

View this comment - View article - View full comments

Quoting: CatKillerI find myself wondering how much these changes represent the other Liam and team being given some autonomy internally, and how much represents a culture change at Nvidia as a whole. It's getting results for us either way but, as we saw with Croteam, the former is fragile with respect to personnel changes.

Well, considering they also opened up virtio functions etc, I would tend to think there is some bigger opening at play.
Probably a kind of landslide strategy in the professional world, by capturing the heart of powerusers on every front, they can hope to also maximize their positive image in companies. And then, when you ask your ML person what GPU they want, they will answer Nvidia hopefully (and that is their "real" business).

View this comment - View article - View full comments

Btw, do we have any news on when 470 series is coming ? I am quite hyped now.

View this comment - View article - View full comments

Quoting: mphuZ

Quoting: gardotd426Your entire comparison is complete and utter nonsense.

Damn, what does vkd3d-proton have to do with it, if we're talking about drivers?

I do not care about VKD3D-Proton, like potential developers who want to want to release native games for Linux.

Joshua says the main obstacle is the driver and its support. I do not agree with his harsh statements.

VKD3D proton uses the same functionalities as native games basically, so if it has an issue, there is no reason a native game would not have the same issue. Very basically, say that you are developing Metro Exodus, an RTX game, and you want to port your game to Linux. Now, you look at driver support for RTX and you see a fair share of cards do not support it, or at least not on the driver that is usually targeted, what will you do ? Release it all the same ? Release a dumbed down version? (they kinda did that, release late, and did not release the extended edition with all the bells and whistles).
So what was pointed out here definitely is an issue, and it does seem like it caused a real problem for a real native game.
Plus if you read the whole paragraph, you will see that the mesa devs actually needed to reverse engineer the RTX instructions from AMD's proprietary driver ... Meaning AMD did not even document it for them, which adds insult to injury.

View this comment - View article - View full comments

Quoting: mylka

Quoting: 3zekiel

Quoting: mylkayou cant buy non TI
why the F do they make a TI then?

For 3070, good question.
For 3080 TI, according to LTT, it seems the supply of rtx 3090s is currently bound by the DDR6X supply

i meant because of miners. a hardware mining blocker would be more helpful

All new models (including newly taped out older models) will come with one. Now, whether it will truly be solid enough, that it the question.

View this comment - View article - View full comments

Quoting: kfpenguin

Quoting: gardotd426Um, no?

I have an RTX 3090 and my overall resolution is 5120x1440@165Hz (2x2560x1440@165Hz), with both connected over DisplayPort. Never once has it failed to boot. And I'm on 5.13-rc4 right now.

Well, this is an nvidia-recognized bug that is currently affecting many people across multiple distributions. And anyone it does affect is in for a rough day. The type of bug that leaves a sour impression on the company for those affected.

But you aren't having this issue, so I'm sorry I've wasted everyone's time.

The formulation from gardotd426 was a bit brutal maybe. But essentially it seems to be bound to a few screen models. The bug does exist, and that is sad of course. But we are far from a systematic, massive problem. It is indeed not linked to distro it seems, but really to some screens. And the Nvidia guy did not manage to reproduce it yet it seems. So it is probably not a massive bug either.
The point is more that it is not a bug that is anywhere as massive or systematic as you made it sound in your first message. Proof is, we seem to find more people without the issue than people with it on this very forum.
It also mitigate the idea that Nv is not doing QA since the problem seems to be a corner case, on a particular setup, on a few models amongst the many that exists. It is very hard to catch all those bugs, no matter how careful you are. Once again, considering they did not manage to reproduce it directly tend to show it is not trivial/easy to see.
Now, if it shows that the amount of people affected is not neglectable, then Nv defo should extend their QA to this, but it is hard to know in advance this kind of stuff.
Whatever you do, there will always be some bugs that pass through the testing, it is really unavoidable. Testing time is not infinite, and there will always be some corner cases creeping thru.

View this comment - View article - View full comments