Plans Being Drafted To Upstream Intel's New "Xe" Linux Graphics Driver

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

  • TemplarGR
    replied
    Originally posted by rogerx View Post

    I'm not seeing anything on Xorg Wikipedia stating the project is deprecated or obsolete, except for the X11R6.9 branch being in a frozen state, while the modular development of Xorg is on going.

    For some odd reason, I found myself laughing at the usage of the word should.

    So far, I see Wayland/Vulkan graphical interfaces are supposedly great for playing games. Or reiterate, Wayland/Vulkan supposedly provide great frames per second, with less overhead/wasted resource usage.
    Since when Wikipedia is the one source for everything? Everyone knows Xorg has ceased getting serious development and is in maintenance mode....

    Leave a comment:


  • rogerx
    replied
    Originally posted by TemplarGR View Post

    You are... While i do agree that testing on X won't be a priority considering it is an obsolete platform, the 2 drivers use the same interfaces with the user stack, so if one works the other should probably work the same. Only the internals of the drivers will change.
    I'm not seeing anything on Xorg Wikipedia stating the project is deprecated or obsolete, except for the X11R6.9 branch being in a frozen state, while the modular development of Xorg is on going.

    For some odd reason, I found myself laughing at the usage of the word should.

    So far, I see Wayland/Vulkan graphical interfaces are supposedly great for playing games. Or reiterate, Wayland/Vulkan supposedly provide great frames per second, with less overhead/wasted resource usage.

    Leave a comment:


  • TemplarGR
    replied
    Originally posted by rogerx View Post
    What bugs me with the re-write, although looks like a really good thing, wondering if this Intel i915 DRM re-write will turn into another systemd method of tearing apart something working and stable on X/Xorg, with the re-written i915/Xe driver subsequently only being stable when using Wayland in comparison to X/Xorg.

    Hopefully I'm just being overly touchy-feely on this.
    You are... While i do agree that testing on X won't be a priority considering it is an obsolete platform, the 2 drivers use the same interfaces with the user stack, so if one works the other should probably work the same. Only the internals of the drivers will change.

    Leave a comment:


  • TemplarGR
    replied
    Originally posted by uid313 View Post
    My dream is Intel Xe graphics on a Intel-designed ARM or RISC-V CPU.
    My dream is sometime in the far far future, millennia later, people will stop thinking x64 adds significant overhead at modern process nodes and any tiny overhead it still adds is worth it immensely for software compatibility.

    Leave a comment:


  • rogerx
    replied
    What bugs me with the re-write, although looks like a really good thing, wondering if this Intel i915 DRM re-write will turn into another systemd method of tearing apart something working and stable on X/Xorg, with the re-written i915/Xe driver subsequently only being stable when using Wayland in comparison to X/Xorg.

    Hopefully I'm just being overly touchy-feely on this.

    Leave a comment:


  • rogerx
    replied
    First sentence, is run-on sentence:
    While the Linux 6.3 merge window has just begun, what you won't find in this next kernel version is the Intel Xe DRM driver as the new kernel graphics driver being worked on by the company for their modern integrated and discrete graphics processors.

    Should be:
    While the Linux 6.3 merge window has just begun, what you won't find in this next kernel version is the newer Intel Xe DRM driver, as the newer kernel graphics driver IS being worked on by the company for their modern integrated and discrete graphics processors.

    The "is" was apparently accidentally omitted, creating a run-on sentence. Also should add "newer" to the initial mention of the "Intel Xe DRM driver" for reading clarity.

    With respect towards every writer's own methods, typically "won't" should be written as "will not", but again, this is up to each and every individual's writing techniques.

    Shrugs... main problem was the run-on sentence.

    Leave a comment:


  • mangeek
    replied
    Originally posted by Vermilion View Post

    Does this blog post help?
    It does, but it seems to be more about what's outside of the kernel than inside. Seems like the kernel drivers expose several interfaces that could end up being used to accomplish 'picture on a screen'. Are there opportunities to make a kernel driver smaller/simpler if it only exposes a DRI path? Can other interfaces be piped through DRI (thinking of the console, DDX, etc.)?

    Leave a comment:


  • Vermilion
    replied
    Originally posted by mangeek View Post
    I've been curious about what parts of Linux graphics happen in the kernel driver vs. Mesa and userland. Is there a good 'explain like I'm... forty' write-up of this? I thought the kernel side was rather 'light', but it's dawning on me that I might have the wrong impression, and I'm not hip enough to understand what's going on in /linux/drivers/gpu/drm/* .
    Does this blog post help? https://blogs.igalia.com/itoral/2014...raphics-stack/
    Note that it's a bit old so it only mentions X11.

    Leave a comment:


  • uid313
    replied
    My dream is Intel Xe graphics on a Intel-designed ARM or RISC-V CPU.

    Leave a comment:


  • mangeek
    replied
    I've been curious about what parts of Linux graphics happen in the kernel driver vs. Mesa and userland. Is there a good 'explain like I'm... forty' write-up of this? I thought the kernel side was rather 'light', but it's dawning on me that I might have the wrong impression, and I'm not hip enough to understand what's going on in /linux/drivers/gpu/drm/* .

    Leave a comment:

Working...
X