Originally posted by schmidtbag
View Post
Announcement
Collapse
No announcement yet.
RADV Sees Experimental Fragment Shader Interlock - Important For Emulators, D3D12
Collapse
X
-
-
Originally posted by user1 View PostYes, you're right, I myself also had no clue what would come out of it. But I'd say the same logic could be applied in 1991 when Linus started developing the Linux kernel. By the same logic one could say that this is a wasted effort (even if Linus himself didn't expect it to become something serious) and that Linus should've waited for or contributed to the GNU Hurd kernel instead. As you can see, when something new looks pointless from first glance, it may drastically change in the future.
Now, compare to Dave Arlie, who in 2016 was already a renowned professional developer, and (as far as I'm aware) didn't create RADV as a hobby. I would be shocked if he didn't know amdvlk was being developed at the time. Considering his history and affiliation, I'd be a little surprised if AMD were to turn down contributions from him. So, it never really became understood to me why he made it.
Where RADV and Linux are comparable is the fact that RADV ended up being more popular for what I assume to be the same reason: it was politically easier to work with. RADV was much more open to 3rd party contributions, and it has served them well. Perhaps the licensing was why he created RADV.
Anyway, of course anything seemingly pointless can drastically change the future, but think of how much more different the future would have been if a different GPU got its first Vulkan driver instead. If amdvlk got patches from Valve, Red Hat, and people like Triang3l, it might have come out better than RADV is today, since it'd have been a collaborative effort rather than a competitive one, all while another GPU would have Vulkan support, further enhancing the Linux experience across a wider range of devices. I do acknowledge that is a very big "if", though.
So here's the thing (and I'm not trying to be antagonistic here): had amdvlk turned out to be better than RADV, what would you say about all this? That outcome was well within the realm of possibility (no offense to Arlie).Last edited by schmidtbag; 04 April 2023, 03:51 PM.
Comment
-
Originally posted by schmidtbag View PostAnyway, of course anything seemingly pointless can drastically change the future, but think of how much more different the future would have been if a different GPU got its first Vulkan driver instead. If amdvlk got patches from Valve, Red Hat, and people like Triang3l, it might have come out better than RADV is today, since it'd have been a collaborative effort rather than a competitive one, all while another GPU would have Vulkan support, further enhancing the Linux experience across a wider range of devices. I do acknowledge that is a very big "if", though.
So here's the thing (and I'm not trying to be antagonistic here): had amdvlk turned out to be better than RADV, what would you say about all this? That outcome was well within the realm of possibility (no offense to Arlie).
First, there would've been no ACO compiler and AMD is known to be highly committed to LLVM which especially on AMDVLK is painfully slow to compile shaders. (this is a fundamental issue with LLVM and one of the reasons for creating ACO).
Second, let's not forget that AMDVLK was originally proprietary software only, which means open sourcing it has some caveats. And the main caveat is that it's still mostly developed behind closed doors (probably because AMD still releases both the proprietary variant and open source variant of AMDVLK and the proprietary variant is much more widely used on WIndows) hence the reason it's much less open to 3rd party contributions (you said it yourself in your previous paragraph). If licensing issues don't stand in the way, the only one who can theoretically change AMDVLK's development model to more resemble Mesa's is only AMD itself (this is also highly questionable, again, because of the proprietary variant that shares the same codebase). Not Valve, not Red Hat and not Triang3l are able to change anything about AMDVLK's development model, hence the much more limited 3rd party contribution opportunities. David Airlie himself mentioned that the big difference between AMDVLK and radv is that the former is "open - released" (open source code snapshots are thrown over the fence as seen in AMDVLK github page), while the latter is "open - developed".Last edited by user1; 04 April 2023, 04:39 PM.
Comment
-
Originally posted by shmerl View Post
More likely it could happen the other way - Russia will block access to something like Github or Gitlab because they aren't under their censorship (shooting themselves in the foot with that is expected, considering everything else Putin is doing). Many developers are leaving Russia while they can.
- Likes 2
Comment
-
Originally posted by RejectModernity View Post
Nah, Russia bans only Soros-funded brainwashing media.Last edited by shmerl; 04 April 2023, 08:15 PM.
- Likes 3
Comment
-
Originally posted by nuetzel View Post
That's sadly my understanding, too.
Greetings,
Dieter
Comment
-
Originally posted by shmerl View Post
They ban anything that's not Putler approved. Not yet on China level, but getting there, including asking China to help with censorship. Putin likes stone age, that's what he'll get technology wise.
- Likes 1
Comment
-
Originally posted by RejectModernity View Post
Stone age doesn't produce supersonic rockets.Last edited by shmerl; 04 April 2023, 10:47 PM.
- Likes 2
Comment
-
Originally posted by Quackdoc View Postit's sad, but my next gpu certainly won't be AMD. when I look at the features that even skylake igpus have that AMD doesn't... I don't know what features will be missing that Nvidia will support.
- Likes 1
Comment
-
Originally posted by agd5f View Post
Do you have any specific examples? Driver extension support is comparable, arguably AMD even supports more extensions: https://mesamatrix.net/
Only GFX9 and newer are supported for the moment. It would be a nice to have for old hardware, to be able to run wlroots'
vulkan: physical device does not support DRM format modifiers VK_EXT_image_drm_format_modifier is required for importing image from dma buf that contains modifiers. NV proprietary, Intel ANV and RA...
other notable GPUs that support this feature are nvidia's GTX 750ti, intel skylake's igpu etc
- Likes 2
Comment
Comment