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: Mike L. <mi...@fi...> - 2010-02-18 23:47:40
|
On 18 February 2010 22:58, Dan Nicholson <dbn...@gm...> wrote: > On Thu, Feb 18, 2010 at 2:52 PM, Mike Lothian <mi...@fi...> wrote: >> On 18 February 2010 22:46, Dan Nicholson <dbn...@gm...> wrote: >>> On Thu, Feb 18, 2010 at 2:36 PM, Mike Lothian <mi...@fi...> wrote: >>>> I'm experiencing 3 issues at the moment >>>> >>>> xorg-server master isn't compiling I get the error: >>>> >>>> ../doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. >>>> -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus >>>> -I../hw/xfree86/common -I../hw/xfree86/dri -I../mi >>>> -I../hw/xfree86/dri2 -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith >>>> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations >>>> -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 >>>> -Wold-style-definition -Wdeclaration-after-statement -D_BSD_SOURCE >>>> -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 >>>> -I/usr/includeMike 23:39:51 Possibly /pixman-1 -I../include -I../include -I../Xext >>>> -I../composite -I../damageext -I../xfixes -I../Xi -I../mi >>>> -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb >>>> -fvisibility=hidden -I/usr/include/drm -I/usr/include/drm >>>> -I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server >>>> -DGLX_USE_TLS -DPTHREADS -D__GLX_ALIGN64 -march=native -O2 -pipe -w >>>> -MT glxdri2.lo -MD -MP -MF .deps/glxdri2.Tpo -c -o glxdri2.lo >>>> glxdri2.c >>>> glxdri2.c: In function '__glXDRIdrawableSwapBuffers': >>>> glxdri2.c:221: error: '__DRI2flushExtension' has no member named >>>> 'flushInvalidate' >>>> >>>> mesa wont compile. I have no idea what's happening >>>> >>>> gmake[5]: Entering directory >>>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>>> running /usr/bin/makedepend >>>> gmake[5]: Leaving directory >>>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>>> gmake[5]: Entering directory >>>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>>> gmake[6]: Entering directory >>>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>>> x86_64-pc-linux-gnu-gcc -c -I. >>>> -I../../../../../src/mesa/drivers/dri/common -Iserver >>>> -I../../../../../include -I../../../../../src/mesa >>>> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri >>>> -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall >>>> -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden >>>> -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS >>>> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS >>>> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING >>>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS ../common/utils.c -o >>>> ../common/utils.o >>>> x86_64-pc-linux-gnu-gcc -c -I. >>>> -I../../../../../src/mesa/drivers/dri/common -Iserver >>>> -I../../../../../include -I../../../../../src/mesa >>>> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri >>>> -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall >>>> -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden >>>> -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS >>>> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS >>>> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING >>>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS swrast.c -o swrast.o >>>> x86_64-pc-linux-gnu-gcc -c -I. >>>> -I../../../../../src/mesa/drivers/dri/common -Iserver >>>> -I../../../../../include -I../../../../../src/mesa >>>> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri >>>> -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall >>>> -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden >>>> -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS >>>> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS >>>> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING >>>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS swrast_span.c -o swrast_span.o >>>> /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker >>>> 'x86_64-pc-linux-gnu-gcc' -ldflags '-Wl,-O1 -Wl,--hash-style=gnu >>>> -Wl,--as-needed' \ >>>> ../../common/driverfuncs.o ../common/utils.o swrast.o >>>> swrast_span.o ../../../../../src/mesa/libmesa.a \ >>>> -ldrm -lexpat -lm -lpthread -ldl >>>> mklib: Making Linux shared library: swrast_dri.so >>>> gmake[6]: *** [swrast_dri.so] Error 1 >>>> gmake[6]: Leaving directory >>>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>>> gmake[5]: *** [lib] Error 2 >>>> gmake[5]: Leaving directory >>>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>>> gmake[4]: *** [subdirs] Error 1 >>>> gmake[4]: Leaving directory >>>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri' >>>> gmake[3]: *** [default] Error 1 >>> >>> For this one, you should revert commit >>> d6f55492af3cb82b0113fe6beac0f3494b6e2956. trap and exit on ERR >>> shouldn't be used blindly since it's entirely possible there are >>> commands that safely fail in mklib. Not to mention that it's not >>> portable. >>> >>> -- >>> Dan >>> >> >> Thanks Dan >> >> Does any one have access to get this reverted on master? > > I just did it. Try again. > > -- > Dan > Thanks that fixed it |
|
From: Mike L. <mi...@fi...> - 2010-02-18 23:47:23
|
On 18 February 2010 23:19, Alexander Lam <lam...@gm...> wrote:
> On Thu, Feb 18, 2010 at 5:36 PM, Mike Lothian <mi...@fi...> wrote:
>> I'm experiencing 3 issues at the moment
> [snip]
>> And lastly the latest intel DRM code from drm-intel-next has the
>> following issue too:
>>
>> CC drivers/gpu/drm/i915/intel_display.o
>> drivers/gpu/drm/i915/intel_display.c: In function 'i9xx_update_wm':
>> drivers/gpu/drm/i915/intel_display.c:2778: error: 'IS_I915GM'
>> undeclared (first use in this function)
>> drivers/gpu/drm/i915/intel_display.c:2778: error: (Each undeclared
>> identifier is reported only once
>> drivers/gpu/drm/i915/intel_display.c:2778: error: for each function it
>> appears in.)
>> make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1
>>
>
> Apply this:
> Fixes 05b044d94f1309b48d62784d329842a2585d6421 rebase error.
> diff -puNr a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> --- a/drivers/gpu/drm/i915/intel_display.c 2010-02-18 18:14:11.287962137 -0500
> +++ b/drivers/gpu/drm/i915/intel_display.c 2010-02-18 18:13:51.336212730 -0500
> @@ -2775,7 +2775,7 @@ static void i9xx_update_wm(struct drm_de
> if (IS_I945G(dev) || IS_I945GM(dev)) {
> I915_WRITE(FW_BLC_SELF, I915_READ(FW_BLC_SELF)
> & ~FW_BLC_SELF_EN);
> - } else if (IS_I915GM) {
> + } else if (IS_I915GM(dev)) {
> I915_WRITE(INSTPM, I915_READ(INSTPM) & ~INSTPM_SELF_EN);
> }
> }
>
>
> --
> Alexander Lam
>
Thanks
|
|
From: Mike L. <mi...@fi...> - 2010-02-18 23:47:20
|
On 18 February 2010 23:11, Xavier Chantry <cha...@gm...> wrote: > On Thu, Feb 18, 2010 at 11:36 PM, Mike Lothian <mi...@fi...> wrote: >> I'm experiencing 3 issues at the moment >> >> xorg-server master isn't compiling I get the error: >> >> ../doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. >> -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus >> -I../hw/xfree86/common -I../hw/xfree86/dri -I../mi >> -I../hw/xfree86/dri2 -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith >> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations >> -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 >> -Wold-style-definition -Wdeclaration-after-statement -D_BSD_SOURCE >> -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 >> -I/usr/include/pixman-1 -I../include -I../include -I../Xext >> -I../composite -I../damageext -I../xfixes -I../Xi -I../mi >> -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb >> -fvisibility=hidden -I/usr/include/drm -I/usr/include/drm >> -I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server >> -DGLX_USE_TLS -DPTHREADS -D__GLX_ALIGN64 -march=native -O2 -pipe -w >> -MT glxdri2.lo -MD -MP -MF .deps/glxdri2.Tpo -c -o glxdri2.lo >> glxdri2.c >> glxdri2.c: In function '__glXDRIdrawableSwapBuffers': >> glxdri2.c:221: error: '__DRI2flushExtension' has no member named >> 'flushInvalidate' >> > > 21:09 < codin> jbarnes: glxdri2.c:221: error: ‘__DRI2flushExtension’ > has no member named ‘flushInvalidate’ > 21:09 < codin> ?! > 21:09 < jbarnes> codin: X master is broken > 21:10 < ickle> s/jbarnes/krh/ > 21:10 < jbarnes> you'll need krh's invalidate branch > 21:10 < jbarnes> codin: look for "DRI2 Invalidate series" on xorg-devel > 21:10 < codin> how do I do that ? > 21:10 < jbarnes> codin: or just "git pull > ssh://people.freedesktop.org/~krh/xserver dri2-invalidate" from your > xserver tree > 21:10 < ickle> notmuch search "DRI2 Invalidate series" > 21:19 < cworth> ickle: Thanks. I'll grab that patch. > 21:20 < codin> ickle, where do I look or that ? > 21:21 < ickle> codin: 20:10 < jbarnes> codin: or just "git pull > ssh://people.freedesktop.org/~krh/xserver dri2-invalidate" from > your xserver tree > 21:21 < codin> ickle, that one is asking for a password > 21:21 < ickle> git pull git://anongit.freedesktop.org/~krh/xserver > dri2-invalidate Any chance they could just be pushed to master or revert the offending commits > > And DRM build issue : > > 00:26 < jifli> Someone knows that the current drm-intel-next doesn't > build right? > 00:32 < jbarnes> anholt: build breakage due to the sr conflict resolution? > 00:32 < jbarnes> or something... > 00:32 < jifli> yeah that's right > 00:32 < anholt> eh, I'll get to it at some point. > 00:33 < jbarnes> I don't see why it's failing offhand > 00:33 < jifli> forgot (dev) after IS_I915GM > 00:33 < jifli> line 2778 in intel_display.c > 00:34 < jbarnes> oh I was looking at debugfs.c > 00:34 < jbarnes> yeah that's it > |
|
From: <bug...@fr...> - 2010-02-18 23:42:22
|
http://bugs.freedesktop.org/show_bug.cgi?id=26632 Jon TURNEY <jon...@dr...> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33390|0 |1 is obsolete| | --- Comment #8 from Jon TURNEY <jon...@dr...> 2010-02-18 15:42:15 PST --- Created an attachment (id=33404) --> (http://bugs.freedesktop.org/attachment.cgi?id=33404) Cygwin linkage fix patch (In reply to comment #5) > I think that the 3rd patch will result in multiply defined symbols in the > normal build since libmesa.a already contains the glsl libs. See line 32 of > src/mesa/Makefile. > > I think the cygwin code in mklib needs to use expand_archives() as the linux > target does. Yes, that patch is complete nonsense. Thanks for the clue as to what's going, updated patch attached. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Alexander L. <lam...@gm...> - 2010-02-18 23:19:32
|
On Thu, Feb 18, 2010 at 5:36 PM, Mike Lothian <mi...@fi...> wrote:
> I'm experiencing 3 issues at the moment
[snip]
> And lastly the latest intel DRM code from drm-intel-next has the
> following issue too:
>
> CC drivers/gpu/drm/i915/intel_display.o
> drivers/gpu/drm/i915/intel_display.c: In function 'i9xx_update_wm':
> drivers/gpu/drm/i915/intel_display.c:2778: error: 'IS_I915GM'
> undeclared (first use in this function)
> drivers/gpu/drm/i915/intel_display.c:2778: error: (Each undeclared
> identifier is reported only once
> drivers/gpu/drm/i915/intel_display.c:2778: error: for each function it
> appears in.)
> make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1
>
Apply this:
Fixes 05b044d94f1309b48d62784d329842a2585d6421 rebase error.
diff -puNr a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
--- a/drivers/gpu/drm/i915/intel_display.c 2010-02-18 18:14:11.287962137 -0500
+++ b/drivers/gpu/drm/i915/intel_display.c 2010-02-18 18:13:51.336212730 -0500
@@ -2775,7 +2775,7 @@ static void i9xx_update_wm(struct drm_de
if (IS_I945G(dev) || IS_I945GM(dev)) {
I915_WRITE(FW_BLC_SELF, I915_READ(FW_BLC_SELF)
& ~FW_BLC_SELF_EN);
- } else if (IS_I915GM) {
+ } else if (IS_I915GM(dev)) {
I915_WRITE(INSTPM, I915_READ(INSTPM) & ~INSTPM_SELF_EN);
}
}
--
Alexander Lam
|
|
From: Xavier C. <cha...@gm...> - 2010-02-18 23:12:09
|
On Thu, Feb 18, 2010 at 11:36 PM, Mike Lothian <mi...@fi...> wrote: > I'm experiencing 3 issues at the moment > > xorg-server master isn't compiling I get the error: > > ../doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. > -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus > -I../hw/xfree86/common -I../hw/xfree86/dri -I../mi > -I../hw/xfree86/dri2 -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith > -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 > -Wold-style-definition -Wdeclaration-after-statement -D_BSD_SOURCE > -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 > -I/usr/include/pixman-1 -I../include -I../include -I../Xext > -I../composite -I../damageext -I../xfixes -I../Xi -I../mi > -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb > -fvisibility=hidden -I/usr/include/drm -I/usr/include/drm > -I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server > -DGLX_USE_TLS -DPTHREADS -D__GLX_ALIGN64 -march=native -O2 -pipe -w > -MT glxdri2.lo -MD -MP -MF .deps/glxdri2.Tpo -c -o glxdri2.lo > glxdri2.c > glxdri2.c: In function '__glXDRIdrawableSwapBuffers': > glxdri2.c:221: error: '__DRI2flushExtension' has no member named > 'flushInvalidate' > 21:09 < codin> jbarnes: glxdri2.c:221: error: ‘__DRI2flushExtension’ has no member named ‘flushInvalidate’ 21:09 < codin> ?! 21:09 < jbarnes> codin: X master is broken 21:10 < ickle> s/jbarnes/krh/ 21:10 < jbarnes> you'll need krh's invalidate branch 21:10 < jbarnes> codin: look for "DRI2 Invalidate series" on xorg-devel 21:10 < codin> how do I do that ? 21:10 < jbarnes> codin: or just "git pull ssh://people.freedesktop.org/~krh/xserver dri2-invalidate" from your xserver tree 21:10 < ickle> notmuch search "DRI2 Invalidate series" 21:19 < cworth> ickle: Thanks. I'll grab that patch. 21:20 < codin> ickle, where do I look or that ? 21:21 < ickle> codin: 20:10 < jbarnes> codin: or just "git pull ssh://people.freedesktop.org/~krh/xserver dri2-invalidate" from your xserver tree 21:21 < codin> ickle, that one is asking for a password 21:21 < ickle> git pull git://anongit.freedesktop.org/~krh/xserver dri2-invalidate And DRM build issue : 00:26 < jifli> Someone knows that the current drm-intel-next doesn't build right? 00:32 < jbarnes> anholt: build breakage due to the sr conflict resolution? 00:32 < jbarnes> or something... 00:32 < jifli> yeah that's right 00:32 < anholt> eh, I'll get to it at some point. 00:33 < jbarnes> I don't see why it's failing offhand 00:33 < jifli> forgot (dev) after IS_I915GM 00:33 < jifli> line 2778 in intel_display.c 00:34 < jbarnes> oh I was looking at debugfs.c 00:34 < jbarnes> yeah that's it |
|
From: Dan N. <dbn...@gm...> - 2010-02-18 22:58:23
|
On Thu, Feb 18, 2010 at 2:52 PM, Mike Lothian <mi...@fi...> wrote: > On 18 February 2010 22:46, Dan Nicholson <dbn...@gm...> wrote: >> On Thu, Feb 18, 2010 at 2:36 PM, Mike Lothian <mi...@fi...> wrote: >>> I'm experiencing 3 issues at the moment >>> >>> xorg-server master isn't compiling I get the error: >>> >>> ../doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. >>> -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus >>> -I../hw/xfree86/common -I../hw/xfree86/dri -I../mi >>> -I../hw/xfree86/dri2 -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith >>> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations >>> -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 >>> -Wold-style-definition -Wdeclaration-after-statement -D_BSD_SOURCE >>> -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 >>> -I/usr/include/pixman-1 -I../include -I../include -I../Xext >>> -I../composite -I../damageext -I../xfixes -I../Xi -I../mi >>> -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb >>> -fvisibility=hidden -I/usr/include/drm -I/usr/include/drm >>> -I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server >>> -DGLX_USE_TLS -DPTHREADS -D__GLX_ALIGN64 -march=native -O2 -pipe -w >>> -MT glxdri2.lo -MD -MP -MF .deps/glxdri2.Tpo -c -o glxdri2.lo >>> glxdri2.c >>> glxdri2.c: In function '__glXDRIdrawableSwapBuffers': >>> glxdri2.c:221: error: '__DRI2flushExtension' has no member named >>> 'flushInvalidate' >>> >>> mesa wont compile. I have no idea what's happening >>> >>> gmake[5]: Entering directory >>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>> running /usr/bin/makedepend >>> gmake[5]: Leaving directory >>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>> gmake[5]: Entering directory >>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>> gmake[6]: Entering directory >>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>> x86_64-pc-linux-gnu-gcc -c -I. >>> -I../../../../../src/mesa/drivers/dri/common -Iserver >>> -I../../../../../include -I../../../../../src/mesa >>> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri >>> -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall >>> -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden >>> -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS >>> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS >>> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING >>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS ../common/utils.c -o >>> ../common/utils.o >>> x86_64-pc-linux-gnu-gcc -c -I. >>> -I../../../../../src/mesa/drivers/dri/common -Iserver >>> -I../../../../../include -I../../../../../src/mesa >>> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri >>> -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall >>> -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden >>> -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS >>> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS >>> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING >>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS swrast.c -o swrast.o >>> x86_64-pc-linux-gnu-gcc -c -I. >>> -I../../../../../src/mesa/drivers/dri/common -Iserver >>> -I../../../../../include -I../../../../../src/mesa >>> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri >>> -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall >>> -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden >>> -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS >>> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS >>> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING >>> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS swrast_span.c -o swrast_span.o >>> /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker >>> 'x86_64-pc-linux-gnu-gcc' -ldflags '-Wl,-O1 -Wl,--hash-style=gnu >>> -Wl,--as-needed' \ >>> ../../common/driverfuncs.o ../common/utils.o swrast.o >>> swrast_span.o ../../../../../src/mesa/libmesa.a \ >>> -ldrm -lexpat -lm -lpthread -ldl >>> mklib: Making Linux shared library: swrast_dri.so >>> gmake[6]: *** [swrast_dri.so] Error 1 >>> gmake[6]: Leaving directory >>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>> gmake[5]: *** [lib] Error 2 >>> gmake[5]: Leaving directory >>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >>> gmake[4]: *** [subdirs] Error 1 >>> gmake[4]: Leaving directory >>> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri' >>> gmake[3]: *** [default] Error 1 >> >> For this one, you should revert commit >> d6f55492af3cb82b0113fe6beac0f3494b6e2956. trap and exit on ERR >> shouldn't be used blindly since it's entirely possible there are >> commands that safely fail in mklib. Not to mention that it's not >> portable. >> >> -- >> Dan >> > > Thanks Dan > > Does any one have access to get this reverted on master? I just did it. Try again. -- Dan |
|
From: Mike L. <mi...@fi...> - 2010-02-18 22:53:29
|
On 18 February 2010 22:46, Dan Nicholson <dbn...@gm...> wrote: > On Thu, Feb 18, 2010 at 2:36 PM, Mike Lothian <mi...@fi...> wrote: >> I'm experiencing 3 issues at the moment >> >> xorg-server master isn't compiling I get the error: >> >> ../doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. >> -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus >> -I../hw/xfree86/common -I../hw/xfree86/dri -I../mi >> -I../hw/xfree86/dri2 -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith >> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations >> -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 >> -Wold-style-definition -Wdeclaration-after-statement -D_BSD_SOURCE >> -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 >> -I/usr/include/pixman-1 -I../include -I../include -I../Xext >> -I../composite -I../damageext -I../xfixes -I../Xi -I../mi >> -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb >> -fvisibility=hidden -I/usr/include/drm -I/usr/include/drm >> -I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server >> -DGLX_USE_TLS -DPTHREADS -D__GLX_ALIGN64 -march=native -O2 -pipe -w >> -MT glxdri2.lo -MD -MP -MF .deps/glxdri2.Tpo -c -o glxdri2.lo >> glxdri2.c >> glxdri2.c: In function '__glXDRIdrawableSwapBuffers': >> glxdri2.c:221: error: '__DRI2flushExtension' has no member named >> 'flushInvalidate' >> >> mesa wont compile. I have no idea what's happening >> >> gmake[5]: Entering directory >> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >> running /usr/bin/makedepend >> gmake[5]: Leaving directory >> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >> gmake[5]: Entering directory >> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >> gmake[6]: Entering directory >> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >> x86_64-pc-linux-gnu-gcc -c -I. >> -I../../../../../src/mesa/drivers/dri/common -Iserver >> -I../../../../../include -I../../../../../src/mesa >> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri >> -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall >> -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden >> -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS >> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS >> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING >> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS ../common/utils.c -o >> ../common/utils.o >> x86_64-pc-linux-gnu-gcc -c -I. >> -I../../../../../src/mesa/drivers/dri/common -Iserver >> -I../../../../../include -I../../../../../src/mesa >> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri >> -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall >> -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden >> -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS >> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS >> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING >> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS swrast.c -o swrast.o >> x86_64-pc-linux-gnu-gcc -c -I. >> -I../../../../../src/mesa/drivers/dri/common -Iserver >> -I../../../../../include -I../../../../../src/mesa >> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri >> -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall >> -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden >> -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS >> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS >> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING >> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS swrast_span.c -o swrast_span.o >> /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker >> 'x86_64-pc-linux-gnu-gcc' -ldflags '-Wl,-O1 -Wl,--hash-style=gnu >> -Wl,--as-needed' \ >> ../../common/driverfuncs.o ../common/utils.o swrast.o >> swrast_span.o ../../../../../src/mesa/libmesa.a \ >> -ldrm -lexpat -lm -lpthread -ldl >> mklib: Making Linux shared library: swrast_dri.so >> gmake[6]: *** [swrast_dri.so] Error 1 >> gmake[6]: Leaving directory >> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >> gmake[5]: *** [lib] Error 2 >> gmake[5]: Leaving directory >> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' >> gmake[4]: *** [subdirs] Error 1 >> gmake[4]: Leaving directory >> `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri' >> gmake[3]: *** [default] Error 1 > > For this one, you should revert commit > d6f55492af3cb82b0113fe6beac0f3494b6e2956. trap and exit on ERR > shouldn't be used blindly since it's entirely possible there are > commands that safely fail in mklib. Not to mention that it's not > portable. > > -- > Dan > Thanks Dan Does any one have access to get this reverted on master? |
|
From: Dan N. <dbn...@gm...> - 2010-02-18 22:52:41
|
On Thu, Feb 18, 2010 at 2:24 PM, Dan Nicholson <dbn...@gm...> wrote:
> On Thu, Feb 18, 2010 at 2:12 PM, Sedat Dilek <sed...@go...> wrote:
>> Hi,
>>
>> Debian has dash as standard /bin/sh, this breaks mesa:
>>
>> commit d6f55492af3cb82b0113fe6beac0f3494b6e2956
>> "Make mklib propogate all errors"
>>
>> $ ls -l /bin/sh
>> lrwxrwxrwx 1 root root 4 2009-09-17 12:53 /bin/sh -> dash
>>
>> checkbashisms script reports the following bashisms:
>>
>> $ checkbashisms mesa/bin/mklib
>> possible bashism in mesa/bin/mklib line 29 ('function' is useless):
>> function errtrap {
>> possible bashism in mesa/bin/mklib line 447 (type):
>> elif [ `type g++` ] ; then
>>
>> As a quick fix, I changed in bin/mklib from /bin/sh to /bin/bash.
>> That works for me.
>> Not sure how you wanna fix this properly.
>
> Yeah, this should be reverted. See bug 26632.
>
> http://bugs.freedesktop.org/show_bug.cgi?id=26632
>
> The only portable way to do this will be to just check the return
> value for all relevant commands. That should basically be anything
> using ar or $LINK, but I haven't looked closely.
I reverted that patch. Try again.
--
Dan
|
|
From: <bug...@fr...> - 2010-02-18 22:51:56
|
http://bugs.freedesktop.org/show_bug.cgi?id=26632 --- Comment #7 from Dan Nicholson <dbn...@gm...> 2010-02-18 14:51:49 PST --- I reverted d6f55492af3cb82b0113fe6beac0f3494b6e2956 (patch 4) since it already caused two separate build errors on the mailing list. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Dan N. <dbn...@gm...> - 2010-02-18 22:46:35
|
On Thu, Feb 18, 2010 at 2:36 PM, Mike Lothian <mi...@fi...> wrote: > I'm experiencing 3 issues at the moment > > xorg-server master isn't compiling I get the error: > > ../doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. > -I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus > -I../hw/xfree86/common -I../hw/xfree86/dri -I../mi > -I../hw/xfree86/dri2 -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith > -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 > -Wold-style-definition -Wdeclaration-after-statement -D_BSD_SOURCE > -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 > -I/usr/include/pixman-1 -I../include -I../include -I../Xext > -I../composite -I../damageext -I../xfixes -I../Xi -I../mi > -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb > -fvisibility=hidden -I/usr/include/drm -I/usr/include/drm > -I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server > -DGLX_USE_TLS -DPTHREADS -D__GLX_ALIGN64 -march=native -O2 -pipe -w > -MT glxdri2.lo -MD -MP -MF .deps/glxdri2.Tpo -c -o glxdri2.lo > glxdri2.c > glxdri2.c: In function '__glXDRIdrawableSwapBuffers': > glxdri2.c:221: error: '__DRI2flushExtension' has no member named > 'flushInvalidate' > > mesa wont compile. I have no idea what's happening > > gmake[5]: Entering directory > `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' > running /usr/bin/makedepend > gmake[5]: Leaving directory > `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' > gmake[5]: Entering directory > `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' > gmake[6]: Entering directory > `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' > x86_64-pc-linux-gnu-gcc -c -I. > -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../include -I../../../../../src/mesa > -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri > -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall > -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden > -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS > -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS > -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING > -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS ../common/utils.c -o > ../common/utils.o > x86_64-pc-linux-gnu-gcc -c -I. > -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../include -I../../../../../src/mesa > -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri > -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall > -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden > -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS > -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS > -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING > -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS swrast.c -o swrast.o > x86_64-pc-linux-gnu-gcc -c -I. > -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../include -I../../../../../src/mesa > -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri > -I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall > -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden > -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS > -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS > -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING > -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS swrast_span.c -o swrast_span.o > /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker > 'x86_64-pc-linux-gnu-gcc' -ldflags '-Wl,-O1 -Wl,--hash-style=gnu > -Wl,--as-needed' \ > ../../common/driverfuncs.o ../common/utils.o swrast.o > swrast_span.o ../../../../../src/mesa/libmesa.a \ > -ldrm -lexpat -lm -lpthread -ldl > mklib: Making Linux shared library: swrast_dri.so > gmake[6]: *** [swrast_dri.so] Error 1 > gmake[6]: Leaving directory > `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' > gmake[5]: *** [lib] Error 2 > gmake[5]: Leaving directory > `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast' > gmake[4]: *** [subdirs] Error 1 > gmake[4]: Leaving directory > `/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri' > gmake[3]: *** [default] Error 1 For this one, you should revert commit d6f55492af3cb82b0113fe6beac0f3494b6e2956. trap and exit on ERR shouldn't be used blindly since it's entirely possible there are commands that safely fail in mklib. Not to mention that it's not portable. -- Dan |
|
From: Mike L. <mi...@fi...> - 2010-02-18 22:36:44
|
I'm experiencing 3 issues at the moment
xorg-server master isn't compiling I get the error:
../doltcompile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
-I../include -I../hw/xfree86/os-support -I../hw/xfree86/os-support/bus
-I../hw/xfree86/common -I../hw/xfree86/dri -I../mi
-I../hw/xfree86/dri2 -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2
-Wold-style-definition -Wdeclaration-after-statement -D_BSD_SOURCE
-DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2
-I/usr/include/pixman-1 -I../include -I../include -I../Xext
-I../composite -I../damageext -I../xfixes -I../Xi -I../mi
-I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb
-fvisibility=hidden -I/usr/include/drm -I/usr/include/drm
-I/usr/include/drm -I/usr/include/X11/dri -DXFree86Server
-DGLX_USE_TLS -DPTHREADS -D__GLX_ALIGN64 -march=native -O2 -pipe -w
-MT glxdri2.lo -MD -MP -MF .deps/glxdri2.Tpo -c -o glxdri2.lo
glxdri2.c
glxdri2.c: In function '__glXDRIdrawableSwapBuffers':
glxdri2.c:221: error: '__DRI2flushExtension' has no member named
'flushInvalidate'
mesa wont compile. I have no idea what's happening
gmake[5]: Entering directory
`/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast'
running /usr/bin/makedepend
gmake[5]: Leaving directory
`/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast'
gmake[5]: Entering directory
`/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast'
gmake[6]: Entering directory
`/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast'
x86_64-pc-linux-gnu-gcc -c -I.
-I../../../../../src/mesa/drivers/dri/common -Iserver
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
-I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS ../common/utils.c -o
../common/utils.o
x86_64-pc-linux-gnu-gcc -c -I.
-I../../../../../src/mesa/drivers/dri/common -Iserver
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
-I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS swrast.c -o swrast.o
x86_64-pc-linux-gnu-gcc -c -I.
-I../../../../../src/mesa/drivers/dri/common -Iserver
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
-I/usr/include/drm -march=native -O2 -pipe -w -ffast-math -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS swrast_span.c -o swrast_span.o
/bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker
'x86_64-pc-linux-gnu-gcc' -ldflags '-Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed' \
../../common/driverfuncs.o ../common/utils.o swrast.o
swrast_span.o ../../../../../src/mesa/libmesa.a \
-ldrm -lexpat -lm -lpthread -ldl
mklib: Making Linux shared library: swrast_dri.so
gmake[6]: *** [swrast_dri.so] Error 1
gmake[6]: Leaving directory
`/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast'
gmake[5]: *** [lib] Error 2
gmake[5]: Leaving directory
`/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri/swrast'
gmake[4]: *** [subdirs] Error 1
gmake[4]: Leaving directory
`/var/tmp/portage/media-libs/mesa-9999/work/Mesa-9999/src/mesa/drivers/dri'
gmake[3]: *** [default] Error 1
And lastly the latest intel DRM code from drm-intel-next has the
following issue too:
CC drivers/gpu/drm/i915/intel_display.o
drivers/gpu/drm/i915/intel_display.c: In function 'i9xx_update_wm':
drivers/gpu/drm/i915/intel_display.c:2778: error: 'IS_I915GM'
undeclared (first use in this function)
drivers/gpu/drm/i915/intel_display.c:2778: error: (Each undeclared
identifier is reported only once
drivers/gpu/drm/i915/intel_display.c:2778: error: for each function it
appears in.)
make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1
Sorry to spam the mailing lists with this but my guess is the people
who introduced these bugs are either using different branches or have
fixes already in their local trees
Cheers
Mike
|
|
From: Dan N. <dbn...@gm...> - 2010-02-18 22:24:36
|
On Thu, Feb 18, 2010 at 2:12 PM, Sedat Dilek <sed...@go...> wrote:
> Hi,
>
> Debian has dash as standard /bin/sh, this breaks mesa:
>
> commit d6f55492af3cb82b0113fe6beac0f3494b6e2956
> "Make mklib propogate all errors"
>
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 2009-09-17 12:53 /bin/sh -> dash
>
> checkbashisms script reports the following bashisms:
>
> $ checkbashisms mesa/bin/mklib
> possible bashism in mesa/bin/mklib line 29 ('function' is useless):
> function errtrap {
> possible bashism in mesa/bin/mklib line 447 (type):
> elif [ `type g++` ] ; then
>
> As a quick fix, I changed in bin/mklib from /bin/sh to /bin/bash.
> That works for me.
> Not sure how you wanna fix this properly.
Yeah, this should be reverted. See bug 26632.
http://bugs.freedesktop.org/show_bug.cgi?id=26632
The only portable way to do this will be to just check the return
value for all relevant commands. That should basically be anything
using ar or $LINK, but I haven't looked closely.
--
Dan
|
|
From: Sedat D. <sed...@go...> - 2010-02-18 22:12:20
|
Hi,
Debian has dash as standard /bin/sh, this breaks mesa:
commit d6f55492af3cb82b0113fe6beac0f3494b6e2956
"Make mklib propogate all errors"
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 2009-09-17 12:53 /bin/sh -> dash
checkbashisms script reports the following bashisms:
$ checkbashisms mesa/bin/mklib
possible bashism in mesa/bin/mklib line 29 ('function' is useless):
function errtrap {
possible bashism in mesa/bin/mklib line 447 (type):
elif [ `type g++` ] ; then
As a quick fix, I changed in bin/mklib from /bin/sh to /bin/bash.
That works for me.
Not sure how you wanna fix this properly.
Kind Regards,
- Sedat -
|
|
From: Ville S. <sy...@sc...> - 2010-02-18 21:42:07
|
On Thu, Feb 18, 2010 at 09:19:46PM +0200, Pauli Nieminen wrote: > On Thu, Feb 18, 2010 at 8:31 PM, Francisco Jerez <cur...@ri...> wrote: > > With current HEAD, if an app mixes GL and X11 calls, resizing could lead > > to broken and incompletely rendered frames, as in the old DRI1 days. The > > succession of events would be something like: > > > > * The app renders half a frame. > > * It does something that makes libX11 process its input buffer (Any > > round-trip would do it, not only the X rendering commands). The DRI2 > > event arrives at this point. > > * The app tries to render the other half, dri_update_buffer realizes the > > window has been resized so it swaps buffers, throwing away the first > > half. > > > > However, I admit I don't have any real-life apps that could lead to > > this, so this could very well be called a purely theoretical concern and > > a case of pointless overengineering. > > > > If you want to overengineer you could make blit to screen handle > scaling of frame in case window sizes doesn't match the size that > frame was rendered at. Private rendering buffer rescaling would happen > in dri code after buffer swap only. This would quarantine that > rendering buffer wouldn't require scaling in middle of frame. Application generally don't want to rescale the window content when the size changes. They just want to move stuff around and resize some elements of the UI. So I'm guessing this kind of whole window scaling would look quite ugly. Shouldn't it just respect the window's bit gravity instead? -- Ville Syrjälä sy...@sc... http://www.sci.fi/~syrjala/ |
|
From: <bug...@fr...> - 2010-02-18 20:42:42
|
http://bugs.freedesktop.org/show_bug.cgi?id=26632 --- Comment #6 from Dan Nicholson <dbn...@gm...> 2010-02-18 12:42:34 PST --- (In reply to comment #4) > Created an attachment (id=33393) --> (http://bugs.freedesktop.org/attachment.cgi?id=33393) [details] > Make mklib propogate all errors > > Bonus patch :-) Nice. Unfortunately, I think trap on ERR is an extension and won't work for many shells. It doesn't appear to be POSIX let along bourne compatible. http://www.opengroup.org/onlinepubs/000095399/utilities/trap.html Here's the default ubuntu/debian shell, dash: $ trap 'echo foo' ERR trap: 1: ERR: bad trap I think we'll have to revert that patch and go with the brute force method of checking all the significant commands. You can do it a little simpler, though: command that could fail || exit $? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@fr...> - 2010-02-18 19:59:56
|
http://bugs.freedesktop.org/show_bug.cgi?id=26632 --- Comment #5 from Brian Paul <bri...@gm...> 2010-02-18 11:59:39 PST --- I've commited patches 1, 2 and 4. I think that the 3rd patch will result in multiply defined symbols in the normal build since libmesa.a already contains the glsl libs. See line 32 of src/mesa/Makefile. I think the cygwin code in mklib needs to use expand_archives() as the linux target does. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Pauli N. <su...@gm...> - 2010-02-18 19:42:55
|
On Thu, Feb 18, 2010 at 8:31 PM, Francisco Jerez <cur...@ri...> wrote: > Keith Whitwell <ke...@vm...> writes: > >> On Thu, 2010-02-18 at 05:16 -0800, Francisco Jerez wrote: >>> Keith Whitwell <ke...@vm...> writes: >>> >>> > On Thu, 2010-02-18 at 00:15 -0800, Keith Whitwell wrote: >>> >> On Wed, Feb 17, 2010 at 10:39 PM, Francisco Jerez >>> >> <cur...@ke...> wrote: >>> >> > Module: Mesa >>> >> > Branch: master >>> >> > Commit: f455ca6490fcb65781b21f81c7117bd923e250d1 >>> >> > URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=f455ca6490fcb65781b21f81c7117bd923e250d1 >>> >> > >>> >> > Author: Francisco Jerez <cur...@ri...> >>> >> > Date: Tue Feb 16 17:21:10 2010 +0100 >>> >> > >>> >> > st/mesa: Make the frontbuffer visible on st_flush(PIPE_FLUSH_FRAME). >>> >> > >>> >> > So far the frontbuffer was only being flushed on st_glFlush and >>> >> > st_glFinish, however, a co-state tracker may need to make sure that >>> >> > any frontbuffer changes are already on its way to the actual front. >>> >> > >>> >> > The dri2 state tracker will need this for event-driven GL applications >>> >> > to resize properly (It could also be done calling "dri_flush_frontbuffer", >>> >> > but that way we would flush unnecessarily in the double-buffered case). >>> >> > >>> >> > Additionally this patch avoids flushing the mesa rendering cache if >>> >> > PIPE_FLUSH_RENDER_CACHE wasn't specified. >>> >> > >>> >> > --- >>> >> > >>> >> > src/mesa/state_tracker/st_cb_flush.c | 15 ++++++--------- >>> >> > 1 files changed, 6 insertions(+), 9 deletions(-) >>> >> > >>> >> > diff --git a/src/mesa/state_tracker/st_cb_flush.c b/src/mesa/state_tracker/st_cb_flush.c >>> >> > index 1329f80..0ddfce4 100644 >>> >> > --- a/src/mesa/state_tracker/st_cb_flush.c >>> >> > +++ b/src/mesa/state_tracker/st_cb_flush.c >>> >> > @@ -91,7 +91,8 @@ display_front_buffer(struct st_context *st) >>> >> > void st_flush( struct st_context *st, uint pipeFlushFlags, >>> >> > struct pipe_fence_handle **fence ) >>> >> > { >>> >> > - FLUSH_CURRENT(st->ctx, 0); >>> >> > + if (pipeFlushFlags & PIPE_FLUSH_RENDER_CACHE) >>> >> > + FLUSH_CURRENT(st->ctx, 0); >>> >> >>> >> This is incorrect. Without this call, st->pipe->flush() will be >>> >> called with the VBO buffers still mapped, which is illegal. This >>> >> needs to be undone. >>> > >>> > OK, I've backed this hunk out. Sorry for not spotting this earlier - >>> > the interactions between the VBO module and driver buffer managers is >>> > definitely a fragile area. >>> > >>> Okay, thanks for pointing this out, and *sorry* for my impatience and >>> for not giving a clear statement of the motivations behind that hunk: We >>> really don't want to flush the VBO rendering caches in that case, >>> there's no need to, and it can lead to a recursive call into the VBO >>> module because we were already called by it, and right now it isn't >>> fully reentrant. >>> >>> With your and José's arguments in mind, I don't think my st_flush >>> changes made any sense, it's a bad design even with a new >>> "PIPE_FLUSH_FRONT" flag (that isn't the pipe driver business, is it?). >>> >>> IMHO a new "st_notify_invalidate" interface would be a somewhat better >>> idea: It would mean that the windowing system is about to throw its >>> current buffers away and allocate new ones, so it would let the state >>> tracker flush whatever it needs to. >>> >>> I've reverted both patches until we consider this issue discussed. Any >>> better ideas? >> >> What would help me a lot is to create or modify one of the mesa demos to >> illustrate the problem you're trying to fix. I think I'm getting an >> understanding now, but there is still possible ambiguity and having a >> concrete example may help get us all onto the same page about what the >> goal of the changes is. >> >> I think I understand it now, but I'm still not sure how much there is we >> can do. It sounds like: >> >> App renders half a frame to a front buffer >> DRI2 receives somehow a notification of window size change >> DRI2 wants to destroy and recreate the window buffers >> --> Your change would try and flush the pipe driver here >> DRI2 ?? creates new front buffer ?? >> DRI2 ?? blits contents of old front to new front ?? >> DRI2 ?? destroys old front buffer ?? >> App keeps on rendering somehow the second half of the front buffer. >> >> I'm unsure how this would all work in practice, and a concrete example >> of an app doing something sensible in these circumstances would help me >> better understand what problem you're fixing. >> >> Keith > > With current HEAD, if an app mixes GL and X11 calls, resizing could lead > to broken and incompletely rendered frames, as in the old DRI1 days. The > succession of events would be something like: > > * The app renders half a frame. > * It does something that makes libX11 process its input buffer (Any > round-trip would do it, not only the X rendering commands). The DRI2 > event arrives at this point. > * The app tries to render the other half, dri_update_buffer realizes the > window has been resized so it swaps buffers, throwing away the first > half. > > However, I admit I don't have any real-life apps that could lead to > this, so this could very well be called a purely theoretical concern and > a case of pointless overengineering. > If you want to overengineer you could make blit to screen handle scaling of frame in case window sizes doesn't match the size that frame was rendered at. Private rendering buffer rescaling would happen in dri code after buffer swap only. This would quarantine that rendering buffer wouldn't require scaling in middle of frame. But this sounds like feature which would be nice to have just in case. But only if implementation can be simple. |
|
From: Ian R. <id...@fr...> - 2010-02-18 19:40:54
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kristian Høgsberg wrote:
> 2010/2/12 Ian Romanick <id...@fr...>:
> Kristian Høgsberg wrote:
>>>> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
>>>> index 0e6f69f..475aeab 100644
>>>> --- a/src/mesa/main/fbobject.c
>>>> +++ b/src/mesa/main/fbobject.c
>>>> @@ -1008,6 +1008,30 @@ renderbuffer_storage(GLenum target, GLenum internalFormat,
>>>> */
>>>> }
>>>>
>>>> +#if FEATURE_OES_EGL_image
>>>> +void GLAPIENTRY
>>>> +_mesa_EGLImageTargetRenderbufferStorageOES (GLenum target, GLeglImageOES image)
>>>> +{
>>>> + GET_CURRENT_CONTEXT(ctx);
>>>> + ASSERT_OUTSIDE_BEGIN_END(ctx);
>>>> + struct gl_renderbuffer *rb;
>>>> +
>>>> + if (target != GL_RENDERBUFFER_EXT) {
> New uses of these enums should use the undecorated versions.
>
>> That means GL_RENDERBUFFER, right?
Yes. Over the years, as things go into core GL, we start using the
non-extension names. We don't typically go back and change the existing
occurances of the extension names. That's generally in the same
category as whitespace cleanup.
>>>> + _mesa_error(ctx, GL_INVALID_ENUM, "EGLImageTargetRenderbufferStorageOES");
>>>> + return;
>>>> + }
>>>> +
>>>> + rb = ctx->CurrentRenderbuffer;
>>>> + if (!rb) {
>>>> + _mesa_error(ctx, GL_INVALID_OPERATION, "EGLImageTargetRenderbufferStorageOES");
>>>> + return;
>>>> + }
>>>> +
> Is there any sort of generic validation of the image that could be done
> here? I suspect not, but I'd hate to see the same validation code
> duplicated in every driver. Maybe that would better belong in a utility
> function in src/mesa/drivers/dri/common. Hmm...
>
>> I know what you're saying, but there isn't. The EGLImage is an EGL
>> type and in our implementation it's a struct _egl_image, but we don't
>> know anything about that here. However, when the driver looks up the
>> EGLImage to get the __DRIimage, we do some basic validation in the
>> lookup function. When the driver finally gets the __DRIimage in hand,
>> there isn't a lot of checking to do; it's just a struct intel_region.
>> I don't worry that this will lead to a lot of code duplication.
Okay.
>>>> + FLUSH_VERTICES(ctx, _NEW_BUFFERS);
>>>> +
>>>> + ctx->Driver.EGLImageTargetRenderbufferStorage(ctx, rb, image);
>>>> +}
>>>> +#endif
>>>>
>>>> /**
>>>> * Helper function for _mesa_GetRenderbufferParameterivEXT() and
>>>> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
>>>> index da3c6f9..6b15c40 100644
>>>> --- a/src/mesa/main/teximage.c
>>>> +++ b/src/mesa/main/teximage.c
>>>> @@ -2448,6 +2448,47 @@ _mesa_TexImage3DEXT( GLenum target, GLint level, GLenum internalFormat,
>>>> }
>>>>
>>>>
>>>> +#if FEATURE_OES_EGL_image
>>>> +void GLAPIENTRY
>>>> +_mesa_EGLImageTargetTexture2DOES (GLenum target, GLeglImageOES image)
>>>> +{
>>>> + GET_CURRENT_CONTEXT(ctx);
>>>> + ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(ctx);
>>>> + struct gl_texture_object *texObj;
>>>> + struct gl_texture_image *texImage;
>>>> +
>>>> + if (target != GL_TEXTURE_2D) {
>>>> + _mesa_error(ctx, GL_INVALID_ENUM, "glCompressedTexImage1D(target)");
> That's probably the wrong error message. :) Cut-and-paste for the lose.
>
>> Oops, fiedx.
>
>>>> + return;
>>>> + }
>>>> +
>>>> + if (ctx->NewState & _MESA_NEW_TRANSFER_STATE)
>>>> + _mesa_update_state(ctx);
>>>> +
>>>> + texObj = _mesa_get_current_tex_object(ctx, target);
>>>> + _mesa_lock_texture(ctx, texObj);
>>>> +
>>>> + texImage = _mesa_get_tex_image(ctx, texObj, target, 0);
>>>> + if (!texImage) {
>>>> + _mesa_error(ctx, GL_OUT_OF_MEMORY, "glTexImage2D");
> That's probably the wrong error message. :) Cut-and-paste for the lose.
>
>> Oops, fiedx.
lol.
>>>> + } else {
>>>> + if (texImage->Data)
>>>> + ctx->Driver.FreeTexImageData( ctx, texImage );
>>>> +
>>>> + ASSERT(texImage->Data == NULL);
>>>> + //clear_teximage_fields(texImage); /* not really needed, but helpful */
>>>> + ctx->Driver.EGLImageTargetTexture2D(ctx, target,
>>>> + texObj, texImage, image);
>>>> +
>>>> + /* state update */
>>>> + texObj->_Complete = GL_FALSE;
>>>> + ctx->NewState |= _NEW_TEXTURE;
>>>> + }
>>>> + _mesa_unlock_texture(ctx, texObj);
>>>> +
>>>> +}
>>>> +#endif
>>>> +
>>>>
>>>> void GLAPIENTRY
>>>> _mesa_TexSubImage1D( GLenum target, GLint level,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt9l6cACgkQX1gOwKyEAw+wQwCdGDLFH9WNw5rAAjqwzNo5S/PH
dTAAn1bbI/xNrW7sMiNbOVG/LM0//Wls
=w5df
-----END PGP SIGNATURE-----
|
|
From: <bug...@fr...> - 2010-02-18 19:29:50
|
http://bugs.freedesktop.org/show_bug.cgi?id=26632 --- Comment #4 from Jon TURNEY <jon...@dr...> 2010-02-18 11:29:41 PST --- Created an attachment (id=33393) --> (http://bugs.freedesktop.org/attachment.cgi?id=33393) Make mklib propogate all errors Bonus patch :-) (In reply to comment #3) > Those all look good to me, although I wish someone would go through mklib and > make it exit everywhere it could fail. This would be a good idea, the build has been broken on cygwin for some time, but my tinderbox didn't notify me because of mklib ignoring the errors. I did consider something like the attached, but that might not be a good idea. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: Francisco J. <cur...@ri...> - 2010-02-18 18:26:21
|
Keith Whitwell <ke...@vm...> writes: > On Thu, 2010-02-18 at 05:16 -0800, Francisco Jerez wrote: >> Keith Whitwell <ke...@vm...> writes: >> >> > On Thu, 2010-02-18 at 00:15 -0800, Keith Whitwell wrote: >> >> On Wed, Feb 17, 2010 at 10:39 PM, Francisco Jerez >> >> <cur...@ke...> wrote: >> >> > Module: Mesa >> >> > Branch: master >> >> > Commit: f455ca6490fcb65781b21f81c7117bd923e250d1 >> >> > URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=f455ca6490fcb65781b21f81c7117bd923e250d1 >> >> > >> >> > Author: Francisco Jerez <cur...@ri...> >> >> > Date: Tue Feb 16 17:21:10 2010 +0100 >> >> > >> >> > st/mesa: Make the frontbuffer visible on st_flush(PIPE_FLUSH_FRAME). >> >> > >> >> > So far the frontbuffer was only being flushed on st_glFlush and >> >> > st_glFinish, however, a co-state tracker may need to make sure that >> >> > any frontbuffer changes are already on its way to the actual front. >> >> > >> >> > The dri2 state tracker will need this for event-driven GL applications >> >> > to resize properly (It could also be done calling "dri_flush_frontbuffer", >> >> > but that way we would flush unnecessarily in the double-buffered case). >> >> > >> >> > Additionally this patch avoids flushing the mesa rendering cache if >> >> > PIPE_FLUSH_RENDER_CACHE wasn't specified. >> >> > >> >> > --- >> >> > >> >> > src/mesa/state_tracker/st_cb_flush.c | 15 ++++++--------- >> >> > 1 files changed, 6 insertions(+), 9 deletions(-) >> >> > >> >> > diff --git a/src/mesa/state_tracker/st_cb_flush.c b/src/mesa/state_tracker/st_cb_flush.c >> >> > index 1329f80..0ddfce4 100644 >> >> > --- a/src/mesa/state_tracker/st_cb_flush.c >> >> > +++ b/src/mesa/state_tracker/st_cb_flush.c >> >> > @@ -91,7 +91,8 @@ display_front_buffer(struct st_context *st) >> >> > void st_flush( struct st_context *st, uint pipeFlushFlags, >> >> > struct pipe_fence_handle **fence ) >> >> > { >> >> > - FLUSH_CURRENT(st->ctx, 0); >> >> > + if (pipeFlushFlags & PIPE_FLUSH_RENDER_CACHE) >> >> > + FLUSH_CURRENT(st->ctx, 0); >> >> >> >> This is incorrect. Without this call, st->pipe->flush() will be >> >> called with the VBO buffers still mapped, which is illegal. This >> >> needs to be undone. >> > >> > OK, I've backed this hunk out. Sorry for not spotting this earlier - >> > the interactions between the VBO module and driver buffer managers is >> > definitely a fragile area. >> > >> Okay, thanks for pointing this out, and *sorry* for my impatience and >> for not giving a clear statement of the motivations behind that hunk: We >> really don't want to flush the VBO rendering caches in that case, >> there's no need to, and it can lead to a recursive call into the VBO >> module because we were already called by it, and right now it isn't >> fully reentrant. >> >> With your and José's arguments in mind, I don't think my st_flush >> changes made any sense, it's a bad design even with a new >> "PIPE_FLUSH_FRONT" flag (that isn't the pipe driver business, is it?). >> >> IMHO a new "st_notify_invalidate" interface would be a somewhat better >> idea: It would mean that the windowing system is about to throw its >> current buffers away and allocate new ones, so it would let the state >> tracker flush whatever it needs to. >> >> I've reverted both patches until we consider this issue discussed. Any >> better ideas? > > What would help me a lot is to create or modify one of the mesa demos to > illustrate the problem you're trying to fix. I think I'm getting an > understanding now, but there is still possible ambiguity and having a > concrete example may help get us all onto the same page about what the > goal of the changes is. > > I think I understand it now, but I'm still not sure how much there is we > can do. It sounds like: > > App renders half a frame to a front buffer > DRI2 receives somehow a notification of window size change > DRI2 wants to destroy and recreate the window buffers > --> Your change would try and flush the pipe driver here > DRI2 ?? creates new front buffer ?? > DRI2 ?? blits contents of old front to new front ?? > DRI2 ?? destroys old front buffer ?? > App keeps on rendering somehow the second half of the front buffer. > > I'm unsure how this would all work in practice, and a concrete example > of an app doing something sensible in these circumstances would help me > better understand what problem you're fixing. > > Keith With current HEAD, if an app mixes GL and X11 calls, resizing could lead to broken and incompletely rendered frames, as in the old DRI1 days. The succession of events would be something like: * The app renders half a frame. * It does something that makes libX11 process its input buffer (Any round-trip would do it, not only the X rendering commands). The DRI2 event arrives at this point. * The app tries to render the other half, dri_update_buffer realizes the window has been resized so it swaps buffers, throwing away the first half. However, I admit I don't have any real-life apps that could lead to this, so this could very well be called a purely theoretical concern and a case of pointless overengineering. |
|
From: Chia-I Wu <ol...@gm...> - 2010-02-18 17:31:32
|
On Thu, Feb 18, 2010 at 12:04:14PM -0500, Kristian Høgsberg wrote:
> 2010/2/12 Ian Romanick <id...@fr...>:
> >> +static _EGLImage *
> >> +dri2_create_image_khr(_EGLDriver *drv, _EGLDisplay *disp,
> >> + _EGLContext *ctx, EGLenum target,
> >> + EGLClientBuffer buffer, const EGLint *attr_list)
> >> +{
> >> + struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> >> + struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
> >> + struct dri2_egl_image *dri2_img;
> >> + unsigned int attachments[1];
> >> + xcb_drawable_t drawable;
> >> + xcb_dri2_get_buffers_cookie_t cookie;
> >> + xcb_dri2_dri2_buffer_t *buffers;
> >> + xcb_dri2_get_buffers_reply_t *reply;
> >> +
> >> + dri2_img = malloc(sizeof *dri2_img);
> >> + if (!dri2_img) {
> >> + _eglError(EGL_BAD_ALLOC, "dri2_create_image_khr");
> >> + return EGL_NO_IMAGE_KHR;
> >> + }
> >> +
> >> + if (!_eglInitImage(&dri2_img->base, disp, attr_list))
> >> + return EGL_NO_IMAGE_KHR;
> >> +
> >> + switch (target) {
> >> + case EGL_NATIVE_PIXMAP_KHR:
> >> + drawable = (xcb_drawable_t) buffer;
> >> + xcb_dri2_create_drawable (dri2_dpy->conn, drawable);
> >> + attachments[0] = XCB_DRI2_ATTACHMENT_BUFFER_FRONT_LEFT;
> >> + cookie = xcb_dri2_get_buffers_unchecked (dri2_dpy->conn,
> >> + drawable, 1, 1, attachments);
> >> + reply = xcb_dri2_get_buffers_reply (dri2_dpy->conn, cookie, NULL);
> >> + buffers = xcb_dri2_get_buffers_buffers (reply);
> >> + if (buffers == NULL) {
> >> + free(dri2_img);
> >> + return NULL;
> >> + }
> >> +
> >> + dri2_img->width = reply->width;
> >> + dri2_img->height = reply->height;
> >> + dri2_img->name = buffers[0].name;
> >> + dri2_img->pitch = buffers[0].pitch / buffers[0].cpp;
> >> + dri2_img->cpp = buffers[0].cpp;
> >> + free(reply);
> >> + break;
> >> +
> >> + default:
> >> + _eglError(EGL_BAD_PARAMETER, "dri2_create_image_khr");
> >> + free(dri2_img);
> >> + return EGL_NO_IMAGE_KHR;
> >> + }
> >> +
> >> + dri2_img->dri_image =
> >> + dri2_dpy->image->createImageFromName(dri2_ctx->dri_context,
> >> + dri2_img->width,
> >> + dri2_img->height,
> >> + GL_RGBA,
> >> + dri2_img->name,
> >> + dri2_img->pitch,
> >> + dri2_img);
> >> +
> > Since applications call this function directly, should this give an
> > error if dri2_dpy->image is NULL, or is it okay to just segfault?
> If __DRIimage isn't available, eglInitializeDisplay fails. I suppose
> we should make that optional and just not advertise any EGLImage
> extensions instead.
It should be noted that eglapi.c does not check if an extension is
available before dispatching (while it probably should).
BTW, it seems
dri2_dpy->base.Extensions.KHR_image_base and
dri2_dpy->base.Extensions.KHR_image_pixmap
are not set in the patch to advertise the extensions.
--
ol...@Lu...
|
|
From: Kristian H. <kr...@bi...> - 2010-02-18 17:04:23
|
2010/2/12 Ian Romanick <id...@fr...>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kristian Høgsberg wrote:
>> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
>> index 5d36c49..1590190 100644
>> --- a/src/egl/drivers/dri2/egl_dri2.c
>> +++ b/src/egl/drivers/dri2/egl_dri2.c
>> @@ -42,7 +42,6 @@
>> #include <X11/Xlib-xcb.h>
>>
>> #include <glapi/glapi.h>
>> -#include "eglconfigutil.h"
>> #include "eglconfig.h"
>> #include "eglcontext.h"
>> #include "egldisplay.h"
>> @@ -50,6 +49,7 @@
>> #include "eglcurrent.h"
>> #include "egllog.h"
>> #include "eglsurface.h"
>> +#include "eglimage.h"
>>
>> struct dri2_egl_driver
>> {
>> @@ -67,10 +67,12 @@ struct dri2_egl_display
>> __DRIdri2Extension *dri2;
>> __DRI2flushExtension *flush;
>> __DRItexBufferExtension *tex_buffer;
>> + __DRIimageExtension *image;
>> int fd;
>>
>> __DRIdri2LoaderExtension loader_extension;
>> - const __DRIextension *extensions[2];
>> + __DRIimageLookupExtension image_lookup_extension;
>> + const __DRIextension *extensions[3];
>> };
>>
>> struct dri2_egl_context
>> @@ -93,12 +95,24 @@ struct dri2_egl_surface
>>
>> struct dri2_egl_config
>> {
>> - _EGLConfig base;
>> + _EGLConfig base;
>> const __DRIconfig *dri_config;
>> };
>>
>> +struct dri2_egl_image
>> +{
>> + _EGLImage base;
>> + __DRIimage *dri_image;
>> + int width;
>> + int height;
>> + int name;
>> + int pitch;
>> + int cpp;
>> +};
>> +
>> /* standard typecasts */
>> _EGL_DRIVER_STANDARD_TYPECASTS(dri2_egl)
>> +_EGL_DRIVER_TYPECAST(dri2_egl_image, _EGLImage, obj)
>>
>> EGLint dri2_to_egl_attribute_map[] = {
>> 0,
>> @@ -346,6 +360,25 @@ dri2_flush_front_buffer(__DRIdrawable * driDrawable, void *loaderPrivate)
>> #endif
>> }
>>
>> +static __DRIimage *
>> +dri2_lookup_image(__DRIcontext *context, void *image, void *data)
>> +{
>> + struct dri2_egl_context *dri2_ctx = data;
>> + _EGLDisplay *disp = dri2_ctx->base.Resource.Display;
>> + struct dri2_egl_image *dri2_img;
>> + _EGLImage *img;
>> +
>> + img = _eglLookupImage(image, disp);
>> + if (img == NULL) {
>> + _eglError(EGL_BAD_PARAMETER, "dri2_lookup_image");
>> + return NULL;
>> + }
>> +
>> + dri2_img = dri2_egl_image(image);
>> +
>> + return dri2_img->dri_image;
>> +}
>> +
>
> If this function can only be called by a driver, I don't think it should
> log error messages.
The image pointer comes straight from the API entry point and we
haven't been able to validate it until now. The purpose of the lookup
function is to do the validation that would normally happen at the API
entry point, log any errors and if everything is OK, return the driver
specific type (__DRIimage). This is the validation that you were
asking about in the other patch.
>> static __DRIbuffer *
>> dri2_get_buffers_with_format(__DRIdrawable * driDrawable,
>> int *width, int *height,
>> @@ -405,6 +438,7 @@ static struct dri2_extension_match dri2_driver_extensions[] = {
>> static struct dri2_extension_match dri2_core_extensions[] = {
>> { __DRI2_FLUSH, 1, offsetof(struct dri2_egl_display, flush) },
>> { __DRI_TEX_BUFFER, 2, offsetof(struct dri2_egl_display, tex_buffer) },
>> + { __DRI_IMAGE, 1, offsetof(struct dri2_egl_display, image) },
>> { NULL }
>> };
>>
>> @@ -609,8 +643,13 @@ dri2_initialize(_EGLDriver *drv, _EGLDisplay *disp,
>> dri2_dpy->loader_extension.getBuffersWithFormat = NULL;
>> }
>>
>> + dri2_dpy->image_lookup_extension.base.name = __DRI_IMAGE_LOOKUP;
>> + dri2_dpy->image_lookup_extension.base.version = 1;
>> + dri2_dpy->image_lookup_extension.lookupImage = dri2_lookup_image;
>> +
>> dri2_dpy->extensions[0] = &dri2_dpy->loader_extension.base;
>> - dri2_dpy->extensions[1] = NULL;
>> + dri2_dpy->extensions[1] = &dri2_dpy->image_lookup_extension.base;
>> + dri2_dpy->extensions[2] = NULL;
>>
>> dri2_dpy->dri_screen =
>> dri2_dpy->dri2->createNewScreen(0, dri2_dpy->fd, dri2_dpy->extensions,
>> @@ -1064,6 +1103,80 @@ dri2_release_tex_image(_EGLDriver *drv,
>> return EGL_TRUE;
>> }
>>
>> +static _EGLImage *
>> +dri2_create_image_khr(_EGLDriver *drv, _EGLDisplay *disp,
>> + _EGLContext *ctx, EGLenum target,
>> + EGLClientBuffer buffer, const EGLint *attr_list)
>> +{
>> + struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
>> + struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
>> + struct dri2_egl_image *dri2_img;
>> + unsigned int attachments[1];
>> + xcb_drawable_t drawable;
>> + xcb_dri2_get_buffers_cookie_t cookie;
>> + xcb_dri2_dri2_buffer_t *buffers;
>> + xcb_dri2_get_buffers_reply_t *reply;
>> +
>> + dri2_img = malloc(sizeof *dri2_img);
>> + if (!dri2_img) {
>> + _eglError(EGL_BAD_ALLOC, "dri2_create_image_khr");
>> + return EGL_NO_IMAGE_KHR;
>> + }
>> +
>> + if (!_eglInitImage(&dri2_img->base, disp, attr_list))
>> + return EGL_NO_IMAGE_KHR;
>> +
>> + switch (target) {
>> + case EGL_NATIVE_PIXMAP_KHR:
>> + drawable = (xcb_drawable_t) buffer;
>> + xcb_dri2_create_drawable (dri2_dpy->conn, drawable);
>> + attachments[0] = XCB_DRI2_ATTACHMENT_BUFFER_FRONT_LEFT;
>> + cookie = xcb_dri2_get_buffers_unchecked (dri2_dpy->conn,
>> + drawable, 1, 1, attachments);
>> + reply = xcb_dri2_get_buffers_reply (dri2_dpy->conn, cookie, NULL);
>> + buffers = xcb_dri2_get_buffers_buffers (reply);
>> + if (buffers == NULL) {
>> + free(dri2_img);
>> + return NULL;
>> + }
>> +
>> + dri2_img->width = reply->width;
>> + dri2_img->height = reply->height;
>> + dri2_img->name = buffers[0].name;
>> + dri2_img->pitch = buffers[0].pitch / buffers[0].cpp;
>> + dri2_img->cpp = buffers[0].cpp;
>> + free(reply);
>> + break;
>> +
>> + default:
>> + _eglError(EGL_BAD_PARAMETER, "dri2_create_image_khr");
>> + free(dri2_img);
>> + return EGL_NO_IMAGE_KHR;
>> + }
>> +
>> + dri2_img->dri_image =
>> + dri2_dpy->image->createImageFromName(dri2_ctx->dri_context,
>> + dri2_img->width,
>> + dri2_img->height,
>> + GL_RGBA,
>> + dri2_img->name,
>> + dri2_img->pitch,
>> + dri2_img);
>> +
>
> Since applications call this function directly, should this give an
> error if dri2_dpy->image is NULL, or is it okay to just segfault?
If __DRIimage isn't available, eglInitializeDisplay fails. I suppose
we should make that optional and just not advertise any EGLImage
extensions instead.
>> + return &dri2_img->base;
>> +}
>> +
>> +static EGLBoolean
>> +dri2_destroy_image_khr(_EGLDriver *drv, _EGLDisplay *disp, _EGLImage *image)
>> +{
>> + struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
>> + struct dri2_egl_image *dri2_img = dri2_egl_image(image);
>> +
>> + dri2_dpy->image->destroyImage(dri2_img->dri_image);
>> + free(dri2_img);
>> +
>> + return EGL_TRUE;
>> +}
>
> Ditto.
>
>>
>> /**
>> * This is the main entrypoint into the driver, called by libEGL.
>> @@ -1094,6 +1207,8 @@ _eglMain(const char *args)
>> dri2_drv->base.API.CopyBuffers = dri2_copy_buffers;
>> dri2_drv->base.API.BindTexImage = dri2_bind_tex_image;
>> dri2_drv->base.API.ReleaseTexImage = dri2_release_tex_image;
>> + dri2_drv->base.API.CreateImageKHR = dri2_create_image_khr;
>> + dri2_drv->base.API.DestroyImageKHR = dri2_destroy_image_khr;
>>
>> dri2_drv->base.Name = "DRI2";
>> dri2_drv->base.Unload = dri2_unload;
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkt1+TMACgkQX1gOwKyEAw8l0ACfYbuK1Oo+8x9rgnOfkfdtIIFy
> kNkAn0sOoggph3XPB2+7qWqkllZZiTCk
> =XEkO
> -----END PGP SIGNATURE-----
>
|
|
From: <bug...@fr...> - 2010-02-18 16:59:24
|
http://bugs.freedesktop.org/show_bug.cgi?id=26632 --- Comment #3 from Dan Nicholson <dbn...@gm...> 2010-02-18 08:59:17 PST --- Those all look good to me, although I wish someone would go through mklib and make it exit everywhere it could fail. Reviewed-by: Dan Nicholson <dbn...@gm...> If Brian doesn't pick these up, I can commit them soon. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
|
From: <bug...@fr...> - 2010-02-18 16:51:21
|
http://bugs.freedesktop.org/show_bug.cgi?id=26632 --- Comment #2 from Jon TURNEY <jon...@dr...> 2010-02-18 08:51:11 PST --- Created an attachment (id=33390) --> (http://bugs.freedesktop.org/attachment.cgi?id=33390) Patch to fix linkage of X11 libGL on cygwin -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. |
102 messages has been excluded from this view by a project administrator.
