Menu
▾
▴
mesa3d-dev
|
From: Jakob B. <wal...@gm...> - 2010-03-24 18:34:54
|
Hi all Can people please try out the gallium-targets branch I like to merge that as soon as possible. Also you will need to run autogen.sh if you switch to this branch. The branch moves all target like directories from the winsys directory into the targets directory this the dri/xorg/egl directories in src/gallium/winsys/drm/*/. It also reorganizes the winsys directory so that the first level says which winsys it exposes the second which type. Example: winsys/drm/radeon/core -> winsys/radeon/drm winsys/drm/radeon/dri -> targets/dri-radeong winsys/drm/radeon/egl -> targets/egl-radeon winsys/drm/radeon/xorg -> targets/xorg-radeon Bad things still left: winsys/i965/xlib should probably be split up into a target and winsys. winsys/g3dvl/* as well (tho this might be dead on the master branch). As far as I know things should not have regressed. Cheers Jakob. |
|
From: STEVE555 <ste...@ho...> - 2010-03-24 21:29:04
|
Hi Jakob,
I've tried out your gallium-targets branch with ./autogen.sh
and my configure options added to it.After a recompile and a re-boot,there
were no compile breakages and no real ill-affects after a re-boot.
I also tried out merging my copy of the Mesa master branch into my copy of
your gallium-targets branch.I used ./autogen.sh with my configure options
again,and there were no compile breakages and no ill-effects after a
re-compile and a re-boot.
I compile the nouveau drivers myself,so I can't speak for others who compile
mesa for their different hardware.
Regards,
STEVE555
Jakob Bornecrantz wrote:
>
> Hi all
>
> Can people please try out the gallium-targets branch I like to merge
> that as soon as possible.
>
> Also you will need to run autogen.sh if you switch to this branch.
>
> The branch moves all target like directories from the winsys directory
> into the targets directory this the dri/xorg/egl directories in
> src/gallium/winsys/drm/*/. It also reorganizes the winsys directory so
> that the first level says which winsys it exposes the second which
> type.
>
> Example:
> winsys/drm/radeon/core -> winsys/radeon/drm
> winsys/drm/radeon/dri -> targets/dri-radeong
> winsys/drm/radeon/egl -> targets/egl-radeon
> winsys/drm/radeon/xorg -> targets/xorg-radeon
>
> Bad things still left:
> winsys/i965/xlib should probably be split up into a target and winsys.
> winsys/g3dvl/* as well (tho this might be dead on the master branch).
>
> As far as I know things should not have regressed.
>
> Cheers Jakob.
>
> ------------------------------------------------------------------------------
> 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/-RFC--gallium-targets-merge-tp28019425p28021629.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.
|
|
From: Jakob B. <wal...@gm...> - 2010-03-24 22:18:32
|
Thanks! Cheers Jakob. On Wed, Mar 24, 2010 at 9:28 PM, STEVE555 <ste...@ho...> wrote: > > Hi Jakob, > I've tried out your gallium-targets branch with ./autogen.sh > and my configure options added to it.After a recompile and a re-boot,there > were no compile breakages and no real ill-affects after a re-boot. > > I also tried out merging my copy of the Mesa master branch into my copy of > your gallium-targets branch.I used ./autogen.sh with my configure options > again,and there were no compile breakages and no ill-effects after a > re-compile and a re-boot. > > I compile the nouveau drivers myself,so I can't speak for others who compile > mesa for their different hardware. > Regards, > STEVE555 > > Jakob Bornecrantz wrote: >> >> Hi all >> >> Can people please try out the gallium-targets branch I like to merge >> that as soon as possible. >> >> Also you will need to run autogen.sh if you switch to this branch. >> >> The branch moves all target like directories from the winsys directory >> into the targets directory this the dri/xorg/egl directories in >> src/gallium/winsys/drm/*/. It also reorganizes the winsys directory so >> that the first level says which winsys it exposes the second which >> type. >> >> Example: >> winsys/drm/radeon/core -> winsys/radeon/drm >> winsys/drm/radeon/dri -> targets/dri-radeong >> winsys/drm/radeon/egl -> targets/egl-radeon >> winsys/drm/radeon/xorg -> targets/xorg-radeon >> >> Bad things still left: >> winsys/i965/xlib should probably be split up into a target and winsys. >> winsys/g3dvl/* as well (tho this might be dead on the master branch). >> >> As far as I know things should not have regressed. >> >> Cheers Jakob. >> >> ------------------------------------------------------------------------------ >> 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/-RFC--gallium-targets-merge-tp28019425p28021629.html > Sent from the mesa3d-dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > 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: Jakob B. <wal...@gm...> - 2010-03-25 14:06:37
|
Hi I since this was not a interface change and I think I got a large enough test sample from various people I have merged the branch to master. I confirmed that the following builds are working; configure with all drivers, configure default, make linux-debug, scons with dri=yes, scons with dri=no. Cheers Jakob. |
|
From: Xavier C. <cha...@gm...> - 2010-03-25 17:30:39
|
I've been using the configure line from nouveau wiki for a while now : http://nouveau.freedesktop.org/wiki/GalliumHowto ./configure --enable-debug --enable-glx-tls --disable-asm --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests Gallium: yes Gallium dirs: auxiliary drivers state_trackers Target dirs: dri-nouveau egl-nouveau dri-swrast egl-swrast Winsys dirs: sw sw/xlib sw/dri sw/drm nouveau/drm Driver dirs: softpipe failover trace identity nouveau nvfx nv50 Trackers dirs: glx dri Shared libs: yes Static libs: no EGL: glx dri2 GLU: yes GLw: yes (Motif: no) glut: yes Demos: no This setup broke after that last merge I think : make[3]: Entering directory `/home/xavier/app/mesa/src/gallium/targets/egl-nouveau' gcc -c -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -g -fPIC -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o make[3]: *** No rule to make target `../../../../src/gallium/state_trackers/egl/libeglx11.a', needed by `egl_x11_nouveau.so'. Stop. It seems egl is enabled by default, but manually specifying state-trackers without egl disables egl state tracker, and build fails. I am not sure why it worked before. I don't know if configure.ac should handle the above configure line somehow, either reporting it as invalid or enabling egl state tracker anyway. On Thu, Mar 25, 2010 at 3:06 PM, Jakob Bornecrantz <wal...@gm...> wrote: > Hi > > I since this was not a interface change and I think I got a large > enough test sample from various people I have merged the branch to > master. I confirmed that the following builds are working; configure > with all drivers, configure default, make linux-debug, scons with > dri=yes, scons with dri=no. > > Cheers Jakob. > > ------------------------------------------------------------------------------ > 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: Jakob B. <wal...@gm...> - 2010-03-25 17:35:43
|
On Thu, Mar 25, 2010 at 5:30 PM, Xavier Chantry <cha...@gm...> wrote: > I've been using the configure line from nouveau wiki for a while now : > http://nouveau.freedesktop.org/wiki/GalliumHowto > > ./configure --enable-debug --enable-glx-tls --disable-asm > --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel > --disable-gallium-radeon --disable-gallium-svga > --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests > > Gallium: yes > Gallium dirs: auxiliary drivers state_trackers > Target dirs: dri-nouveau egl-nouveau dri-swrast egl-swrast > Winsys dirs: sw sw/xlib sw/dri sw/drm nouveau/drm > Driver dirs: softpipe failover trace identity nouveau nvfx nv50 > Trackers dirs: glx dri > > Shared libs: yes > Static libs: no > EGL: glx dri2 > GLU: yes > GLw: yes (Motif: no) > glut: yes > Demos: no > > This setup broke after that last merge I think : > > make[3]: Entering directory > `/home/xavier/app/mesa/src/gallium/targets/egl-nouveau' > gcc -c -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math > -fvisibility=hidden -fno-strict-aliasing -g -fPIC -D_GNU_SOURCE > -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS > -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING > -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -D_GNU_SOURCE -DPTHREADS -DDEBUG > -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS > -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING > -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o > make[3]: *** No rule to make target > `../../../../src/gallium/state_trackers/egl/libeglx11.a', needed by > `egl_x11_nouveau.so'. Stop. > > It seems egl is enabled by default, but manually specifying > state-trackers without egl disables egl state tracker, and build > fails. > I am not sure why it worked before. > > I don't know if configure.ac should handle the above configure line > somehow, either reporting it as invalid or enabling egl state tracker > anyway. Thanks for testing... Hmm I currently only checking for if the --enable-egl switch has been thrown when selecting so if you throw in --disable-egl in there it should work again. I'll look into it. Cheers Jakob. |
|
From: Xavier C. <cha...@gm...> - 2010-03-25 19:06:50
|
On Thu, Mar 25, 2010 at 6:35 PM, Jakob Bornecrantz <wal...@gm...> wrote: > > Thanks for testing... > > Hmm I currently only checking for if the --enable-egl switch has been > thrown when selecting so if you throw in --disable-egl in there it > should work again. I'll look into it. > Interestingly enough, the drisw work that happened right after the merge fails in the same way. Anyway, I already have two working options : 1) add egl and drisw to --with-state-trackers=glx,dri 2) add --disable-egl --enable-gallium-swrast=no The handling of with_state_trackers option does not seem optimal : - yes case : mesa_driver=dri -> glx state tracker mesa_driver=xlib -> dri state tracker so there is apparently no way to get both glx and dri - * case : does not check whether egl state tracker is enabled when egl is enabled does not check whether drisw state tracker is enabled when drisw is enabled But there is nothing inherently broken. So we can just assume the user is not stupid and will select configure options that are consistent. I will just go with 2), and possibly update nouveau wiki accordingly. |
|
From: Jakob B. <wal...@gm...> - 2010-03-25 19:33:01
|
On Thu, Mar 25, 2010 at 7:06 PM, Xavier Chantry <cha...@gm...> wrote: > On Thu, Mar 25, 2010 at 6:35 PM, Jakob Bornecrantz <wal...@gm...> wrote: >> >> Thanks for testing... >> >> Hmm I currently only checking for if the --enable-egl switch has been >> thrown when selecting so if you throw in --disable-egl in there it >> should work again. I'll look into it. >> > > Interestingly enough, the drisw work that happened right after the > merge fails in the same way. > > Anyway, I already have two working options : > 1) add egl and drisw to --with-state-trackers=glx,dri > 2) add --disable-egl --enable-gallium-swrast=no > > The handling of with_state_trackers option does not seem optimal : > - yes case : > mesa_driver=dri -> glx state tracker > mesa_driver=xlib -> dri state tracker > > so there is apparently no way to get both glx and dri > > - * case : > does not check whether egl state tracker is enabled when egl is enabled > does not check whether drisw state tracker is enabled when drisw is enabled > > > But there is nothing inherently broken. So we can just assume the user > is not stupid and will select configure options that are consistent. > I will just go with 2), and possibly update nouveau wiki accordingly. > Thanks again for testing. Okay, this could be solved by just checking if the state trackers are built where we enable the the targets instead of the subsystem or driver. The xorg drivers is the only one doing this correctly, by checking HAVE_XORG. I'll get to that later today. Cheers Jakob. |
|
From: Xavier C. <cha...@gm...> - 2010-03-26 09:57:50
|
On Thu, Mar 25, 2010 at 8:32 PM, Jakob Bornecrantz <wal...@gm...> wrote: > > Thanks again for testing. > > Okay, this could be solved by just checking if the state trackers are > built where we enable the the targets instead of the subsystem or > driver. The xorg drivers is the only one doing this correctly, by > checking HAVE_XORG. > > I'll get to that later today. > It's perfect now, thanks. And I like the refactoring and better consistency. STEVE555 reported a build failure in another thread with svga, it seems to just be a small typo. |
|
From: Jakob B. <wal...@gm...> - 2010-03-26 10:51:19
|
On Fri, Mar 26, 2010 at 9:57 AM, Xavier Chantry <cha...@gm...> wrote: > On Thu, Mar 25, 2010 at 8:32 PM, Jakob Bornecrantz <wal...@gm...> wrote: >> >> Thanks again for testing. >> >> Okay, this could be solved by just checking if the state trackers are >> built where we enable the the targets instead of the subsystem or >> driver. The xorg drivers is the only one doing this correctly, by >> checking HAVE_XORG. >> >> I'll get to that later today. >> > > It's perfect now, thanks. And I like the refactoring and better consistency. > > STEVE555 reported a build failure in another thread with svga, it > seems to just be a small typo. > Thanks, have pushed a fix. Cheers Jakob. |
×
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