Announcement

Collapse
No announcement yet.

KDE KWin's Move Away From GBM Surfaces

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

  • #81
    Originally posted by ranixon View Post
    That argument is for 20 years old hardware that were recently droped that can't run anything modern. 10 years old Hardware isn't that old, even Radeon R600 GPUs where moved to the NIR backend in sep, 2022 and they are GPUs from 2007.
    According to various forums and sites, a Vulkan driver for Terascale is possible: but will require an inordinate amount of dedication to create and is highly complex and...

    If you are looking a vulkan support covered hardware R600 only TeraScale 3 RV960(yes a subset of northern islands) appear to have the hardware in memory management required for Vulkan so the 2010 card. But no one is investing the developer time to bring this up.

    Lot of 20+ year old hardware has been dropped because the hardware is most failing at this point and no one is there to take care of the drivers or even test that the drivers have not been broken up updates. So this was not dropped just because it could not run anything modern they were dropped that there was no test reports that the worked at all.

    Comment


    • #82
      Originally posted by oiaohm View Post



      KMS and DRM are adding the means to do both implicit and explicit fencing.

      Linux kernel graphics drivers drivers include with the Linux kernel are explicit fencing. Its the wrappers like KMS/DRM that implement the implicit fencing so the drivers don't have to. Yes if no implicit sync ioctl or syscall is used then the implicit sync functionality in Linux kernel does nothing.

      Nvidia doing their own thing means they were not behind the Linux kernel provided wrappers. Thing to remember users are not going to update all their applications any time soon. So trying to demand everyone changes to explicit sync instantly completely failed. Also there is a problem with the way explicit sync has been done result in a few cases where there is not performance gain or equal performance in the explicit sync direction instead there is a performance loss. These explicit sync problems still need to be addressed. Its the waiting problem.

      This waiting problem is a classic bad penny problem that keeps on turning up. Someone does some modification that massive reduces the size of waits they implement it claim all kind of gains they poorly benchmark it so they fail to notice they just made a spinlock again. The issue with a spinlock is that you are waiting in userspace instead of going to kernel space to wait where the CPU resources can be reallocated.

      There is a real repeating failure to learn this one from history.

      There is another problem is failure to notice that applications are going to get fencing wrong. Explicit sync will not prevent applications setting up fences for existing hardware behavior that will not remain true into the future.
      I hope the kernel team is able to modernize that side of linux. Now that Linux gaming is becoming bigger, we need all the support we can get from there.

      Comment


      • #83
        Originally posted by jorgepl View Post
        I hope the kernel team is able to modernize that side of linux. Now that Linux gaming is becoming bigger, we need all the support we can get from there.
        That the thing the Linux mainline is following the path of modernizing. Yes modernizing does not equal making legacy stuff no longer function this is why you are seeing wrappers. The wrappers is so the older interfaces remain working whiling providing a new interface. Its also good that Nvidia is now working their way in the direction open sourcing their GPU kernel driver with the idea of mainlining it finally.

        Comment

        Working...
        X