Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD Open Source Driver for Vulkan

github.com

Post reply on HN
Print view View original

161–170 of 181 posts

Re: AMD Open Source Driver for Vulkan

#161

Post by AsyncAwait »

opencl wrote: post #49
chrisper wrote: post #43

Earlier quoted context omitted.

Yet I can still not read CPU core temperatures of my ryzen 2600 on Linux (5.0-rc2). I am not sure what is going on but I think next time I'll go with Intel again. I read this may be related to some NDA by AMD but not sure.

Temperature monitoring for the first gen Ryzen chips has been in the kernel for about a year. The patch for second gen is there but narrowly missed the 5.0 release window, so it should land in the first release after 5.0. Intel is a bit faster about this but it's not like they have perfect day 1 kernel support either. i.e. temperature monitoring drivers for both first gen Ryzen and Coffee Lake landed in 4.15. At the…

Phoronix[1] is usually good at monitoring Linux hardware news.

1 - https://www.phoronix.com

Re: AMD Open Source Driver for Vulkan

#162

Post by SmellyGeekBoy »

kkarakk wrote: post #146
mj_olnir wrote: post #131

Earlier quoted context omitted.

Salary. Remember, Comcast also has software developers.

also there are a lot of developers globally with looser morals because of different cultural values. in my experience anyone from a -stan country will make whatever you want as long as you give them a decent salary and a visa

Aside from the racism - are you suggesting that working on closed source software is immoral!?

Re: AMD Open Source Driver for Vulkan

#163

Post by pjmlp »

geezerjay wrote: post #156
pjmlp wrote: post #140

Earlier quoted context omitted.

Khronos learned too late that the world has moved on and the community wanted to use something else other than C to program their GPGPUs. And they are doing it again with Vulkan. With a large majority looking for higher level wrappers instead of dealing directly with its APIs and increasing number of extensions.

> and the community wanted to use something else other than C to program their GPGPUs. This assertion makes no sense. The whole reason why these APIs are specified based on C is that once a C API is available its trivial to develop bindings in any conceivable language. You can't do that if you opt for a flavor of the month. Furthermore, GPGPU applications are performance-driven, and C is unbeatable in this domain. Th…

Tell that to Khronos that is now forced to support HLSL so that most studios bother to port their shaders.

NVidia that created a C++ binding to use Vulkan instead of plain C or AMD that had to create higher level bindings for the CAD industry to even bother to look into Vulkan.

This blind advocacy for straight C APIs will turn Vulkan into another OpenCL.

Re: AMD Open Source Driver for Vulkan

#164

Post by AsyncAwait »

gamblor956 wrote: post #69
majewsky wrote: post #66

Earlier quoted context omitted.

Please keep in mind though that this is not strictly a US site. To me (as an experienced, but non-native speaker) "what are you smoking" does not sound tongue-in-cheek at all.

Please keep in mind that this site is operated by a US VC, on US hardware and software, for a US audience residing in a few tech-centric US cities. US colloquialisms are perfectly appropriate on this site.

> Please keep in mind that this site is operated by a US VC, on US hardware and software, for a US audience residing in a few tech-centric US cities.

And funded by a Brit :-)

Honestly, that's not how today's world works. Sites like Reddit and HN obviously have an international audience. It is not meant for people from tech-centric U.S. cities, but rather to be a sort of sales channel for YC, which BTW has well-known companies founded by non-Americans on its list, such as Gitlab, Stripe etc.

> on US hardware and software

Really? Are you sure there's not a line of free/open-source in there that's written by a non American? It runs on Linux, I presume, who's creator is Finnish and there are many non-U.S. contributors. If there's NGINX somewhere in the pipeline, now you're got some Kazakhstani/Russian code in there. If any part was ever touched by a JetBrains IDE, more evil Russians were involved etc.

Please keep the nationalistic rhetoric down.

P.S. Did you know that paper is a Chinese technology? Yeah, the same Chinese who keep the U.S. down by hyping climate change! I hope you're not using it! \s

Re: AMD Open Source Driver for Vulkan

#165

Post by dagw »

geezerjay wrote: post #156
pjmlp wrote: post #140

Earlier quoted context omitted.

Khronos learned too late that the world has moved on and the community wanted to use something else other than C to program their GPGPUs. And they are doing it again with Vulkan. With a large majority looking for higher level wrappers instead of dealing directly with its APIs and increasing number of extensions.

> and the community wanted to use something else other than C to program their GPGPUs. This assertion makes no sense. The whole reason why these APIs are specified based on C is that once a C API is available its trivial to develop bindings in any conceivable language. You can't do that if you opt for a flavor of the month. Furthermore, GPGPU applications are performance-driven, and C is unbeatable in this domain. Th…

Furthermore, GPGPU applications are performance-driven, and C is unbeatable in this domain.

One of the reasons CUDA beat OpenCL was that enough people preferred C++ or Fortran to C and CUDA was happy to accommodate them while OpenCL wasn't.

Re: AMD Open Source Driver for Vulkan

#166

Post by bitwize »

geezerjay wrote: post #156
pjmlp wrote: post #140

Earlier quoted context omitted.

