Free Fermi cards to interested developers and researchers
Hi all PathScale is giving away a limited amount of Nvidia Fermi cards to qualified open source developers and researchers. We are mainly focused on our optimized gpu compiler and the HPC market, but also open to sponsoring creative ideas or projects surrounding the gpu. Here's a short list of some of the areas most interesting to us * Nouveau/kernel drivers * CUDA * OpenCL * HMPP * Parallel programming * MPI * Shader compilers If you're interested please contact me offlist with a brief description of your background, the contributions you made to open source and what you'd intend to do with the card. Thanks Christopher #pathscale - irc.freenode.net -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Alan Cox wrote: >> Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The >> guy who is, as far as I know, effectively in charge of that whole >> integration. Yeah, I realize that there are other people (Kyle?) involved, >> and maybe Dave isn't as central as I think he is, but I learnt from last >> time that the nouveau guys don't seem to care. >> > > Ok "screamed about" is perhaps better wording. Why should the Nouveau > guys care ? You've forced their hand, you've demanded stuff they > said they didn't want to do and then you've bitched about things they > said they would do. Actually I think they've been quite restrained. I'd > probably have proposed a licence change to make it only work on FreeBSD > and Solaris given that treatment ;) > Our OpenSolaris port isn't done yet.. ;) Oh.. and I hope you won't mind if we break the API in doing so.. *cough* /me hides -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Pekka Enberg wrote: > On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar wrote: > >> The conclusion is crystal clear, breaking an ABI via a "flag day" >> cleanup/feature/etc is: >> >> - wrong >> >> - harmful >> >> - limits the developer base >> >> - limits the tester base >> >> - wastes time and effort. (fewer developers/testers means that while _this_ >> feature was easier to add, all your _future_ features will be a bit harder >> to do. It compounds up.) >> >> - so it hurts even the very developer who is most convinced that this was >> the >> right thing to do >> >> It's a bad technical decision throughout. It's masochistic and often suicidal >> to just about any project in essence. I've seen projects that did it once and >> died just due to that single act of stupidity. I've seen projects that have >> done it a few times and took the usage hit, limped along with the wounds and >> never grew to the size they could have achieved. I've seen projects that did >> it once, took the hit, learned from it and never did it again. >> > > Agreed. What bothers me in this discussion is that people keep > bringing up the fact that nouveau is mostly developed by volunteers > and thus it doesn't make sense to make sure it's backwards (or > forwards) compatible. But the way I see it, it's the complete > opposite. It's _more_ important to support ABIs for community-driven > efforts because you're relying on people who by definition don't have > time to waste. While the nouveau people might have good intentions, > I'm afraid they might be severely limiting their developer and tester > base because they're not focused on real world problems (like the ones > Linus is seeing). staging != stable Nobody guaranteed a stable API for staging and in fact it was stated previously it needed to be changed. Please lets just get back to work and stop declaring the sky is falling. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
Linus Torvalds wrote: > On Thu, 10 Dec 2009, Alan Cox wrote: > >>> But not only is Fedora not following the rules, >>> >> You changed the rules. You require a Signed-off-by:. Fedora can no more >> add a signed off by than you can. It's not their code nor Red Hat's code >> any more than they "own" the kernel because they pay someone to work on >> it. >> > > You're avoiding the point: they are shipping it, they are paying for (at > least some) development, and they seem to not even want to face the issue. > > Sign-offs aren't some new feature that took Red Hat people by surprise. > The "get it merged upstream first" didn't change in any way from it: it > just codified existing practice - of _course_ everybody expects copyrights > to be honored and clear. > > >> It's really simple: if you want to merge it *you* pull it and sign it off. >> If you aren't prepared to do that then ask why Fedora should, its not >> their code either. >> > > I'm not shipping it. They are. That's the difference. > > I realize that you have some emotional attachments to Red Hat, but ask > yourself (and answer honestly): what would you think if some random other > distro was packaging tens of thousands of lines of kernel code and not > apparently working at trying to get them upstream? > > Dave claims it's only been going on for a few months, but quite frankly, > we all know better. The nouveau kernel modules have been shipped for a lot > longer than just F12. > > And it's possible that other distros are doing the same thing. I happen to > know that Fedora does it (and has been doing it for at least a year), > because I happen to have an Intel development machine that runs Fedora and > was shipped by Intel with an nVidia card (and has a power supply that > craps out if you don't use several hundred watts of power, so I can't > change it to something more power-efficient - seriously). > Thanks for the rather lengthly explanation, but in case you missed what people are trying to say here.. With all due respect Linus.. "patches welcome" -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
Pekka Paalanen > The fact is, if there are license questions, then Fedora had > better not be distributing the code either. And they clearly are. I've no idea how they pulled that, but I have not heard anyone say that there are *no* legal issues at all. > I've heard the "but it's hard to merge" excuse too - which I also > know is bullshit, because I can look at the git tree Fedora > apparently uses, and it merges without any conflicts what-so-ever. No-one has said that about Nouveau, have they? > The most common excuse is the "oh, but it might change" crap. But > that's not even a very good excuse to start with, and it's what > staging is for anyway. Yes, and to my understanding Nouveau is past that excuse. People just like to quote what they heard last. The big question is what we call ctxprogs: binary blobs that are clearly executable, running somewhere in the GPU. No-one seems to know, if those are copyrightable, or if they can be redistributed. In their current form, they have been recorded from the nvidia proprietary driver using mmiotrace, and copied verbatim for each card type. Would you be willing to pull that kind of stuff into Linux? I would not even dare sending them to the Linux firmware repository, since they have some license requirements, too. --- (apologies about the copy paste of thread, but I'm joining the list late) Please see my other response. From my perspective there is only technical issues remaining and no license issues. I am just evaluating and receiving information from one of the nouveau devs. However, ctxprogs was obtained in the same way that the rest of the information was via dumping from the mmio-traces. (As stated above) -- So beyond all this I have been in discussion with someone at nv about their view. I have a call setup for next Monday and anyone interested to participate or listen in please ping me off list. ./C -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
I'm trying to put together a highly optimized compute driver for the company I work for and had to ask this question myself recently. From what I know there's only one reason it hasn't gotten pushed, but that's being worked on by someone at RH. However to clear up some of the doubts about this licensing bs.. Someone from SFLC was kind enough to provide.. (copy/paste with part not needed omitted) Generally, there are three ways to infringe copyright: actually copying (or modifying or distributing) a copyrighted work (a typical copyright infringement), circumventing a technological measure that controls access to a copyrighted work (a DMCA violation), or violating the license that gave you the right to copy the work to begin with (a EULA violation). If the Nouveau FAQ is correct, and they are not copying or modifying NVidia's blob, then this cannot be a copyright infringement in the classic sense. I also don't think that monitoring GPU register activity or the graphics card's memory is a DMCA violation. Neither of these data are copyrighted material. The blob is, but Nouveau isn't trying to access the blob, and I see no evidence that NVidia has used any technological measures to protect it anyway. ... An important disclaimer in case you intend to share this email with anyone at the Nouveau project: please keep in mind that this is privileged advice for you, and not for the Nouveau project generally. If you chose to share any of this information with the Nouveau project or any third party, you would wave attorney-client privilege regarding this email and the third party should not rely on this advice, but should seek their own counsel. - ./C -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
