Announcement

Collapse
No announcement yet.

AMDGPU In Linux 4.9 To Bring Virtual Display Support, Improved GPU Reset

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

  • spacekookie
    replied
    I would love to see some progress being made on the whole DAL thing. I really wanna invest in a Freesync monitor but won't play extra for something I might not be able to use on Linux.
    So far all the info I found through articles was that it's 90k lines of code, that it's apparently quite horribly written and will have to be re-written from scratch? How is that going? Is there a roadmap? Or a tracker that is just the DAL efforts? Because for the last 5 months it's been "Oh yea, the DAL isn't ready yet..." and it's getting a little frustrating :/

    Leave a comment:


  • droste
    replied
    That would make his life easier with his new opengl implementation https://lists.freedesktop.org/archiv...st/126538.html

    Leave a comment:


  • pal666
    replied
    Originally posted by atomsymbol
    In my opinion, it would be better to move some of the code to GPU's "firmware" so that the Linux kernel (Windows, Mac kernel) does not need to deal with too many low-level details.
    what makes you think dealing with those details in firmware would be easier? someone still has to write it, and i doubt moving engineer from kernel to firmware will increase his productivity

    Leave a comment:


  • bridgman
    replied
    In general we keep our microcode very low level and don't particularly want to change that.

    The one exception is the "HW Scheduler" in the MEC block, but in that case we maintain a separate non-HWS path in the drivers so we can perform similar functions in driver code.

    Leave a comment:


  • R00KIE
    replied
    Originally posted by atomsymbol

    I can download and update firmware for my wireless printer. I would expect the GPU operating system to be able to do the same.
    Sure you can, the million dollar question is for how long it will be supported. Will it be six months after the product was released? One year? What will you do two years down the line, when the hardware is still perfectly capable of performing its function but some bug is uncovered that prevents you from benefiting from some functionality improvement or better support, or if a security vulnerability is discovered?

    Leave a comment:


  • duby229
    replied
    arrghhh!! stupid mod queue

    Leave a comment:


  • duby229
    replied
    clintar reply stuck in mod queue.

    There is clover but it isn't production ready and probably never will be. There is an experimental amdgpu branch with gcn1.0 support, you can search phoronix to find more info.

    Leave a comment:


  • duby229
    replied
    Originally posted by clintar View Post
    So with no GCN 1.0 / Southern Islands AMDGPU support, can you have any opencl with ubuntu 16.04 and up on these cards at all?
    Well, there is clover, but its definitely not ready for a production environment. It probably never will be. There is an experimental branch of amdgpu containing gcn1.0 support, you can search phoronix to find the relevant articles containing information about it.

    Leave a comment:


  • clintar
    replied
    So with no GCN 1.0 / Southern Islands AMDGPU support, can you have any opencl with ubuntu 16.04 and up on these cards at all?

    Leave a comment:


  • darkbasic
    replied
    Originally posted by atomsymbol

    In my opinion, it would be better to move some of the code to GPU's "firmware" so that the Linux kernel (Windows, Mac kernel) does not need to deal with too many low-level details.

    The amount of complexity in current GPUs is enough for them to contain a small operating system. It would be really cool to connect to the GPU OS via a wireless TCP/IP connection.
    No, please. *PLEASE* no. Unless firmware's source code gets released of course.


    Originally posted by R00KIE View Post

    I'd rather see minimal GPU (or anything else) firmware that takes care of only the absolute minimum functionality, such as preventing self destruction and basic sanity checks, and let drivers or something else along the stack deal with the rest.

    I believe we've seen enough bugs and security problems hardcoded in firmware that will never get updated or fixed, so we should know better and not ask for trouble further down the line.
    +1
    The more closed source *SHIT* removed, the better.

    Leave a comment:

Working...
X