Khronos learned too late that the world has moved on and the community wanted to use something else other than C to program their GPGPUs. And they are doing it again with Vulkan. With a large majority looking for higher level wrappers instead of dealing directly with its APIs and increasing number of extensions.

> and the community wanted to use something else other than C to program their GPGPUs. This assertion makes no sense. The whole reason why these APIs are specified based on C is that once a C API is available its trivial to develop bindings in any conceivable language. You can't do that if you opt for a flavor of the month. Furthermore, GPGPU applications are performance-driven, and C is unbeatable in this domain. Th…

Yeah, except in actual high-performance computing, almost nobody uses C. It's all C++ and Fortran.

Re: AMD Open Source Driver for Vulkan

#167

Post by geezerjay »

dagw wrote: post #165
geezerjay wrote: post #156

Earlier quoted context omitted.

> and the community wanted to use something else other than C to program their GPGPUs. This assertion makes no sense. The whole reason why these APIs are specified based on C is that once a C API is available its trivial to develop bindings in any conceivable language. You can't do that if you opt for a flavor of the month. Furthermore, GPGPU applications are performance-driven, and C is unbeatable in this domain. Th…

Furthermore, GPGPU applications are performance-driven, and C is unbeatable in this domain. One of the reasons CUDA beat OpenCL was that enough people preferred C++ or Fortran to C and CUDA was happy to accommodate them while OpenCL wasn't.

> One of the reasons CUDA beat OpenCL was that enough people preferred C++ or Fortran to C and CUDA was happy to accommodate them while OpenCL wasn't.

Nonsense. We're talking about an API. C provides a bare-bones interface that doesn't impose any performance penalty, but just because the API is C nothing forces anyone to implement core functionality in the best tool they can find.

That's like complaining that an air conditioner doesn't cool the room as well as others just because it uses a type F electrical socket instead of a type C plug.

Re: AMD Open Source Driver for Vulkan

#168

Post by pjmlp »

geezerjay wrote: post #167
dagw wrote: post #165

Earlier quoted context omitted.

Furthermore, GPGPU applications are performance-driven, and C is unbeatable in this domain. One of the reasons CUDA beat OpenCL was that enough people preferred C++ or Fortran to C and CUDA was happy to accommodate them while OpenCL wasn't.

> One of the reasons CUDA beat OpenCL was that enough people preferred C++ or Fortran to C and CUDA was happy to accommodate them while OpenCL wasn't. Nonsense. We're talking about an API. C provides a bare-bones interface that doesn't impose any performance penalty, but just because the API is C nothing forces anyone to implement core functionality in the best tool they can find. That's like complaining that an air…

Proper APIs can be defined via IDLs, C is not needed at all.

Re: AMD Open Source Driver for Vulkan

#169

Post by Jnr »

tombert wrote: post #11

I can't speak for anyone else, but because AMD has been opening up their drivers, the laptop I purchased six months ago was AMD based. I haven't done any kind of elaborate benchmarks, but as someone who runs Linux full-time, I want to support companies that make my life a bit easier. That said, I have had some issue with my computer having some weird graphical glitches, and then crashing...I don't know if that's the…

I built new media box last year and thought I would try AMD Ryzen 2400G APU. Turns out it was a bad choice. Those graphics drivers are extremely unstable, it keeps crashing frequently, kernel bug reports have many reports from multiple people with info on how to reproduce them but those cases are still in status "NEW" almost 1 year later. And while their Windows benchmarks are decent, anything 3D related on Linux is a glitching disaster with poor performance.

My friend bought latest Intel NUC with AMD Vega graphics and he could not even get Linux to boot with that.

Meanwhile I have Nvidia GTX970 on my desktop PC and everything works fine, even G-Sync works. I have used Nvidia cards with Linux for 10 years now and I have not had any issues like I have with AMD now.

To me it seems like AMD dumping their drivers as open source is a call for help on maintaining them rather than being all friendly to community.

Re: AMD Open Source Driver for Vulkan

#170

Post by twtw »

geezerjay wrote: post #167
dagw wrote: post #165

Earlier quoted context omitted.

Furthermore, GPGPU applications are performance-driven, and C is unbeatable in this domain. One of the reasons CUDA beat OpenCL was that enough people preferred C++ or Fortran to C and CUDA was happy to accommodate them while OpenCL wasn't.

> One of the reasons CUDA beat OpenCL was that enough people preferred C++ or Fortran to C and CUDA was happy to accommodate them while OpenCL wasn't. Nonsense. We're talking about an API. C provides a bare-bones interface that doesn't impose any performance penalty, but just because the API is C nothing forces anyone to implement core functionality in the best tool they can find. That's like complaining that an air…

> We're talking about an API

I don't think we are. We are talking about languages.

In CUDA, compute kernels are written in a language called "CUDA C++." In OpenCL 1.2, compute kernels are written in a language called "OpenCL C." Somebody else probably could have (likely did) implement a compiler for their own version of C++ for OpenCL kernels, but the point 'pjmlp was making is that the standard platform did not enable C++ to be used for kernels until long after it was available in CUDA.

Post reply on HN