Menu
▾
▴
mesa3d-dev
|
From: Luca B. <lu...@lu...> - 2010-03-13 17:30:00
|
Currently the nv30 and nv40 Gallium drivers are very similar, and contain about 5000 lines of essentially duplicate code. I prepared a patchset (which can be found at http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) which gradually unifies the drivers, one file per the commit. A new "nvfx" directory is created, and unified files are put there one by one. After all patches are applied, the nv30 and nv40 directories are removed and the only the new nvfx directory remains. The first patches unify the engine naming (s/curie/eng3d/g; s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants. Initial versions of this work changed renouveau.xml to create a new "NVFXTCL" object, but the current version doesn't need any renouveau.xml modification at all. The "unification+fixes" branch referenced above is the one that should be tested. The "unification" branch contains just the unification, with no behavior changes, while "unification+fixes" also fixes swtnl and quad rendering, allowing to better test the unification. Some cleanups on top of the unfication are also included. That same repository also contains other branches with significant improvements on top of the unification, but I'm still not proposing them for inclusion as they need more testing and some fixes. While there are some branches in the Mesa repository that would conflict with this, such branches seem to be popping up continuously (and this is good!), so waiting until they are merged probably won't really work. The conflicts are minimal anyway and the driver fixes can be very easily reconstructed over the unified codebase. How about merging this? Any objections? Any comments? |
|
From: Keith W. <kei...@go...> - 2010-03-13 17:35:51
|
Sounds good to me - fewer driver directories to fix up after changes... Keith On Sat, Mar 13, 2010 at 5:29 PM, Luca Barbieri <lu...@lu...> wrote: > Currently the nv30 and nv40 Gallium drivers are very similar, and > contain about 5000 lines of essentially duplicate code. > > I prepared a patchset (which can be found at > http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) > which gradually unifies the drivers, one file per the commit. > > A new "nvfx" directory is created, and unified files are put there one by one. > After all patches are applied, the nv30 and nv40 directories are > removed and the only the new nvfx directory remains. > > The first patches unify the engine naming (s/curie/eng3d/g; > s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants. > Initial versions of this work changed renouveau.xml to create a new > "NVFXTCL" object, but the current version doesn't need any > renouveau.xml modification at all. > > The "unification+fixes" branch referenced above is the one that should > be tested. > The "unification" branch contains just the unification, with no > behavior changes, while "unification+fixes" also fixes swtnl and quad > rendering, allowing to better test the unification. Some cleanups on > top of the unfication are also included. > > That same repository also contains other branches with significant > improvements on top of the unification, but I'm still not proposing > them for inclusion as they need more testing and some fixes. > > While there are some branches in the Mesa repository that would > conflict with this, such branches seem to be popping up continuously > (and this is good!), so waiting until they are merged probably won't > really work. > > The conflicts are minimal anyway and the driver fixes can be very > easily reconstructed over the unified codebase. > > How about merging this? > Any objections? Any comments? > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Mesa3d-dev mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > |
|
From: STEVE555 <ste...@ho...> - 2010-03-14 14:28:06
|
Hi guys,
I came across this post and downloaded luca's version of Mesa
(mesa-lb) using:
git clone git://repo.or.cz/mesa/mesa-lb.git and then git checkout --track -b
unification+fixes+stable origin/unification+fixes+stable and switched to
that branch. I then for safety,I compiled and installed with:
./configure --prefix=/usr/local --enable-32-bit --enable-xcb
--enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es
--enable-motif --enable-gl-osmesa --disable-gallium-intel
--disable-gallium-radeon --with-expat=/usr/lib
--with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast
--enable-gallium-swrast --enable-gallium-svga --with-max-width=4096
--with-max-height=4096 --enable-debug
http://old.nabble.com/file/p27895301/glxinfo-error.txt glxinfo-error.txt
There were no compilation problems when I compiled Luca's version of Mesa.I
re-booted into my root account.I fired up Konsole and ran glxinfo for the
packaged version of Mesa for Fedora Rawhide,and that showed up fine.To see
Luca'a version,I used :
export LIBGL_DRIVERS_PATH=/usr/local/lib/dri and then glxinfo.I found a
strange error near the top:
Mesa: CPU name: AMD Athlon(tm) XP 3000+
Mesa warning: failed to remap index 390
Mesa warning: failed to remap index 391
Mesa warning: failed to remap index 392
Mesa warning: failed to remap index 398
Mesa warning: failed to remap index 399
I've attached a txt file with the full output.My graphics card is an Nvidia
NV40 (6,600 GT),and I also compile DRM the nouveau kernel modules and the
nouveau driver from git
I wanted to merge Lucsa' branch in to my copy of Mesa master to test it
out,but it would let me for some reason,any advice on that?
Regards,
STEVE555
Keith Whitwell-4 wrote:
>
> Sounds good to me - fewer driver directories to fix up after changes...
>
> Keith
>
> On Sat, Mar 13, 2010 at 5:29 PM, Luca Barbieri <lu...@lu...>
> wrote:
>> Currently the nv30 and nv40 Gallium drivers are very similar, and
>> contain about 5000 lines of essentially duplicate code.
>>
>> I prepared a patchset (which can be found at
>> http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes)
>> which gradually unifies the drivers, one file per the commit.
>>
>> A new "nvfx" directory is created, and unified files are put there one by
>> one.
>> After all patches are applied, the nv30 and nv40 directories are
>> removed and the only the new nvfx directory remains.
>>
>> The first patches unify the engine naming (s/curie/eng3d/g;
>> s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants.
>> Initial versions of this work changed renouveau.xml to create a new
>> "NVFXTCL" object, but the current version doesn't need any
>> renouveau.xml modification at all.
>>
>> The "unification+fixes" branch referenced above is the one that should
>> be tested.
>> The "unification" branch contains just the unification, with no
>> behavior changes, while "unification+fixes" also fixes swtnl and quad
>> rendering, allowing to better test the unification. Some cleanups on
>> top of the unfication are also included.
>>
>> That same repository also contains other branches with significant
>> improvements on top of the unification, but I'm still not proposing
>> them for inclusion as they need more testing and some fixes.
>>
>> While there are some branches in the Mesa repository that would
>> conflict with this, such branches seem to be popping up continuously
>> (and this is good!), so waiting until they are merged probably won't
>> really work.
>>
>> The conflicts are minimal anyway and the driver fixes can be very
>> easily reconstructed over the unified codebase.
>>
>> How about merging this?
>> Any objections? Any comments?
>>
>> ------------------------------------------------------------------------------
>> 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
>> _______________________________________________
>> Mesa3d-dev mailing list
>> Mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
--
View this message in context: http://old.nabble.com/-PATCH--nv30-nv40-Gallium-drivers-unification-tp27889377p27895301.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.
|
|
From: Luca B. <luc...@gm...> - 2010-03-14 19:25:59
|
Perhaps try running make clean and make if you haven't already? And perhaps make sure that the installed libGL.so and DRI drivers are build from the same codebase. The changes in my branch definitely shouldn't affect this. > I wanted to merge Lucsa' branch in to my copy of Mesa master to test it > out,but it would let me for some reason,any advice on that? What reason? git merge should work. |
|
From: Keith W. <kei...@go...> - 2010-03-14 23:12:21
|
On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell <kei...@go...> wrote: > Sounds good to me - fewer driver directories to fix up after changes... > It'd be good to get this merged sooner rather than later as I'll soon be starting on pipe_resources conversion for the nv drivers. Once I do that, there will be heaps of conflicts with your patches, but if I can merge them in before I do the conversion all will be well... Keith |
|
From: Xavier C. <cha...@gm...> - 2010-03-14 23:17:23
|
On Mon, Mar 15, 2010 at 12:12 AM, Keith Whitwell <kei...@go...> wrote: > On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell > <kei...@go...> wrote: >> Sounds good to me - fewer driver directories to fix up after changes... >> > > It'd be good to get this merged sooner rather than later as I'll soon > be starting on pipe_resources conversion for the nv drivers. Once I > do that, there will be heaps of conflicts with your patches, but if I > can merge them in before I do the conversion all will be well... > I tested unification+fixes branch on nv35 with 11 games that you can see on that page : http://nouveau.freedesktop.org/wiki/XavierChantry No regression to report compared to mesa master. A benefit worth mentioning is the SWTNL support which allows to run the 4 games currently broken with mesa master. |
|
From: STEVE555 <ste...@ho...> - 2010-03-14 23:45:25
|
Dear Luca,
I got your latest commits for your branch,did a make clean
instead of make -B realclean as I usaully do and did an autoreconf -iv,then
.autogen.sh with my configure options I mentioned earlier to ths thread.I
then ran make and make install instead of gmake and gmake install,and
rebooted.
When I did export LIBGL_DRIVERS_PATH=/usr/local/lib/dri(then return) and ran
glxinfo again,the error message appeared again.I then did a ldd
/usr/bin/glxinfo in terminal I exported on and it was showing that it was
pointing to libGL.so in /usr/lib.
So I exported LD_LIBRARY_PATH=/usr/local/lib in the same Konsole window and
ran glxinfo again.This time,the errors disappeared.I like to thank you for
your advice.
Regards,
STEVE555
Xavier Chantry-3 wrote:
>
> On Mon, Mar 15, 2010 at 12:12 AM, Keith Whitwell
> <kei...@go...> wrote:
>> On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell
>> <kei...@go...> wrote:
>>> Sounds good to me - fewer driver directories to fix up after changes...
>>>
>>
>> It'd be good to get this merged sooner rather than later as I'll soon
>> be starting on pipe_resources conversion for the nv drivers. Once I
>> do that, there will be heaps of conflicts with your patches, but if I
>> can merge them in before I do the conversion all will be well...
>>
>
> I tested unification+fixes branch on nv35 with 11 games that you can
> see on that page :
> http://nouveau.freedesktop.org/wiki/XavierChantry
>
> No regression to report compared to mesa master.
>
> A benefit worth mentioning is the SWTNL support which allows to run
> the 4 games currently broken with mesa master.
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
--
View this message in context: http://old.nabble.com/-PATCH--nv30-nv40-Gallium-drivers-unification-tp27889377p27899191.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.
|
|
From: Younes M. <you...@gm...> - 2010-03-15 05:22:48
|
On Sat, Mar 13, 2010 at 1:29 PM, Luca Barbieri <lu...@lu...> wrote: > Currently the nv30 and nv40 Gallium drivers are very similar, and > contain about 5000 lines of essentially duplicate code. > > I prepared a patchset (which can be found at > http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) > which gradually unifies the drivers, one file per the commit. > > A new "nvfx" directory is created, and unified files are put there one by one. > After all patches are applied, the nv30 and nv40 directories are > removed and the only the new nvfx directory remains. > > The first patches unify the engine naming (s/curie/eng3d/g; > s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants. > Initial versions of this work changed renouveau.xml to create a new > "NVFXTCL" object, but the current version doesn't need any > renouveau.xml modification at all. > > The "unification+fixes" branch referenced above is the one that should > be tested. > The "unification" branch contains just the unification, with no > behavior changes, while "unification+fixes" also fixes swtnl and quad > rendering, allowing to better test the unification. Some cleanups on > top of the unfication are also included. > > That same repository also contains other branches with significant > improvements on top of the unification, but I'm still not proposing > them for inclusion as they need more testing and some fixes. > > While there are some branches in the Mesa repository that would > conflict with this, such branches seem to be popping up continuously > (and this is good!), so waiting until they are merged probably won't > really work. > > The conflicts are minimal anyway and the driver fixes can be very > easily reconstructed over the unified codebase. > > How about merging this? > Any objections? Any comments? Pushed. Thanks. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X