Printable View
Another question to PSCNV developers. Have you raised your concerns about Gallium quality in the mesa-dev mailing list? (in other words: are you trying to work in silence without opinion sharing?) The fact that Phoronix knows your opinion on Gallium but the Gallium maintainers don't is rather sad and nonprofessional.
Marek, what do you mean? Pscnv is opensource, you can find it in the github repo. If upstream wants the changes it has to port it over. Given that many of the pscnv developers are also nouveau developers we will see this porting sometime in the future. But you _have to_ fork a project when you crush certain design decisions of the upstream project, you can't criticize the current design without having a superior solution. So developers need some type of playground to see if their ideas work out.
When other parts of the graphics stack have to be modified it will be done in the project repos of that particular part. Many of the concerns about gallium have been brought up on the mesa-dev list over the last months. Why should persons don't express their opinion about this publicly when they are simultaneously working on fixing the issues?
sifnt: Thanks, we are also exited about using GPUs do offload some calculations to it.
HMPP is all about using compilers to generate GPU code and all the synchronisation needed for you. You just tell what part of the code you want to offload and it will magically be offloaded :)
Marek: The kernel driver, libdrm and the (very slightly modified) ddx are and will stay open source. As for mesa, they are working upstream as they have commit access.
For more information, you may ask to codestr0m on IRC (#pathscale on freenode)
I'm not a Pathscale official, I'm just helping them with pscnv, accelerated X (I failed on that, I have a stupid bug that prevents everyone from using it, there are no texture. Someone else hacked-up another libdrm and it works but it is a bit slower.) and Power Management (I'm doing a better job but I badly need more skills and knowledge).
I promise I'll try my best to merge everything upstream ASAP. My libdrm work was in this direction (libdrm would support either nouveau or pscnv by detecting at runtime which one is loaded) and Power Management is developed on nouveau (for testing and userbase) and is integrated as is in pscnv.
Lynxeye: We are not currently changing anything in gallium, the only work done on gallium is hacking up a small support for 3D on Fermi. It kind of works but it is far from completion.
Everyone: If you want some info, please join us on IRC (#pathscale on freenode) and ask your questions.
Sorry I'm late to this thread and will try to clarify things.. (also apologies in advance for the mixing up quotes)
>I like to use the word sucks, but you can check the public wiki page for a list of reasons why pscnv exists. Also I can find a multitude of public comments from others who don't like gallium, TGSI and show that it's performance for 3D has a lot of room for improvement. The comment about gallium is totally a personal one and should not reflect on PathScale at all.Quote:
I hope they don't go around re-doing everything because they think "it sucks" and their work just gets lost on it all, or gets very hard to use because they patch things everywhere.
>Try it and then come off the sidelines to send us a patch if does anything useful to you. When your ideas on performance and engineering are unresolvable with code developers on a project what else can you do besides fork? Seriously? Think about that and then once you've sent a patch talk about integrating with the rest of the open source crowd. Also we're really focused on compute which nobody else in open source is even doing and I fail to understand what crowd we're not playing well with.Quote:
This fork smells like Reiser4 all over: PathScale may come up with something which performs on a Fermi GPU, but their efforts do not seem to be very well integrated with the rest of the open source crowd
>From my perspective pscnv is really a *compute* driver.. Some people are working on various graphics things, but that's all community people who are volunteering hard time. Also if you try to dig into the *facts* you'll see that quite a few of the pscnv volunteers are still helping nouveau where the benefits overlap.Quote:
looks like radeonhd not taught them that incompatible user-alienating ununified community-dividing graphic driver forks are shortliving, useless and disrupting.
>pscnv is developed fully in the open.. please visit our irc channel #pathscale or pull the source which is regularly updated and try it..Quote:
there may be technical reasons for reinventing the wheel, but they must be aware that this sort of insular development
> isolated from most of the OSS community is usually doomed from the outset.
>For graphics this is true, but for compute I disagree. We currently have (I believe) nv50+ support.. (This could be nv84+ as I haven't personally tested on an nv50 device) You can't even go further back since the hardware wasn't even compute capable...Quote:
I don't think PathScale has any intention of creating a generally useful driver for the benefit of the community at large.
>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 years time if it's broken down into small manageable pieces with good docs it can be done.Quote:
Specific people may find specific advantages for a limited set of hardware (NV50 or newer), but they seem uninterested in the 3d stack. They then tell us that they're looking to add OpenGL 4 support, which is an extremely dubious claim, even for a big company. What, are they just going to build their own 3d driver from scratch on top of their own custom kernel memory manager? How many people do they have working on this project?
>
>Yepp we are sticking to compilers and you'll see that's why we focus on compute. People are beating us up for not supporting graphics, but c'est la vie. The confusion here may be my personal comments about wanting graphics which aren't cleanly separated.Quote:
And a compiler company, to do all this? Maybe they should stick with compilers for the CPU. They don't seem to understand how the open source world (or the graphics device driver world, for that matter) works.
>
>How unfair! You do realize that this doesn't just magically happen and it's really a big first step.. NVIDIA makes awesome hardware and comparing it to a $15 Intel card just isn't fair because some random open source project software isn't ready..Quote:
But hey, people who want really fast 2d on their new awesome $500 Fermi card can grab pscnv and be amazed at the glorious non-composited desktop (that a $15 Intel chip can do equally well)...
>CAPS and PathScale made HMPP directives an open standard to solve this problemQuote:
And HMPP is proprietary software,
http://www.pathscale.com/node/232
>There's more in the world than mainline linux kernel.. I also wonder if you've given consideration for the *huge* academic community who is doing GPGPU research. Redhat sells support/licensing on top of open source and I don't see them having any trouble contributing to open source. Also Mupuf (wrongly) linked to the CAPS HMPP which is their implementation of the standard.Quote:
so it looks like your interest is in enabling this open source driver to actually outperform the proprietary NVidia driver, with the goal of selling more licenses of your proprietary software. Nice, but again, this is not something that will appeal to the open source community.
>
> Good luck to you guys, I'm sure you will sell some licenses to some big-name companies for this, but don't expect much in the way of community enthusiasm or opportunities for making it to the mainline Linux kernel.
>Yes this was my personal comment (to repeat myself)Quote:
Heh... the article makes it seem like Christopher Bergström wrote "OpenGL 4" in his email:
>We're open to it, but there's three things involved here..Quote:
One question though is that if your efforts are successful and you improve certain aspects of the driver will the two projects ever merge back together. If not why not?
a) A couple of the main nouveau devs would really have to let TTM get refactored out. (We still conform to the GEM interface)
b) The technical challenge of merging the code (which has diverged quite a bit)
c) Graphics support for nv50 and pre-nv50 cards would have to be improved (I think this is totally possible, but I don't know how much work)
>Could you help with some of this testing and benchmarking?Quote:
But please remember that if you do merge with nouveau, do some performance comparisons on the 3d side for a while to determine whether you are negatively impacting that. I don't think very many users would appreciate (hypothetically) a merge with nouveau that improves GPGPU performance at the expense of 3d.
>Thank you!Quote:
Craig73 I really appreciate the work they are embarking on...
>The graphics stuff is all done in open and may be scattered because of the various different ways at trying to solve the same problem (libdrm changes for example) If you ask in #pathscale I'm sure someone can help find what you're looking for.Quote:
Just a little question. You are replacing a lot of components in the current graphics stack. Which of those will be open-sourced and pushed upstream?
>I never imagined my personal and flippant comments would be directly relayed into an article. However, when and if I personally have time I will do my best to create an accurate list of problems I see with TGSI and gallium.Quote:
Another question to PSCNV developers. Have you raised your concerns about Gallium quality in the mesa-dev mailing list? (in other words: are you trying to work in silence without opinion sharing?) The fact that Phoronix knows your opinion on Gallium but the Gallium maintainers don't is rather sad and nonprofessional.
Thanks for the answers, the whole situation is now clearer to me.
Yeah I recall some discussion on mesa-dev. I think it was just indirect addressing using pure temps and not temporary arrays and therefore making some optimizations unapplicable (and the whole temporary file had to be spilled out needlessly on nv50). But it's something that can be fixed.
I don't think TGSI is going to be replaced. It's just a "transport" representation for sending shader code from one component to another. It's not supposed to be used for code transformations (optimizations, etc.). Instead, a driver should convert it to whatever internal representation it needs and do any transformations there. If this transport IR (TGSI) does not contain enough information to have full hardware support and being able to do all the optimizations you need, it should be extended to meet your requirements instead of rewritten.
I really don't get it - why we need a fork of a very incomplete and immature product? Why do we need to squander so scarce resources?
My understanding is that the Pathscale work is aimed at completely different goals from Nouveau (an HPC compute runtime vs. a graphics driver stack) so forking the code while pushing stuff back and forth where possible may be the most efficient approach during the initial implementation.
There are basically two options :
1. Only implement changes which are fully compatible with the existing graphics code, which arguably limits what you can do with compute
2. Implement what you think is best for compute, then periodically go back and see what can be shared or made common between graphics and compute
It's probably worth reading up a bit on the programming model Pathscale is implementing... it might help to explain why implementing in a separate code base probably makes sense, at least for now.
Looking forward to see the outcome of your efforts guys. It's nice to see someone finally get the ball rolling on GPGPU computing with an opensource solution. It is a pity that despite the openCL spec being out for a few years now and being completely open that it is just now someone is seriously addressing it in the opensource community.
One more comment, I am surprised however that the first real efforts would be done on nvidia hardware given the close relationship PathScale has with AMD and their availability of semi-open hardware and specs.