Reply With QuoteWell, 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.Originally Posted by phoronix
The other libdrm supporting pscnv is slower but works way better
Phoronix News Bot
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
Nouveau
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
Senior Member
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."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."
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? ^_^
Senior Member
@Michael you have an issue in vbulletin : "Bergström"
doctype setting perhaps? utf-8 not being used?
Nouveau
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.
Nouveau
In fact, the blob does userspace command submission too.
Also, it seems like the slow 2D may only be Qt related.
Senior Member
Qt is well known for having bad xrender support.
Senior Member
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!
X.Org Developer
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.
