Results 1 to 9 of 9

Thread: Mixed Feelings Over The PSCNV Nouveau Driver Fork

  1. #1
    Join Date
    Jan 2007
    Posts
    15,098

    Default Mixed Feelings Over The PSCNV Nouveau Driver Fork

    Phoronix: Mixed Feelings Over The PSCNV Nouveau Driver Fork

    Three days ago we passed along the latest information on the PSCNV driver, which is a fork of the open-source Nouveau driver for NVIDIA graphics cards, with this information coming from Christopher Bergström of PathScale. As this was one of our first articles talking about the PSCNV driver at length, many readers were surprised by this fork with the upstream Nouveau driver still lacking even an official release. Some feel that this fork is a bad idea (it's even been compared to the dead RadeonHD driver) while others are in support of PathScale's efforts. Since publishing that article we have learned a few more details on the PSCNV driver from some of its developers within our forums...

    http://www.phoronix.com/vr.php?view=ODczNg

  2. #2
    Join Date
    Feb 2009
    Location
    France
    Posts
    309

    Default

    Quote Originally Posted by phoronix View Post
    From Martin's comment, PathScale is not only interested in GPGPU on NVIDIA cards, but to increase performance. Martin says their 2D Fermi support is up to 50% faster than NVIDIA's official proprietary driver.
    Well, I said that of my version of libdrm which isn't working properly currently and it was on my nv86. I have no nvcx to try it with.
    The other libdrm supporting pscnv is slower but works way better

  3. #3
    Join Date
    Oct 2007
    Posts
    288

    Default

    "The OpenGL4 comment was only a personal one. I would really love to see a community of developers make a todo list, plan and try to tackle this. I think within a year's time if it's broken down into small manageable pieces with good docs it can be done."
    Erm yeah sure.. The problem is not the opengl extensions since they can't be _that_ hard to implement.. The problem is the extremely high learning curve for driver development in general and TGSI. And the different "IL" layers in nvidia and amd don't make it much easier.

    Anyway, a 2d performance that is 50% better then the proprietary nvidia driver? Compared to what? windows or linux? Even then, that must be a "special" way of doing things so perhaps that "special" way can also be implemented in the r600c/g drivers? ^_^

  4. #4
    Join Date
    Oct 2007
    Posts
    288

    Default

    @Michael you have an issue in vbulletin : "Bergström"
    doctype setting perhaps? utf-8 not being used?

  5. #5
    Join Date
    Feb 2009
    Location
    France
    Posts
    309

    Default

    Quote Originally Posted by markg85 View Post
    Erm yeah sure.. The problem is not the opengl extensions since they can't be _that_ hard to implement.. The problem is the extremely high learning curve for driver development in general and TGSI. And the different "IL" layers in nvidia and amd don't make it much easier.

    Anyway, a 2d performance that is 50% better then the proprietary nvidia driver? Compared to what? windows or linux? Even then, that must be a "special" way of doing things so perhaps that "special" way can also be implemented in the r600c/g drivers? ^_^
    It was tested on Linux. The blob is terrible at doing 2D stuffs. I guess the reason why pscnv is so fast on 2D is because command submission is done from the userspace and not from the kernel space as the blob and nouveau do.
    Also, contrary to nouveau and the blob, I was using a single big buffer to send the commands and used it as a ring-buffer. This proves useful when we are sending a shitload of commands, we wait less so it is more efficient on the CPU and on the GPU.

    Anyway, don't trust this number too much, it is from an experimental code that may not work very well later. I have stopped working on libdrm and went to PM as I was kind of stuck with some issues I could'nt solve (I'm a noob). Someone else did a quick libdrm port (Christopher Bumiller) and we are using it to get accelerated X on nv50+.

    As for this being possible on radeon cards, I asked Alex Deucher at the XDS. I can't really remember what his answer was but I seem to recall it was impractical due to hw design.

  6. #6
    Join Date
    Feb 2009
    Location
    France
    Posts
    309

    Default

    Quote Originally Posted by MPF View Post
    It was tested on Linux. The blob is terrible at doing 2D stuffs. I guess the reason why pscnv is so fast on 2D is because command submission is done from the userspace and not from the kernel space as the blob and nouveau do.
    Also, contrary to nouveau and the blob, I was using a single big buffer to send the commands and used it as a ring-buffer. This proves useful when we are sending a shitload of commands, we wait less so it is more efficient on the CPU and on the GPU.

    Anyway, don't trust this number too much, it is from an experimental code that may not work very well later. I have stopped working on libdrm and went to PM as I was kind of stuck with some issues I could'nt solve (I'm a noob). Someone else did a quick libdrm port (Christopher Bumiller) and we are using it to get accelerated X on nv50+.

    As for this being possible on radeon cards, I asked Alex Deucher at the XDS. I can't really remember what his answer was but I seem to recall it was impractical due to hw design.
    In fact, the blob does userspace command submission too.

    Also, it seems like the slow 2D may only be Qt related.

  7. #7
    Join Date
    Jan 2010
    Posts
    365

    Default

    Qt is well known for having bad xrender support.

  8. #8
    Join Date
    Sep 2006
    Posts
    714

    Default

    Who knows.


    Maybe Intel was right to abandon TTM and go with their own GEM solution. Maybe TTM sucks that much, or that it's more practical to have a memory management solution for each hardware type.

    As long as these forks do not get all ideological and are willing to work together to find the best solution then I don't see anything wrong with it.

    May the best video memory management scheme win!

  9. #9
    Join Date
    Jan 2009
    Posts
    625

    Default

    TTM was designed for graphics and we believe it's quite good at it, but Pathscale wants a memory manager for compute. If their solution turns out to be good enough even for graphics, we might end up switching over to it for Radeons. Let's see.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •