Announcement

Collapse
No announcement yet.

AMD Sends Out Patches For New AMDGPU DAL Display Driver, Adds 93k Lines Of Code

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

  • humbug
    replied
    Originally posted by schmidtbag View Post
    Seeing how unpopular both G-sync and Freesync are even on Windows, I wouldn't keep my hopes up. It seems to me more people prefer 120Hz+ monitors instead, since they effectively yield the same results while not being restricted by hardware.
    I'm sure Freesync will come some day, but I'm sure AMD sees it as a low priority for Linux (possibly lower than Crossfire, I'm not sure).
    Crossfire is something that will require game specific profiles. That would be very high maintenance on Linux at least until Vulkan games allow game devs to do it themselves. Even on windows Nvidia and AMD have problems keeping up with SLI and crossfire profiles as new games come out, and that's with significantly more manpower. On the other hand freesync is something that once implemented requires less upkeep.

    Leave a comment:


  • Septor
    replied
    Presumably this will eventually replace at least 15kLoC of existing code from amdgpu... Should be able to shrink it down some more.

    Leave a comment:


  • Nille_kungen
    replied
    It will take time to get this merged and i think the review will be harsh.
    It wouldn't surprise me if it needs a lot of rework to get merged.

    Leave a comment:


  • orome
    replied
    Originally posted by Min1123 View Post



    Sorry, I can't figure out how to turn a personal repo into an anongit repo to clone anonymously. I think I may just have to wait until it gets pulled by something I have access to.
    click on the summary tab and the clone links are at the bottom...

    Leave a comment:


  • kenjitamura
    replied
    Originally posted by boffo View Post
    It's over 8000* LoC!!!
    Fixed that for you.

    Leave a comment:


  • boffo
    replied
    It's over 9000 LoC!!!

    Leave a comment:


  • entropy
    replied
    Almost 100k LoC... Holy cow.
    Who is going to review that thoroughly?

    I can't imagine that Linus likes to add such large patch sets.

    Leave a comment:


  • Min1123
    replied
    Originally posted by hwentland View Post
    The patches are available at https://cgit.freedesktop.org/~agd5f/...xt-4.6-wip-dal for easier reading (and testing). These patches just hit the dri-devel mailing list but you can feel free to run this and let me know what you find.


    Sorry, I can't figure out how to turn a personal repo into an anongit repo to clone anonymously. I think I may just have to wait until it gets pulled by something I have access to.

    Leave a comment:


  • microcode
    replied
    Originally posted by jf33 View Post
    What you say is technically true, but with high refresh rate monitors you can achieve similar results as with adaptive sync (at least in theory). Think of what would happen if you had a monitor with an infinitely high refresh rate. Once the gpu is done with rendering a frame, it would show up immediately, with no delay. Then this rendered image would be refreshed many times (which the user doesn't recognise) until the next frame is done, which then would be displayed without a delay again. So the user's impression would be the very same as with Freesync.

    Of course this theory doesn't quite fit in practice, because the fastest refreshing displays are about 144 Hz. Also, high rate refreshing has the disadvantage that you need more bandwidth for the video memory and display cable - and as a consequence more electric power However, I can understand that some people prefer a display with high refresh rate which works with all gpu vendors and is additionally a bit cheaper than adaptive sync monitors. They at least have a kind of similar effect.

    Frame skips still look awful even at 120Hz or even higher. One of the two reasons for variable refresh rate monitors is to avoid full frame skips (i.e. a situation where you have been seeing 120 frames every second, and suddenly lose one and display the same frame for two refreshes). This looks awful on any monitor, including (albeit, somewhat less so,) ones operating at very high refresh rates.

    Another good reason is for compositing videos in the desktop. Let's say you have a 23.976Hz video, and the native refresh rate of your monitor is 60Hz. You will either blend frames, skip frames, mistime frames, or distort the audio; all of these things are either computationally expensive, or don't look good, or both.

    It would be infinitely simpler and better to just refresh at 23.976Hz while the video is the only motion, and refresh on a multiple of that rate (47.952Hz or 71.928Hz) when you want smoother motion elsewhere on the desktop (i.e. loading indicator).
    Last edited by microcode; 02-11-2016, 07:42 PM.

    Leave a comment:


  • hwentland
    replied
    The patches are available at https://cgit.freedesktop.org/~agd5f/...xt-4.6-wip-dal for easier reading (and testing). These patches just hit the dri-devel mailing list but you can feel free to run this and let me know what you find.

    Leave a comment:

Working...
X