Announcement

Collapse
No announcement yet.

AMDVLK 2021.Q4.1 Released As First Code Drop In Over A Month

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

  • smitty3268
    replied
    Originally posted by middy View Post
    isn't still good just to see how amd does (did) something and since it is open source, couldn't mesa project incorporate things from it they like? or at least use it to build something off of?
    It's mostly useful as hardware documentation. Particularly in cases where there are hardware bugs that need to be worked around that may not be obvious.

    Leave a comment:


  • middy
    replied
    Originally posted by JoshuaAshton View Post
    As is to be expected -- this is more of a source available driver than open source, as it isn't developed in the open at all.

    The code drops really suck and it's clear they don't want or care about external contributions or issues. Large code drops make bisecting impossible.
    isn't still good just to see how amd does (did) something and since it is open source, couldn't mesa project incorporate things from it they like? or at least use it to build something off of?

    Leave a comment:


  • smitty3268
    replied
    Originally posted by bridgman View Post
    As you know we only stabilized RT support in the closed source Linux driver recently
    6 months ago. And it was itself 6 months late.

    Not sure what the current situation is but will see if there is something I can say about it.
    Appreciated.

    By the way, I don't intend this to come off as overly rude, but honestly even if amdvlk raytracing support comes out tomorrow it's still a giant debacle for AMD in my mind. But better late than never, obviously.
    Last edited by smitty3268; 06 November 2021, 01:06 AM.

    Leave a comment:


  • bridgman
    replied
    Originally posted by smitty3268 View Post
    Bridgman's silence on the whole ray-tracing debacle speaks volumes, IMO. Usually he'd be telling us to just be patient and that it's coming as soon as they are able to scrape enough people together to implement it. This time, nothing.
    Geez, if I had known I was able to speak volumes by shutting up I would have done that years ago and made a lot of people happy

    As you know we only stabilized RT support in the closed source Linux driver recently, and there was some debate about how much of that to expose in the AMDVLK version, ie what parts if any needed to be rewritten before release.

    Not sure what the current situation is but will see if there is something I can say about it.
    Last edited by bridgman; 05 November 2021, 11:50 PM.

    Leave a comment:


  • QwertyChouskie
    replied
    Originally posted by smitty3268 View Post

    Bridgman's silence on the whole ray-tracing debacle speaks volumes, IMO. Usually he'd be telling us to just be patient and that it's coming as soon as they are able to scrape enough people together to implement it. This time, nothing.

    There is obviously no current plan to bring ray-tracing to amdvlk. Maybe not ever. At the very least, probably not until the rocm team decides they need it.

    The only question is if this is some kind of legal IP issue, a business decision to try and hide their RT code for trade-secret reasons, or if they just don't care about linux consumer support enough to spend the time making LLVM work properly with it. Or maybe all of the above.



    Oh, and the delay in code drops is almost certainly just down to the 1 person who's responsible for doing so going on vacation. I doubt they have anyone as a backup because it's not important enough to worry about.
    Honestly, I feel as though AMD is aware that everyone uses RADV and therefore puts little-to-no effort into AMDVLK, I mean why spend resources on a driver no one uses? Similar to the proprietary OpenGL driver, they keep it runnable but that's about it.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by jonix View Post
    I hope AMD is preparing ray-tracing on this official drive (that could explain the delays on this drops) otherwise there is going to be complete worthless to even try it on linux (yes it can run better on some games, mas if it's missing a huge feature like this why bother).
    Bridgman's silence on the whole ray-tracing debacle speaks volumes, IMO. Usually he'd be telling us to just be patient and that it's coming as soon as they are able to scrape enough people together to implement it. This time, nothing.

    There is obviously no current plan to bring ray-tracing to amdvlk. Maybe not ever. At the very least, probably not until the rocm team decides they need it.

    The only question is if this is some kind of legal IP issue, a business decision to try and hide their RT code for trade-secret reasons, or if they just don't care about linux consumer support enough to spend the time making LLVM work properly with it. Or maybe all of the above.



    Oh, and the delay in code drops is almost certainly just down to the 1 person who's responsible for doing so going on vacation. I doubt they have anyone as a backup because it's not important enough to worry about.
    Last edited by smitty3268; 05 November 2021, 05:26 PM.

    Leave a comment:


  • Seebi
    replied
    Originally posted by skeevy420 View Post

    The pull request for documentation that's open shows that much. Both the AUR and Manjaro have 4.19 and earlier kernels that some people might need to use but since Arch itself doesn't have those kernels in its repos they won't accept that pull request. From the outside, it just seems kind of silly of them not to accept it since it covers both active distributions and historical use cases.
    If someone commented on the PR to say that, maybe it would have already been merged

    Leave a comment:


  • perpetually high
    replied
    Sorry to go off-topic, but I just pulled the trigger on a 5800X for $299 at Microcenter (in-store pick up only):

    https://www.microcenter.com/category...all-processors

    You guys think that was a dumb impulse buy? Honestly I wanted some new tech. My 4c/4c i5-4670K is still flying, but it's still obviously going to be limited by some stuff. Let me know any thoughts, who cares if we're off-topic.

    I'm also thinking of pairing it with a MSI MPG B550 GAMING EDGE WIFI motherboard and some fast DDR4-3600 RAM.

    I know new tech is coming out, but it's going to be really pricey, likely early adopter issues, and again, paying the premium for DDR5/PCIE5/all the 5's. Let me know any thoughts. I can always sell this later and swap it for the new Zen processors also. Seems like a lot of winning.

    (edit: actually, going to go the ECC route, doing research now,
    edit2: going with the Gigabyte X570 AORUS Elite or X570S AORUS Master (new chipset with passive cooling), both supports ECC memory. Still deciding. I don't want to skimp on motherboard. Most important component (alongside PSU). Also look at some Crucial DDR4-2666 2x16GB for the ECC, but want to make sure it's Ryzen approved. I basically want no compatibility issues or memory errors... Man, I'm f'n excited!! This is gonna be a supercomputer.)
    Last edited by perpetually high; 05 November 2021, 02:25 PM.

    Leave a comment:


  • uid313
    replied
    I don't know why AMD do code drops instead of just having a public Git repository.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by JoshuaAshton View Post
    As is to be expected -- this is more of a source available driver than open source, as it isn't developed in the open at all.

    The code drops really suck and it's clear they don't want or care about external contributions or issues. Large code drops make bisecting impossible.
    The pull request for documentation that's open shows that much. Both the AUR and Manjaro have 4.19 and earlier kernels that some people might need to use but since Arch itself doesn't have those kernels in its repos they won't accept that pull request. From the outside, it just seems kind of silly of them not to accept it since it covers both active distributions and historical use cases.

    Leave a comment:

Working...
X