Announcement

Collapse
No announcement yet.

DRI3000 Still Being Developed For New X.Org DRI

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

  • marek
    replied
    drag, I'll correct a couple of things in your post.

    Originally posted by drag View Post
    "DRI" is the driver protocol for open source drivers. It describes the 'Stable API' that is used for the userspace DRI driver to communicate with the kernel DRM driver.
    DRI is the protocol for communicating between the application and the X server. The kernel has very little to do with it.

    Originally posted by drag View Post
    DRI-3000 will improve things for Wayland a lot, but it will also improve XFree a lot also.
    DRI-3000 will only improve things for the X server. It has nothing to do with Wayland.

    Originally posted by drag View Post
    A example of this is that it will create a standard way for drivers to transfer buffers from one application to another.
    As far as I know, DRI-3000 is pretty much all about improving SwapBuffers and presenting stuff on the screen with the X server. We only need a way to share buffers between the application, the compositor, and the X server, but we don't need to share buffers with any other application.

    Leave a comment:


  • Rexilion
    replied
    Originally posted by drag View Post
    Very confusing way to state things.

    "DRI" is the driver protocol for open source drivers. It describes the 'Stable API' that is used for the userspace DRI driver to communicate with the kernel DRM driver.

    "DRI 3000" is going to be a improvement over DRI 2, which is what we use now. DRI-3000 will offer numerous security, stability, and performance improvements over DRI 2 drivers.

    ...

    So in conclusion:

    Wayland and DRI 3000 together should allow the DRI drivers to become much more efficient then X and DRI 2. They will cut down dramatically on memory bandwith usage for composited desktops. It will free up bandwidth for rendering and it will make it much easier to get rid of things like tearing, dramatically improve media playback performance, etc etc etc.

    X will be helped out also.
    Thanks! So if I take this right, the things that Wayland is doing right are now being propagated into the kernel. And by using standard kernel (Unix?) mechanisms, there are more benefits such as improved memory handling and performance increases.

    Thank you.

    Leave a comment:


  • garegin
    replied
    given the low resources that x.org/wayland guys have, isn't it a better idea to throw more manpower on fixing up the toolkits for wayland instead of improving X which would be dumped anyway.

    Leave a comment:


  • Ericg
    replied
    Originally posted by drag View Post
    Very confusing way to state things.

    "DRI" is the driver protocol for open source drivers. It describes the 'Stable API' that is used for the userspace DRI driver to communicate with the kernel DRM driver.

    Wayland and XFree DDX (X.org's X Server for Unix systems) both can use DRI drivers. DRI-3000 will improve things for Wayland a lot, but it will also improve XFree a lot also.

    "DRI 3000" is going to be a improvement over DRI 2, which is what we use now. DRI-3000 will offer numerous security, stability, and performance improvements over DRI 2 drivers.

    A example of this is that it will create a standard way for drivers to transfer buffers from one application to another.

    There are a couple ways that I can remember from the previous talk (which you can watch online) if I remember correctly:

    DRI 2 for Intel uses reference counting for keeping track of application buffers. When a application uses a buffer it will increment the count by one, when a application drops the buffer it decrements it. When the count goes to zero it will drop the buffer. When DRI 2 transfers buffers between application it many times has to copy the buffer or translate the image buffer from one format to another. (this is partially caused by requirements for X protocol, but it's also caused by how the drivers handle buffers)

    DRI 3000 will instead use the Linux kernel's in-built way it hands file descriptors (FD). So when a application creates a buffer the driver will create a FD to point to it. The way Linux counts FDs is much faster, mature and more efficient then the way DRI 2 drivers did. The Linux kernel can take over the more of the work of keeping track of memory management and will know naturally which applications have which FDs. When all the applications close out the FD then Linux kernel will simply drop the buffer. No need for the drivers or applications to have to keep special track of who has what open.

    Also when it needs to transfer the buffer between applications or between the application and the display server it can simply pass the file descriptor between applications rather then doing any copying. The file descriptor is very small number and can be copied much quicker then a entire image buffer.

    If you are using Wayland then things get much better because it does not require any of the pre-writing to the buffer, copying of the buffer, and conversion of image formats that X requires.


    Note that everything and anything I said could be incorrect or just misleading. I recommend watching Packard's talks yourself.


    So in conclusion:

    Wayland and DRI 3000 together should allow the DRI drivers to become much more efficient then X and DRI 2. They will cut down dramatically on memory bandwith usage for composited desktops. It will free up bandwidth for rendering and it will make it much easier to get rid of things like tearing, dramatically improve media playback performance, etc etc etc.

    X will be helped out also.
    Thanks Drag, I didn't feel like typing everything out on my phone so I just went with the simplest answer I could haha

    Leave a comment:


  • drag
    replied
    DRI-3000 and Wayland do much the same thing in the same way
    Very confusing way to state things.

    "DRI" is the driver protocol for open source drivers. It describes the 'Stable API' that is used for the userspace DRI driver to communicate with the kernel DRM driver.

    Wayland and XFree DDX (X.org's X Server for Unix systems) both can use DRI drivers. DRI-3000 will improve things for Wayland a lot, but it will also improve XFree a lot also.

    "DRI 3000" is going to be a improvement over DRI 2, which is what we use now. DRI-3000 will offer numerous security, stability, and performance improvements over DRI 2 drivers.

    A example of this is that it will create a standard way for drivers to transfer buffers from one application to another.

    There are a couple ways that I can remember from the previous talk (which you can watch online) if I remember correctly:

    DRI 2 for Intel uses reference counting for keeping track of application buffers. When a application uses a buffer it will increment the count by one, when a application drops the buffer it decrements it. When the count goes to zero it will drop the buffer. When DRI 2 transfers buffers between application it many times has to copy the buffer or translate the image buffer from one format to another. (this is partially caused by requirements for X protocol, but it's also caused by how the drivers handle buffers)

    DRI 3000 will instead use the Linux kernel's in-built way it hands file descriptors (FD). So when a application creates a buffer the driver will create a FD to point to it. The way Linux counts FDs is much faster, mature and more efficient then the way DRI 2 drivers did. The Linux kernel can take over the more of the work of keeping track of memory management and will know naturally which applications have which FDs. When all the applications close out the FD then Linux kernel will simply drop the buffer. No need for the drivers or applications to have to keep special track of who has what open.

    Also when it needs to transfer the buffer between applications or between the application and the display server it can simply pass the file descriptor between applications rather then doing any copying. The file descriptor is very small number and can be copied much quicker then a entire image buffer.

    If you are using Wayland then things get much better because it does not require any of the pre-writing to the buffer, copying of the buffer, and conversion of image formats that X requires.


    Note that everything and anything I said could be incorrect or just misleading. I recommend watching Packard's talks yourself.


    So in conclusion:

    Wayland and DRI 3000 together should allow the DRI drivers to become much more efficient then X and DRI 2. They will cut down dramatically on memory bandwith usage for composited desktops. It will free up bandwidth for rendering and it will make it much easier to get rid of things like tearing, dramatically improve media playback performance, etc etc etc.

    X will be helped out also.

    Leave a comment:


  • Ericg
    replied
    Originally posted by Rexilion View Post
    Isn't this implementing something to fix the same problem that initiated the development of Wayland?
    DRI-3000 and Wayland do much the same thing in the same way, DRI3000 makes X very Wayland-like in implementation but we still need a break from the X protocol just because the X protocol is so terrible. Other benefits of Wayland are breaking from GLX (which if you read the blogpost, Keith is breaking certain GLX conditions anyway) and moving to standardized EGL.

    Its a step in the right direction, towards the goal and objective, but it not the objective in and of itself. The objective is no more X, no more legacy, no more 20 or 30 years of cruft and bad design decisions.
    Last edited by Ericg; 13 April 2013, 03:18 PM.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by Rexilion View Post
    Isn't this implementing something to fix the same problem that initiated the development of Wayland?
    no, DRI3 find to fix certain conditions in the stack that are very redundant or inefficient for modern hardware and it will benefit wayland/Xorg and the likes but in no way is a fix for any of latters.

    Leave a comment:


  • Rexilion
    replied
    Isn't this implementing something to fix the same problem that initiated the development of Wayland?

    Leave a comment:


  • Ericg
    replied
    Thanks Michael, I was wondering what ever happened with DRI-3000 after linux.conf.au

    Leave a comment:


  • phoronix
    started a topic DRI3000 Still Being Developed For New X.Org DRI

    DRI3000 Still Being Developed For New X.Org DRI

    Phoronix: DRI3000 Still being Developed For New X.Org DRI

    While there hasn't been too much news on the work recently, DRI3000 (DRI3) is still being developed...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
Working...
X