Menu
▾
▴
mesa3d-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(10) |
Apr
(28) |
May
(41) |
Jun
(91) |
Jul
(63) |
Aug
(45) |
Sep
(37) |
Oct
(80) |
Nov
(91) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(48) |
Feb
(121) |
Mar
(126) |
Apr
(16) |
May
(85) |
Jun
(84) |
Jul
(115) |
Aug
(71) |
Sep
(27) |
Oct
(33) |
Nov
(15) |
Dec
(71) |
| 2002 |
Jan
(73) |
Feb
(34) |
Mar
(39) |
Apr
(135) |
May
(59) |
Jun
(116) |
Jul
(93) |
Aug
(40) |
Sep
(50) |
Oct
(87) |
Nov
(90) |
Dec
(32) |
| 2003 |
Jan
(181) |
Feb
(101) |
Mar
(231) |
Apr
(240) |
May
(148) |
Jun
(228) |
Jul
(156) |
Aug
(49) |
Sep
(173) |
Oct
(169) |
Nov
(137) |
Dec
(163) |
| 2004 |
Jan
(243) |
Feb
(141) |
Mar
(183) |
Apr
(364) |
May
(369) |
Jun
(251) |
Jul
(194) |
Aug
(140) |
Sep
(154) |
Oct
(167) |
Nov
(86) |
Dec
(109) |
| 2005 |
Jan
(176) |
Feb
(140) |
Mar
(112) |
Apr
(158) |
May
(140) |
Jun
(201) |
Jul
(123) |
Aug
(196) |
Sep
(143) |
Oct
(165) |
Nov
(158) |
Dec
(79) |
| 2006 |
Jan
(90) |
Feb
(156) |
Mar
(125) |
Apr
(146) |
May
(169) |
Jun
(146) |
Jul
(150) |
Aug
(176) |
Sep
(156) |
Oct
(237) |
Nov
(179) |
Dec
(140) |
| 2007 |
Jan
(144) |
Feb
(116) |
Mar
(261) |
Apr
(279) |
May
(222) |
Jun
(103) |
Jul
(237) |
Aug
(191) |
Sep
(113) |
Oct
(129) |
Nov
(141) |
Dec
(165) |
| 2008 |
Jan
(152) |
Feb
(195) |
Mar
(242) |
Apr
(146) |
May
(151) |
Jun
(172) |
Jul
(123) |
Aug
(195) |
Sep
(195) |
Oct
(138) |
Nov
(183) |
Dec
(125) |
| 2009 |
Jan
(268) |
Feb
(281) |
Mar
(295) |
Apr
(293) |
May
(273) |
Jun
(265) |
Jul
(406) |
Aug
(679) |
Sep
(434) |
Oct
(357) |
Nov
(306) |
Dec
(478) |
| 2010 |
Jan
(856) |
Feb
(668) |
Mar
(927) |
Apr
(269) |
May
(12) |
Jun
(13) |
Jul
(6) |
Aug
(8) |
Sep
(23) |
Oct
(4) |
Nov
(8) |
Dec
(11) |
| 2011 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sedat D. <sed...@go...> - 2010-03-21 09:19:27
|
Hi Chia-I (hope this is the first name), >I've merged the branch. All Gallium DRI drivers now use st_api.h >instead of st_public.h. If you notice any regression due the merge, >please let me know so that I can work on it. The last days I have tested your gallium-st-api-dri GIT branch by merging into mesa master GIT. I was testing here with r300g st/dri on an RV515 radeon gfxcard. So, here is my positive feedback: Works here, lovely. Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps (master GIT incl. gallium-st-api-dri merge) $ cat oa_benchmark.txt sd@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 2>&1 | egrep -e '[0-9]+ frames' 840 frames 26.3 seconds 31.9 fps 9.0/31.3/90.0/9.9 ms Thanks for your work! -- Sedat |
|
From: Chia-I Wu <ol...@gm...> - 2010-03-21 08:49:21
|
Hi all,
On Thu, Mar 18, 2010 at 10:11:12AM +0800, Chia-I Wu wrote:
> I've created a new branch, gallium-st-api-dri, that switches st/dri from
> st_public.h to st_api.h. The branch starts with four commits that move DRI1
> support to a new file, followed by 2 commits to switch st/dri to st_api.h.
> My laptop has Intel 945GM so I can only test i915g. I've done some basic tests
> with progs/{demos,xdemos} and they seem to work fine. The red/blue channels of
> the demos are swapped. But I suspect it is a bug in the pipe driver since I
> observe the same issue on master branch.
> Only the DRI2 path is tested. I couldn't figure out how to disable DRI2 and
> enable DRI1 in my xserver. It would be great if someone can tell me how to do
> that with Intel DDX.
> The changes are bigger than I expected. It would be great to get some
> feedbacks before merging. If everthing works fine, the current plan is to
> merge it over the weekend.
I've merged the branch. All Gallium DRI drivers now use st_api.h
instead of st_public.h. If you notice any regression due the merge,
please let me know so that I can work on it.
--
ol...@Lu...
|
|
From: Sedat D. <sed...@go...> - 2010-03-21 06:49:37
|
Hi Dave, mesa master GIT world seems to be OK in OpenArena land, now. commit 162bc831c93bf8632b25c11f116a1405b93a1704 Author: Marek Olšák <ma...@gm...> r300g: align misaligned ushort vertex indices Thanks for fixing the issue(s). -- Sedat On Sat, Mar 20, 2010 at 10:02 PM, Dave Airlie <ai...@gm...> wrote: > On Sat, Mar 20, 2010 at 4:18 AM, Sedat Dilek <sed...@go...> wrote: >> Hi Marek - "you are nominated for the next DRIgeller (Uri Geller)" :-) >> >> concerning my problems r300g dri/st with mesa master GIT: >> >> THE BAD: >> commit 68e58a96e80865878e6881dc4d34fcc3ec24eb19 >> Author: Dave Airlie <ai...@re...> >> r300g: rebuild screen/winsys interface > > Please retest with master, I've just pushed some fixes for piglit > regressions hopefully will fix other issues. > > Dave. > |
|
From: Chia-I Wu <ol...@gm...> - 2010-03-21 03:16:14
|
On Fri, Mar 19, 2010 at 09:57:41PM +0200, George Sapountzis wrote: > The timing of the first attempt was unfortunate because it was in the > middle of a re-factoring I had not realized it was happening. The good > thing is that after the changes by Chia-I and Keith, implementing > swrastg_dri.so is much simpler. I update the patches at the above > branch, gallium swrast_dri.so works now with the following caveats: > * stride: the driver and the loader compute the stride independently. > They usually agree, but when you start resizing and they finally > don't, you get a regular oblique image. If you run with valgrind, you > also get a regular message the size of the mismatch, at each PutImage. > * fences: i did not use any, are they needed for cell/llvmpipe ? Nice work. I haven't tried this, but I think there should be DRM_CREATE_DRISW and drisw_api.h, similar to how DRI1 is supported, and let winsys/drm decide which version to support. swrast will be the only one to support DRM_CREATE_DRISW. This will also give st/dri a chance to define whatever needed to swrast to implement displaytarget_display in drisw_api.h, both at drm_api::create_screen time and pipe_screen::flush_frontbuffer time. drisw_st_framebuffer_flush_front will then only prepare a pipe_surface for the given attachment and call pipe_screen::flush_frontbuffer. Similar to what st/glx is doing. This may also solve the resize issue. If it is feasible, I think it is better to have st/dri support all three of DRI1/DRI2/DRISW at the same time when drm.h is available; And have st/dri support only DRISW when drm.h is not available. This will eliminate the need for st/drisw. > There are some patches (mostly one-liners) at the start of the branch > on other code, please take a look and object. -- ol...@Lu... |
|
From: <bug...@fr...> - 2010-03-20 21:52:41
|
http://bugs.freedesktop.org/show_bug.cgi?id=27216 Summary: Assignment with a function call in an if statement causes an assertion failure Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mes...@li... ReportedBy: ne...@li... This GLSL fragment shader causes an assertion failure from Mesa: void main () { float thing; if ((thing = sqrt (5.0)) > 1.0) gl_FragColor = vec4 (1.0, 0.0, 0.0, 1.0); } The assertion is "assert(index >= 0);" in storage_to_src_reg in slang_emit.c Taking away the assignment or the function call avoids the problem. As does moving the expression to outside the if condition. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Dave A. <ai...@gm...> - 2010-03-20 21:02:43
|
On Sat, Mar 20, 2010 at 4:18 AM, Sedat Dilek <sed...@go...> wrote: > Hi Marek - "you are nominated for the next DRIgeller (Uri Geller)" :-) > > concerning my problems r300g dri/st with mesa master GIT: > > THE BAD: > commit 68e58a96e80865878e6881dc4d34fcc3ec24eb19 > Author: Dave Airlie <ai...@re...> > r300g: rebuild screen/winsys interface Please retest with master, I've just pushed some fixes for piglit regressions hopefully will fix other issues. Dave. |
|
From: Dan N. <dbn...@gm...> - 2010-03-20 17:54:05
|
On Sat, Mar 20, 2010 at 8:06 AM, Sedat Dilek <sed...@go...> wrote: > Fixes here the problem described in [1] with mesa 7.8 GIT branch. > > - Sedat - > > [1] http://marc.info/?l=mesa3d-dev&m=126909519809790&w=2 But we want to link the demos against the libGL in the build tree, not the one on the host (if there even is one on the host). I think this is a different problem. -- Dan |
|
From: <bug...@fr...> - 2010-03-20 16:51:18
|
http://bugs.freedesktop.org/show_bug.cgi?id=27150 Sedat Dilek <sed...@gm...> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sed...@gm... --- Comment #5 from Sedat Dilek <sed...@gm...> 2010-03-20 09:51:10 PST --- Here on i386 Debian/sid this requires an additional fix from mesa 7.8 GIT [1]: commit 6fed3a9fa0a87ae797f995de5b51eb9be3493fe0 "glapi: Fix aliases to non-static functions." See also thread at mesa3d-dev ML [2]: mesa 7.8 GIT: Broken by "glapi: Correctly generate static disatches for X86." - Sedat - [1] http://cgit.freedesktop.org/mesa/mesa/commit/?h=7.8&id=6fed3a9fa0a87ae797f995de5b51eb9be3493fe0 [2] http://marc.info/?t=126909319800003&r=1&w=2 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Brian P. <bri...@gm...> - 2010-03-20 16:34:55
|
On Fri, Mar 19, 2010 at 6:11 PM, Sven Arvidsson <sa...@wh...> wrote: > Hi, > > The documentation on mesa3d.org doesn't seem to be up to date; at least > shading.html does not mention the MESA_GLSL env variable. Thanks for the tip. I've updated the website page. -Brian |
|
From: Sedat D. <sed...@go...> - 2010-03-20 16:30:44
|
[Only for documenting the build-error] $ cd ~/src/mesa/mesa/progs/xdemos/ $ undefref="glBlitFramebufferEXT glDeleteVertexArraysAPPLE glIsVertexArrayAPPLE glBlendEquationSeparateEXT" GOOD: $ for i in $undefref ; do objdump -x ../../lib/libGL.so | grep $i ; done 0001b000 l F .text 000000a0 __indirect_glBlitFramebufferEXT 0001b570 l F .text 00000058 __indirect_glBlendEquationSeparateEXT BAD: $ for i in $undefref ; do objdump -x ../../lib/libGL.so | grep $i ; done 0001b000 l F .text 000000a0 __indirect_glBlitFramebufferEXT 00000000 *UND* 00000000 glBlitFramebufferEXT 00000000 *UND* 00000000 glDeleteVertexArraysAPPLE 00000000 *UND* 00000000 glIsVertexArrayAPPLE 0001b570 l F .text 00000058 __indirect_glBlendEquationSeparateEXT 00000000 *UND* 00000000 glBlendEquationSeparateEXT - Sedat - On Sat, Mar 20, 2010 at 5:11 PM, Chia-I Wu <ol...@lu...> wrote: > On Sat, Mar 20, 2010 at 9:51 PM, Sedat Dilek <sed...@go...> wrote: >> while upgrading my mesa from 7.8 GIT branch, I saw with >> commit 41a87a43e11c664935349f938022d58d3e22da4e >> "glapi: Correctly generate static disatches for X86." >> the build breaking (especially with xdemos). > Sorry for introducing the build error. I've committed a fix to it. Can you > git pull again and see if it works for you too? > > -- > ol...@Lu... > |
|
From: Sedat D. <sed...@go...> - 2010-03-20 16:23:05
|
Real fix is this one: commit 6fed3a9fa0a87ae797f995de5b51eb9be3493fe0 "glapi: Fix aliases to non-static functions." - Sedat - On Sat, Mar 20, 2010 at 4:06 PM, Sedat Dilek <sed...@go...> wrote: > Fixes here the problem described in [1] with mesa 7.8 GIT branch. > > - Sedat - > > [1] http://marc.info/?l=mesa3d-dev&m=126909519809790&w=2 > |
|
From: Sedat D. <sed...@go...> - 2010-03-20 16:21:10
|
commit 6fed3a9fa0a87ae797f995de5b51eb9be3493fe0 "glapi: Fix aliases to non-static functions." ...fixes here the issues. THX for the quick fix. - Sedat - On Sat, Mar 20, 2010 at 5:11 PM, Chia-I Wu <ol...@lu...> wrote: > On Sat, Mar 20, 2010 at 9:51 PM, Sedat Dilek <sed...@go...> wrote: >> while upgrading my mesa from 7.8 GIT branch, I saw with >> commit 41a87a43e11c664935349f938022d58d3e22da4e >> "glapi: Correctly generate static disatches for X86." >> the build breaking (especially with xdemos). > Sorry for introducing the build error. I've committed a fix to it. Can you > git pull again and see if it works for you too? > > -- > ol...@Lu... > |
|
From: Chia-I Wu <ol...@lu...> - 2010-03-20 16:11:47
|
On Sat, Mar 20, 2010 at 9:51 PM, Sedat Dilek <sed...@go...> wrote: > while upgrading my mesa from 7.8 GIT branch, I saw with > commit 41a87a43e11c664935349f938022d58d3e22da4e > "glapi: Correctly generate static disatches for X86." > the build breaking (especially with xdemos). Sorry for introducing the build error. I've committed a fix to it. Can you git pull again and see if it works for you too? -- ol...@Lu... |
|
From: Sedat D. <sed...@go...> - 2010-03-20 15:06:32
|
Fixes here the problem described in [1] with mesa 7.8 GIT branch. - Sedat - [1] http://marc.info/?l=mesa3d-dev&m=126909519809790&w=2 |
|
From: Sedat D. <sed...@go...> - 2010-03-20 14:26:21
|
Hmm, strange... $ cd ~/src/mesa/mesa/progs/xdemos/ $ gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -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 corender.o ipc.o -L../../lib -lGL -L/usr/lib -lm -lX11 -lpthread -o corender ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' collect2: ld returned 1 exit status $ undefref="glBlitFramebufferEXT glDeleteVertexArraysAPPLE glIsVertexArrayAPPLE glBlendEquationSeparateEXT" $ for i in $undefref ; do objdump -x ../../lib/libGL.so | grep $i ; done 0001b000 l F .text 000000a0 __indirect_glBlitFramebufferEXT 00000000 *UND* 00000000 glBlitFramebufferEXT 00000000 *UND* 00000000 glDeleteVertexArraysAPPLE 00000000 *UND* 00000000 glIsVertexArrayAPPLE 0001b570 l F .text 00000058 __indirect_glBlendEquationSeparateEXT 00000000 *UND* 00000000 glBlendEquationSeparateEXT - Sedat - On Sat, Mar 20, 2010 at 2:55 PM, Sedat Dilek <sed...@go...> wrote: > My autogen.sh line looks like this: > > $ ./autogen.sh --prefix=/usr --with-driver=dri > --with-dri-driverdir=/usr/lib/dri --with-dri-drivers=r300,swrast > --enable-gallium-radeon --with-state-trackers=dri,glx --enable-glx-tls > --enable-debug > > - Sedat - > > On Sat, Mar 20, 2010 at 2:51 PM, Sedat Dilek <sed...@go...> wrote: >> Hi, >> >> while upgrading my mesa from 7.8 GIT branch, I saw with >> >> commit 41a87a43e11c664935349f938022d58d3e22da4e >> "glapi: Correctly generate static disatches for X86." >> >> the build breaking (especially with xdemos). >> >> - Sedat - >> >> [build.log] >> .... >> ccache gcc -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 >> -ffast-math -fvisibility=hidden -fno-strict-aliasing -g -fPIC >> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM >> -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 >> glxdemo.c -L../../lib -lGL -L/usr/lib -lm -lX11 -lpthread -o glxdemo >> ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' >> ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' >> ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' >> ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' >> collect2: ld returned 1 exit status >> make[2]: *** [glsync] Error 1 >> make[2]: *** Waiting for unfinished jobs.... >> ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' >> >> ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' >> ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' >> ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' >> collect2: ld returned 1 exit status >> make[2]: *** [glxdemo] Error 1 >> ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' >> ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' >> ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' >> ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' >> collect2: ld returned 1 exit status >> make[2]: *** [glthreads] Error 1 >> make[2]: Leaving directory `/home/sd/src/mesa/mesa/progs/xdemos' >> make[1]: *** [subdirs] Error 1 >> make[1]: Leaving directory `/home/sd/src/mesa/mesa/progs' >> make: *** [default] Error 1 >> > |
|
From: Sedat D. <sed...@go...> - 2010-03-20 13:55:20
|
My autogen.sh line looks like this: $ ./autogen.sh --prefix=/usr --with-driver=dri --with-dri-driverdir=/usr/lib/dri --with-dri-drivers=r300,swrast --enable-gallium-radeon --with-state-trackers=dri,glx --enable-glx-tls --enable-debug - Sedat - On Sat, Mar 20, 2010 at 2:51 PM, Sedat Dilek <sed...@go...> wrote: > Hi, > > while upgrading my mesa from 7.8 GIT branch, I saw with > > commit 41a87a43e11c664935349f938022d58d3e22da4e > "glapi: Correctly generate static disatches for X86." > > the build breaking (especially with xdemos). > > - Sedat - > > [build.log] > .... > ccache gcc -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 > -ffast-math -fvisibility=hidden -fno-strict-aliasing -g -fPIC > -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM > -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 > glxdemo.c -L../../lib -lGL -L/usr/lib -lm -lX11 -lpthread -o glxdemo > ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' > ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' > ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' > ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' > collect2: ld returned 1 exit status > make[2]: *** [glsync] Error 1 > make[2]: *** Waiting for unfinished jobs.... > ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' > > ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' > ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' > ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' > collect2: ld returned 1 exit status > make[2]: *** [glxdemo] Error 1 > ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' > ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' > ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' > ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' > collect2: ld returned 1 exit status > make[2]: *** [glthreads] Error 1 > make[2]: Leaving directory `/home/sd/src/mesa/mesa/progs/xdemos' > make[1]: *** [subdirs] Error 1 > make[1]: Leaving directory `/home/sd/src/mesa/mesa/progs' > make: *** [default] Error 1 > |
|
From: Sedat D. <sed...@go...> - 2010-03-20 13:51:51
|
Hi, while upgrading my mesa from 7.8 GIT branch, I saw with commit 41a87a43e11c664935349f938022d58d3e22da4e "glapi: Correctly generate static disatches for X86." the build breaking (especially with xdemos). - Sedat - [build.log] .... ccache gcc -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -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 glxdemo.c -L../../lib -lGL -L/usr/lib -lm -lX11 -lpthread -o glxdemo ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' collect2: ld returned 1 exit status make[2]: *** [glsync] Error 1 make[2]: *** Waiting for unfinished jobs.... ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' collect2: ld returned 1 exit status make[2]: *** [glxdemo] Error 1 ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT' ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE' ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE' ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT' collect2: ld returned 1 exit status make[2]: *** [glthreads] Error 1 make[2]: Leaving directory `/home/sd/src/mesa/mesa/progs/xdemos' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/sd/src/mesa/mesa/progs' make: *** [default] Error 1 |
|
From: <bug...@fr...> - 2010-03-20 05:10:00
|
http://bugs.freedesktop.org/show_bug.cgi?id=27150 Chia-I Wu <ol...@gm...> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #4 from Chia-I Wu <ol...@gm...> 2010-03-19 22:09:52 PST --- Thanks. I've applied the patch to 7.8 branch and it will appear in next RC. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Octavio R. <oc...@gn...> - 2010-03-20 01:11:43
|
Nicolai Haehnle escribió: > because we want to > have the DRM in our codebase Why? -- __________________________________________________________ | , , | | / \ | | ((__-^^-,-^^-__)) Octavio Rossell Tabet | | `-_---' `---_-' oc...@gn... | | `--|o` 'o|--' http://octavio.gnu.org.ve | | \ ` / irc.radiognu.org #gnu | | .: :. | | :o_o: Huella: FC69 551B ECB9 62B0 D992 | | "-" BE57 B551 2497 C78B 870A | |__________________________________________________________| |
|
From: Sven A. <sa...@wh...> - 2010-03-20 01:03:05
|
Hi, The documentation on mesa3d.org doesn't seem to be up to date; at least shading.html does not mention the MESA_GLSL env variable. -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 |
|
From: Brian P. <bri...@gm...> - 2010-03-19 23:41:03
|
On Fri, Mar 19, 2010 at 4:17 PM, Xavier Chantry <cha...@gm...> wrote: > On Fri, Mar 19, 2010 at 10:39 PM, Dan Nicholson <dbn...@gm...> wrote: >> On Fri, Mar 19, 2010 at 2:19 PM, Luca Barbieri <lu...@lu...> wrote: >>>> Can we just put this program in the demos? Or at least just make it a >>>> separate target (make test-link)? It seems excessive to make this part >>>> of the default build path. >>> >>> The whole purpose is to run this as part of the standard build, so >>> that the build fails if any driver is unloadable, (i.e. a modification >>> to it was botched) and the tree hopefully doesn't get pushed to >>> master. >>> >>> You can test it separately by just running glxinfo/glxgears, obviously. >> >> For developers that makes a lot of sense, but I've never seen any >> other projects impose this type of thing on regular users. >> > > You should only count the projects that allow by default successful > build with undefined symbols (I have honestly no idea how common that > is). > This seems especially bad in mesa where there are many people working > on core parts affecting all drivers and who cannot test easily all the > drivers. At least a build failure to catch the obvious mistakes would > be nice, though that will clearly not solve everything. > > And I think it is as profitable to the user, who do not use / know > about LIBGL_DEBUG=verbose , and won't spot easily the dri failure and > the fallback to software rendering. I'm OK with this change. If it causes hardship for anyone it could easily be reverted and revisited. -Brian |
|
From: <bug...@fr...> - 2010-03-19 23:35:43
|
http://bugs.freedesktop.org/show_bug.cgi?id=24942 Corbin Simpson <Mos...@gm...> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Mos...@gm... Status|NEW |ASSIGNED Summary|r300g segfaults on rs690 |r300g: R300 Gallium SW TCL --- Comment #1 from Corbin Simpson <Mos...@gm...> 2010-03-19 16:35:30 PST --- Formally accepting. This bug will be closed when SW TCL runs again on r300g. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Xavier C. <cha...@gm...> - 2010-03-19 22:48:10
|
This just changes the error message printed with LIBGL_DEBUG when loading
dri2 driver fails. It makes it more informative, more consistent with second
fallback swrast->indirect , and possibly more consistent with old dri1
behavior.
OLD:
libGL error: dlopen foo/nouveau_dri.so failed (foo/nouveau_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: dlopen foo/swrast_dri.so failed (foo/swrast_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: swrast_dri.so
libGL error: reverting to indirect rendering
NEW:
libGL error: dlopen foo/nouveau_dri.so failed (foo/nouveau_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: nouveau_dri.so
libGL error: reverting to software direct rendering
libGL error: dlopen foo/swrast_dri.so failed (foo/swrast_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: swrast_dri.so
libGL error: reverting to indirect rendering
Signed-off-by: Xavier Chantry <cha...@gm...>
---
src/glx/dri2_glx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 5b0f335..903c8c9 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -527,7 +527,6 @@ dri2CreateScreen(__GLXscreenConfigs * psc, int screen,
psc->driver = driOpenDriver(driverName);
if (psc->driver == NULL) {
- ErrorMessageF("driver pointer missing\n");
goto handle_error;
}
@@ -633,6 +632,7 @@ handle_error:
/* FIXME: clean up here */
+ ErrorMessageF("reverting to software direct rendering\n");
return NULL;
}
--
1.7.0.2
|
|
From: Xavier C. <cha...@gm...> - 2010-03-19 22:42:43
|
To quote Dan Nicholson : "In fact, when I wrote configure.ac originally, I wanted it to be a hard requirement and assumed that AC_PATH_PROG would error by default if it didn't find the program." I have been updating and building mesa a few times per week. More often than not, this just resulted in segfault at runtime, and I had to make clean and do a full build again. This was simply because I did not have makedepend installed, and parts of the tree were not rebuilt when they should. Signed-off-by: Xavier Chantry <cha...@gm...> --- configure.ac | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 0f51097..2ddfd14 100644 --- a/configure.ac +++ b/configure.ac @@ -30,8 +30,11 @@ AC_PROG_CPP AC_PROG_CC AC_PROG_CXX AC_CHECK_PROGS([MAKE], [gmake make]) -AC_PATH_PROG([MKDEP], [makedepend]) AC_PATH_PROG([SED], [sed]) +AC_PATH_PROG([MKDEP], [makedepend], no) +if test "x$MKDEP" = xno; then + AC_MSG_ERROR([makedepend not found]) +fi dnl Our fallback install-sh is a symlink to minstall. Use the existing dnl configuration in that case. -- 1.7.0.2 |
|
From: Xavier C. <cha...@gm...> - 2010-03-19 22:17:38
|
On Fri, Mar 19, 2010 at 10:39 PM, Dan Nicholson <dbn...@gm...> wrote: > On Fri, Mar 19, 2010 at 2:19 PM, Luca Barbieri <lu...@lu...> wrote: >>> Can we just put this program in the demos? Or at least just make it a >>> separate target (make test-link)? It seems excessive to make this part >>> of the default build path. >> >> The whole purpose is to run this as part of the standard build, so >> that the build fails if any driver is unloadable, (i.e. a modification >> to it was botched) and the tree hopefully doesn't get pushed to >> master. >> >> You can test it separately by just running glxinfo/glxgears, obviously. > > For developers that makes a lot of sense, but I've never seen any > other projects impose this type of thing on regular users. > You should only count the projects that allow by default successful build with undefined symbols (I have honestly no idea how common that is). This seems especially bad in mesa where there are many people working on core parts affecting all drivers and who cannot test easily all the drivers. At least a build failure to catch the obvious mistakes would be nice, though that will clearly not solve everything. And I think it is as profitable to the user, who do not use / know about LIBGL_DEBUG=verbose , and won't spot easily the dri failure and the fallback to software rendering. |
102 messages has been excluded from this view by a project administrator.
