Announcement

Collapse
No announcement yet.

Radeon Crimson 16.3 Released With Vulkan, But No Sign Yet For Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dea1993
    replied
    Originally posted by zanny View Post

    Can they please not? Don't waste time on Catalyst. Ubuntu has already made the great decision to drop it, Arch already dropped it long ago, it is a PITA to use on Debian, etc. The entire community is behind AMD dropping Catalyst entirely and just focusing on Mesa, and they absolutely should do that.

    Any resources that would have gone into maintaining Catalyst on Linux should really be spent making Gallium match it in performance and features on Windows.
    on my notebook, opensource driver (radeon and amdgpu) has very bad 3d performance, and high temperature.
    so i can't use open source driver.
    i hope that in future catalyst/crimson will has better performance and better support.

    I've a carrizo APU

    Leave a comment:


  • Pecisk
    replied
    Originally posted by juno View Post
    Yes, it is - according to AMD (http://support.amd.com/en-us/kb-arti...tion_16.3.aspx)

    Not yet listed by Khronos (https://www.khronos.org/conformance/...rmant-products), but I'm sure it is when they claim that.
    I guessed if they have released with their official driver it has passed tests. I think it is just a matter of time for Khronos web admins to get it checked and confirmed and AMD added. Good.

    Leave a comment:


  • Pecisk
    replied
    Originally posted by agd5f View Post

    I'm not sure who you are paraphrasing, but I don't think AMD ever said that. The Vulkan driver is working fine on Linux. As we've said before, we have internal validation cycles related to releases and the Linux one did not line up with the Vulkan announcement. As to why it's closed source initially, the Vulkan driver is shared across OSes. With the catalyst transition to amdgpu, finalizing of the Vulkan API, and various other projects, we have not been focusing on the review of the code for public release in the short term. Some of the code for supporting other OSes cannot be open sourced for example and needs to be reviewed such that we can easily release the Linux code publicly and still keep things in sync with our internal trees relatively easily.
    Nice to get some much needed clarification regarding this. Thanks for hanging around and explaining situation.

    Leave a comment:


  • juno
    replied
    Yes, it is - according to AMD (http://support.amd.com/en-us/kb-arti...tion_16.3.aspx)
    Vulkan™ Support(1)
    [...] (1)Product is conformant with Vulkan 1.0 Specification.
    Not yet listed by Khronos (https://www.khronos.org/conformance/...rmant-products), but I'm sure it is when they claim that.

    Leave a comment:


  • bug77
    replied
    Ok, there's Vulkan support, but is it conformant Vulkan support? Last I checked, their driver wasn't passing conformance tests. And the release notes page says it supports Vulkan 1.0, while the current Vulkan version is 1.0.4 (they may be the same thing from an implementation pov, idk).

    Leave a comment:


  • Azpegath
    replied
    At work, I'm running Windows 8 on Apple MacPro via Bootcamp, when will we see new drivers? :'( We get one to two releases per year, why is it so slow? Aren't they the same drivers, only allowing for FirePro-cards?

    Leave a comment:


  • rakah
    replied
    Originally posted by agd5f View Post

    I'm not sure who you are paraphrasing, but I don't think AMD ever said that. The Vulkan driver is working fine on Linux. As we've said before, we have internal validation cycles related to releases and the Linux one did not line up with the Vulkan announcement. As to why it's closed source initially, the Vulkan driver is shared across OSes. With the catalyst transition to amdgpu, finalizing of the Vulkan API, and various other projects, we have not been focusing on the review of the code for public release in the short term. Some of the code for supporting other OSes cannot be open sourced for example and needs to be reviewed such that we can easily release the Linux code publicly and still keep things in sync with our internal trees relatively easily.
    Thanks for clearing that up. Completely understand where that is coming from.

    Leave a comment:


  • asdfblah
    replied
    Phoronix: Ubuntu Is Deprecating fglrx (Catalyst) In 16.04 LTS Ubuntu developers have deprecated the fglrx / Catalyst Linux display stack for Ubuntu 16.04 LTS.

    Leave a comment:


  • juno
    replied
    sorry, wrote bs here...
    Last edited by juno; 10 March 2016, 12:31 AM.

    Leave a comment:


  • agd5f
    replied
    Originally posted by rakah View Post
    I'm not going to quote the developer directly, but to paraphrase one of the AMDGPU developers on this forum pointed out that they expected Vulkan to be released later in the year and are not ready. They're in the middle of a transition from RadeonSI to AMDGPU and while they know how to implement Vulkan, the driver as a whole still needs quite a bit of work.

    I'm not sure why the Vulkan implementation needs to be closed source at first though. Intel already has a working open source Vulkan driver and because it's open source we can see the commit log and monitor progress. With AMD we don't know if the Vulkan driver exists and if it will show up in 3 months, 6 months, 12 months, etc.
    I'm not sure who you are paraphrasing, but I don't think AMD ever said that. The Vulkan driver is working fine on Linux. As we've said before, we have internal validation cycles related to releases and the Linux one did not line up with the Vulkan announcement. As to why it's closed source initially, the Vulkan driver is shared across OSes. With the catalyst transition to amdgpu, finalizing of the Vulkan API, and various other projects, we have not been focusing on the review of the code for public release in the short term. Some of the code for supporting other OSes cannot be open sourced for example and needs to be reviewed such that we can easily release the Linux code publicly and still keep things in sync with our internal trees relatively easily.

    Leave a comment:

Working...
X