If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

They don't like Gallium, don't like TTM (GEM too I guess) and are interested in *BSD/OpenSolaris(/ReactOS?). Sound a little weird to me. It sounds they already created own memory manager (couldn't TTM be improved any way?), hope they won't create new Mesa framework.

Comment

They don't like Gallium, don't like TTM (GEM too I guess) and are interested in *BSD/OpenSolaris(/ReactOS?). Sound a little weird to me. It sounds they already created own memory manager (couldn't TTM be improved any way?), hope they won't create new Mesa framework.

My thinking exactly.

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.

Comment

They don't like Gallium, don't like TTM (GEM too I guess) and are interested in *BSD/OpenSolaris(/ReactOS?). Sound a little weird to me. It sounds they already created own memory manager (couldn't TTM be improved any way?), hope they won't create new Mesa framework.

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. Nobody will want to include it later since it is incompatible with the current state of kernel and X.Org, and nobody will want to support it when PathScale decides to no longer work on it one day. And they already started insulting people ("Gallium has very low quality" etc.). GREAT move, PathScale! Did Hans Reiser not teach you anything?

Since all the things they point out in TTM seem fixable to me, and Nouveau already supports quite some stuff on NV50, why don't they just branch both projects and work with the community? Would probably take a bit longer, but if they really come up with something working until the end of the year it will probably already be included in the next bigger distributions (Ubuntu 10.04, Fedora 15). Nobody will want to include a fork, since PSCNV does not support older hardware distributions would even have to deliver Nouveau AND the fork, and make sure they don't block each other.

Comment

looks like radeonhd not taught them that incompatible user-alienating ununified community-dividing graphic driver forks are shortliving, useless and disrupting.
gallium maybe not a saviour of all humanity but it's a way most developers and users want things done, and in current state of nouveau, fork is the last thing it needs :\

it also looks like they just want not to have troubles porting GNU/Linux driver awesomeness on those other OS's and reinventing bicycle again. of course they will not have skill or resources to do it single-handedly and no one going to help them. good fucking luck.

Comment

I'm sure that they're not stupid, and that 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.

Comment

I'm sure that they're not stupid, and that 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.

Indeed, well, reimplementing a new memory manager isn't so much of a problem as the GEM interface is still being used.

We are not forking everything, only the kernel side (and most of the code remains shared). The ddx is left (almost) untouched (there is a one-line patch) that can eventually get merged in the mainline ddx.

The point of all that is to get GPGPU on nvidia cards (TTM is incompatible with GPGPU without some modifications as it assumes you can safely move the buffers. Of course, you wouldn't expect your pointers to move in your standard C code.) and to increase performance (on some selected 2D-tests I made, we were _up to 50% faster_ than the blob. There is still a lot of work to be done though.

I try to work for both Nouveau and pscnv and I can assure you both projects benefit from each others. The hard work is reverse engineering, and this work is still shared.
Come on guys, please have a look at HMPP (http://www.caps-entreprise.com/fr/pa...p?id=49&p_p=36) and get exited by it