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: Kristian H. <kr...@bi...> - 2010-07-16 12:11:43
|
On Fri, Jul 16, 2010 at 7:59 AM, Sedat Dilek <sed...@go...> wrote: > On Fri, Jul 16, 2010 at 1:43 PM, Chia-I Wu <ol...@gm...> wrote: >> On Wed, Jul 14, 2010 at 1:53 AM, Sedat Dilek <sed...@go...> wrote: >>> On Tue, Jul 13, 2010 at 5:25 PM, Sedat Dilek <sed...@go...> wrote: >>> [...] >>>> Shouldn't there be a more rough depend-checking on XCB_DRI2 >>>> (libxcb-1.6) in configure.ac? >>>> With "rough" I mean to stop immediately the build, so someone can >>>> check for the missing packages. >>>> >>> >>> Looking at [1] feom >>> >>> Commit 2168b87b51e70e8ad914e547c6c922fc33af3a89 >>> "egl_dri2: Support _EGL_PLATFORM_DRM" >>> >>> [configure.ac] >>> ... >>> # build egl_dri2 when xcb-dri2 is available >>> - PKG_CHECK_MODULES([EGL_DRI2], [x11-xcb xcb-dri2 xcb-xfixes libdrm], >>> + PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes], >>> [have_xcb_dri2=yes],[have_xcb_dri2=no]) >>> + PKG_CHECK_MODULES([LIBUDEV], [libudev > 150], >>> + [have_libudev=yes],[have_libudev=no]) >>> + >>> if test "$have_xcb_dri2" = yes; then >>> - EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS dri2" >>> + EGL_DRIVER_DRI2=dri2 >>> + DEFINES="$DEFINES -DHAVE_XCB_DRI2" >>> + fi >>> + >>> + if test "$have_libudev" = yes; then >>> + EGL_DRIVER_DRI2=dri2 >>> + DEFINES="$DEFINES -DHAVE_LIBUDEV" >>> fi >>> + >>> + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" >>> ... >>> >>> So if $have_xcb_dri2 is false, but $have_libudev true, >>> $EGL_DRIVER_DRI2 is set to "dri2" and the compilation of egl_dri2 will >>> be broken. >>> >>> What about...? >>> >>> - EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" >>> + if test "$have_xcb_dri2" = no; then >>> + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS" >>> + else >>> + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" >>> + fi >>> >>> - Sedat - >>> >>> [1] >>> http://cgit.freedesktop.org/mesa/mesa/diff/configure.ac?id=2168b87b51e70e8ad914e547c6c922fc33af3a89 >> I will commit a fix so that egl_dri2 is built only when xcb-dri2 is available. >> I believe Krisitian wants to make xcb-dri2 optional, but it does not seem to be >> the case right now. >> >> >> -- >> olv@LunarG.com >> > > Sounds good to me, thanks for your attention. Yup, sounds fine, thanks Chia-I. Kristian |
|
From: Sedat D. <sed...@go...> - 2010-07-16 12:00:05
|
On Fri, Jul 16, 2010 at 1:43 PM, Chia-I Wu <ol...@gm...> wrote: > On Wed, Jul 14, 2010 at 1:53 AM, Sedat Dilek <sed...@go...> wrote: >> On Tue, Jul 13, 2010 at 5:25 PM, Sedat Dilek <sed...@go...> wrote: >> [...] >>> Shouldn't there be a more rough depend-checking on XCB_DRI2 >>> (libxcb-1.6) in configure.ac? >>> With "rough" I mean to stop immediately the build, so someone can >>> check for the missing packages. >>> >> >> Looking at [1] feom >> >> Commit 2168b87b51e70e8ad914e547c6c922fc33af3a89 >> "egl_dri2: Support _EGL_PLATFORM_DRM" >> >> [configure.ac] >> ... >> # build egl_dri2 when xcb-dri2 is available >> - PKG_CHECK_MODULES([EGL_DRI2], [x11-xcb xcb-dri2 xcb-xfixes libdrm], >> + PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes], >> [have_xcb_dri2=yes],[have_xcb_dri2=no]) >> + PKG_CHECK_MODULES([LIBUDEV], [libudev > 150], >> + [have_libudev=yes],[have_libudev=no]) >> + >> if test "$have_xcb_dri2" = yes; then >> - EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS dri2" >> + EGL_DRIVER_DRI2=dri2 >> + DEFINES="$DEFINES -DHAVE_XCB_DRI2" >> + fi >> + >> + if test "$have_libudev" = yes; then >> + EGL_DRIVER_DRI2=dri2 >> + DEFINES="$DEFINES -DHAVE_LIBUDEV" >> fi >> + >> + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" >> ... >> >> So if $have_xcb_dri2 is false, but $have_libudev true, >> $EGL_DRIVER_DRI2 is set to "dri2" and the compilation of egl_dri2 will >> be broken. >> >> What about...? >> >> - EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" >> + if test "$have_xcb_dri2" = no; then >> + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS" >> + else >> + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" >> + fi >> >> - Sedat - >> >> [1] >> http://cgit.freedesktop.org/mesa/mesa/diff/configure.ac?id=2168b87b51e70e8ad914e547c6c922fc33af3a89 > I will commit a fix so that egl_dri2 is built only when xcb-dri2 is available. > I believe Krisitian wants to make xcb-dri2 optional, but it does not seem to be > the case right now. > > > -- > olv@LunarG.com > Sounds good to me, thanks for your attention. - Sedat - |
|
From: Chia-I Wu <ol...@gm...> - 2010-07-16 11:43:53
|
On Wed, Jul 14, 2010 at 1:53 AM, Sedat Dilek <sed...@go...> wrote: > On Tue, Jul 13, 2010 at 5:25 PM, Sedat Dilek <sed...@go...> wrote: > [...] >> Shouldn't there be a more rough depend-checking on XCB_DRI2 >> (libxcb-1.6) in configure.ac? >> With "rough" I mean to stop immediately the build, so someone can >> check for the missing packages. >> > > Looking at [1] feom > > Commit 2168b87b51e70e8ad914e547c6c922fc33af3a89 > "egl_dri2: Support _EGL_PLATFORM_DRM" > > [configure.ac] > ... > # build egl_dri2 when xcb-dri2 is available > - PKG_CHECK_MODULES([EGL_DRI2], [x11-xcb xcb-dri2 xcb-xfixes libdrm], > + PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes], > [have_xcb_dri2=yes],[have_xcb_dri2=no]) > + PKG_CHECK_MODULES([LIBUDEV], [libudev > 150], > + [have_libudev=yes],[have_libudev=no]) > + > if test "$have_xcb_dri2" = yes; then > - EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS dri2" > + EGL_DRIVER_DRI2=dri2 > + DEFINES="$DEFINES -DHAVE_XCB_DRI2" > + fi > + > + if test "$have_libudev" = yes; then > + EGL_DRIVER_DRI2=dri2 > + DEFINES="$DEFINES -DHAVE_LIBUDEV" > fi > + > + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" > ... > > So if $have_xcb_dri2 is false, but $have_libudev true, > $EGL_DRIVER_DRI2 is set to "dri2" and the compilation of egl_dri2 will > be broken. > > What about...? > > - EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" > + if test "$have_xcb_dri2" = no; then > + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS" > + else > + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" > + fi > > - Sedat - > > [1] > http://cgit.freedesktop.org/mesa/mesa/diff/configure.ac?id=2168b87b51e70e8ad914e547c6c922fc33af3a89 I will commit a fix so that egl_dri2 is built only when xcb-dri2 is available. I believe Krisitian wants to make xcb-dri2 optional, but it does not seem to be the case right now. -- olv@LunarG.com |
|
From: Sedat D. <sed...@go...> - 2010-07-13 17:53:41
|
On Tue, Jul 13, 2010 at 5:25 PM, Sedat Dilek <sed...@go...> wrote: [...] > Shouldn't there be a more rough depend-checking on XCB_DRI2 > (libxcb-1.6) in configure.ac? > With "rough" I mean to stop immediately the build, so someone can > check for the missing packages. > Looking at [1] feom Commit 2168b87b51e70e8ad914e547c6c922fc33af3a89 "egl_dri2: Support _EGL_PLATFORM_DRM" [configure.ac] ... # build egl_dri2 when xcb-dri2 is available - PKG_CHECK_MODULES([EGL_DRI2], [x11-xcb xcb-dri2 xcb-xfixes libdrm], + PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes], [have_xcb_dri2=yes],[have_xcb_dri2=no]) + PKG_CHECK_MODULES([LIBUDEV], [libudev > 150], + [have_libudev=yes],[have_libudev=no]) + if test "$have_xcb_dri2" = yes; then - EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS dri2" + EGL_DRIVER_DRI2=dri2 + DEFINES="$DEFINES -DHAVE_XCB_DRI2" + fi + + if test "$have_libudev" = yes; then + EGL_DRIVER_DRI2=dri2 + DEFINES="$DEFINES -DHAVE_LIBUDEV" fi + + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" ... So if $have_xcb_dri2 is false, but $have_libudev true, $EGL_DRIVER_DRI2 is set to "dri2" and the compilation of egl_dri2 will be broken. What about...? - EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" + if test "$have_xcb_dri2" = no; then + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS" + else + EGL_DRIVERS_DIRS="$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2" + fi - Sedat - [1] http://cgit.freedesktop.org/mesa/mesa/diff/configure.ac?id=2168b87b51e70e8ad914e547c6c922fc33af3a89 |
|
From: Sedat D. <sed...@go...> - 2010-07-13 15:26:59
|
Hi,
I was trying to build a mesa snapshot from GIT master and egl_dri2
seems to be broken on first sight (see below for build.log).
As egl_dri2 is build by-default, you can "workaround" the problem by
setting explicitly --disable-egl to configure-line.
Alternatively, for example Debian-systems (tested on sid 32-bit) please install:
# apt-get install libxcb-xfixes0-dev libxcb-dri2-0-dev
Shouldn't there be a more rough depend-checking on XCB_DRI2
(libxcb-1.6) in configure.ac?
With "rough" I mean to stop immediately the build, so someone can
check for the missing packages.
Kind Regards,
- Sedat -
[build.log]
...
checking for XCB_DRI2... no
Use XCB: no
...
make[4]: Entering directory `/home/sd/src/mesa/mesa/src/egl/drivers/dri2'
ccache gcc -c -I../../../../include -I../../../../src/egl/main
-I../../../../src/mapi -DDEFAULT_DRIVER_DIR=\"/usr/lib/dri\"
-I/usr/include/libdrm -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
-DHAVE_LIBUDEV egl_dri2.c -o egl_dri2.o
egl_dri2.c:40:22: error: xcb/dri2.h: No such file or directory
egl_dri2.c:41:24: error: xcb/xfixes.h: No such file or directory
egl_dri2.c:104: error: expected specifier-qualifier-list before
'xcb_xfixes_region_t'
egl_dri2.c:292: error: expected declaration specifiers or '...' before
'xcb_dri2_dri2_buffer_t'
egl_dri2.c: In function 'dri2_process_buffers':
egl_dri2.c:300: error: 'struct dri2_egl_surface' has no member named
'have_fake_front'
egl_dri2.c:305: error: 'buffers' undeclared (first use in this function)
egl_dri2.c:305: error: (Each undeclared identifier is reported only once
egl_dri2.c:305: error: for each function it appears in.)
egl_dri2.c:317: error: 'struct dri2_egl_surface' has no member named
'have_fake_front'
egl_dri2.c:320: error: 'struct dri2_egl_surface' has no member named 'region'
egl_dri2.c:321: warning: implicit declaration of function
'xcb_xfixes_destroy_region'
egl_dri2.c:321: error: 'struct dri2_egl_surface' has no member named 'region'
egl_dri2.c:327: error: 'struct dri2_egl_surface' has no member named 'region'
egl_dri2.c:328: warning: implicit declaration of function
'xcb_xfixes_create_region'
egl_dri2.c:328: error: 'struct dri2_egl_surface' has no member named 'region'
egl_dri2.c: In function 'dri2_get_buffers':
egl_dri2.c:340: error: 'xcb_dri2_dri2_buffer_t' undeclared (first use
in this function)
egl_dri2.c:340: error: 'buffers' undeclared (first use in this function)
egl_dri2.c:341: error: 'xcb_dri2_get_buffers_reply_t' undeclared
(first use in this function)
egl_dri2.c:341: error: 'reply' undeclared (first use in this function)
egl_dri2.c:342: error: 'xcb_dri2_get_buffers_cookie_t' undeclared
(first use in this function)
egl_dri2.c:342: error: expected ';' before 'cookie'
egl_dri2.c:344: error: 'cookie' undeclared (first use in this function)
egl_dri2.c:344: warning: implicit declaration of function
'xcb_dri2_get_buffers_unchecked'
egl_dri2.c:347: warning: implicit declaration of function
'xcb_dri2_get_buffers_reply'
egl_dri2.c:348: warning: implicit declaration of function
'xcb_dri2_get_buffers_buffers'
egl_dri2.c:355: error: too many arguments to function 'dri2_process_buffers'
egl_dri2.c: In function 'dri2_get_buffers_with_format':
egl_dri2.c:407: error: 'xcb_dri2_dri2_buffer_t' undeclared (first use
in this function)
egl_dri2.c:407: error: 'buffers' undeclared (first use in this function)
egl_dri2.c:408: error: 'xcb_dri2_get_buffers_with_format_reply_t'
undeclared (first use in this function)
egl_dri2.c:408: error: 'reply' undeclared (first use in this function)
egl_dri2.c:409: error: 'xcb_dri2_get_buffers_with_format_cookie_t'
undeclared (first use in this function)
egl_dri2.c:409: error: expected ';' before 'cookie'
egl_dri2.c:410: error: 'xcb_dri2_attach_format_t' undeclared (first
use in this function)
egl_dri2.c:410: error: 'format_attachments' undeclared (first use in
this function)
egl_dri2.c:412: error: expected expression before ')' token
egl_dri2.c:413: error: 'cookie' undeclared (first use in this function)
egl_dri2.c:413: warning: implicit declaration of function
'xcb_dri2_get_buffers_with_format_unchecked'
egl_dri2.c:418: warning: implicit declaration of function
'xcb_dri2_get_buffers_with_format_reply'
egl_dri2.c:423: warning: implicit declaration of function
'xcb_dri2_get_buffers_with_format_buffers'
egl_dri2.c:427: error: too many arguments to function 'dri2_process_buffers'
egl_dri2.c: In function 'dri2_connect':
egl_dri2.c:506: error: 'xcb_xfixes_query_version_reply_t' undeclared
(first use in this function)
egl_dri2.c:506: error: 'xfixes_query' undeclared (first use in this function)
egl_dri2.c:507: error: 'xcb_xfixes_query_version_cookie_t' undeclared
(first use in this function)
egl_dri2.c:507: error: expected ';' before 'xfixes_query_cookie'
egl_dri2.c:508: error: 'xcb_dri2_query_version_reply_t' undeclared
(first use in this function)
egl_dri2.c:508: error: 'dri2_query' undeclared (first use in this function)
egl_dri2.c:509: error: 'xcb_dri2_query_version_cookie_t' undeclared
(first use in this function)
egl_dri2.c:509: error: expected ';' before 'dri2_query_cookie'
egl_dri2.c:510: error: 'xcb_dri2_connect_reply_t' undeclared (first
use in this function)
egl_dri2.c:510: error: 'connect' undeclared (first use in this function)
egl_dri2.c:511: error: 'xcb_dri2_connect_cookie_t' undeclared (first
use in this function)
egl_dri2.c:511: error: expected ';' before 'connect_cookie'
egl_dri2.c:515: error: 'xcb_xfixes_id' undeclared (first use in this function)
egl_dri2.c:516: error: 'xcb_dri2_id' undeclared (first use in this function)
egl_dri2.c:518: error: 'xfixes_query_cookie' undeclared (first use in
this function)
egl_dri2.c:518: warning: implicit declaration of function
'xcb_xfixes_query_version'
egl_dri2.c:519: error: 'XCB_XFIXES_MAJOR_VERSION' undeclared (first
use in this function)
egl_dri2.c:520: error: 'XCB_XFIXES_MINOR_VERSION' undeclared (first
use in this function)
egl_dri2.c:522: error: 'dri2_query_cookie' undeclared (first use in
this function)
egl_dri2.c:522: warning: implicit declaration of function
'xcb_dri2_query_version'
egl_dri2.c:523: error: 'XCB_DRI2_MAJOR_VERSION' undeclared (first use
in this function)
egl_dri2.c:524: error: 'XCB_DRI2_MINOR_VERSION' undeclared (first use
in this function)
egl_dri2.c:527: error: 'connect_cookie' undeclared (first use in this function)
egl_dri2.c:527: warning: implicit declaration of function
'xcb_dri2_connect_unchecked'
egl_dri2.c:529: error: 'XCB_DRI2_DRIVER_TYPE_DRI' undeclared (first
use in this function)
egl_dri2.c:532: warning: implicit declaration of function
'xcb_xfixes_query_version_reply'
egl_dri2.c:543: warning: implicit declaration of function
'xcb_dri2_query_version_reply'
egl_dri2.c:553: warning: implicit declaration of function
'xcb_dri2_connect_reply'
egl_dri2.c:561: warning: implicit declaration of function
'xcb_dri2_connect_device_name'
egl_dri2.c:562: warning: implicit declaration of function
'xcb_dri2_connect_device_name_length'
egl_dri2.c:565: warning: implicit declaration of function
'xcb_dri2_connect_driver_name'
egl_dri2.c:566: warning: implicit declaration of function
'xcb_dri2_connect_driver_name_length'
egl_dri2.c: In function 'dri2_authenticate':
egl_dri2.c:582: error: 'xcb_dri2_authenticate_reply_t' undeclared
(first use in this function)
egl_dri2.c:582: error: 'authenticate' undeclared (first use in this function)
egl_dri2.c:583: error: 'xcb_dri2_authenticate_cookie_t' undeclared
(first use in this function)
egl_dri2.c:583: error: expected ';' before 'authenticate_cookie'
egl_dri2.c:593: error: 'authenticate_cookie' undeclared (first use in
this function)
egl_dri2.c:594: warning: implicit declaration of function
'xcb_dri2_authenticate_unchecked'
egl_dri2.c:596: warning: implicit declaration of function
'xcb_dri2_authenticate_reply'
egl_dri2.c: In function 'dri2_destroy_surface':
egl_dri2.c:1117: warning: implicit declaration of function
'xcb_dri2_destroy_drawable'
egl_dri2.c: In function 'dri2_create_surface':
egl_dri2.c:1196: error: 'struct dri2_egl_surface' has no member named 'region'
egl_dri2.c:1216: warning: implicit declaration of function
'xcb_dri2_create_drawable'
egl_dri2.c: At top level:
egl_dri2.c:1276: error: expected declaration specifiers or '...'
before 'xcb_xfixes_region_t'
egl_dri2.c: In function 'dri2_copy_region':
egl_dri2.c:1282: error: 'xcb_dri2_copy_region_cookie_t' undeclared
(first use in this function)
egl_dri2.c:1282: error: expected ';' before 'cookie'
egl_dri2.c:1303: error: 'struct dri2_egl_surface' has no member named
'have_fake_front'
egl_dri2.c:1306: error: 'cookie' undeclared (first use in this function)
egl_dri2.c:1306: warning: implicit declaration of function
'xcb_dri2_copy_region_unchecked'
egl_dri2.c:1308: error: 'region' undeclared (first use in this function)
egl_dri2.c:1309: error: 'XCB_DRI2_ATTACHMENT_BUFFER_FRONT_LEFT'
undeclared (first use in this function)
egl_dri2.c:1310: error: 'XCB_DRI2_ATTACHMENT_BUFFER_FAKE_FRONT_LEFT'
undeclared (first use in this function)
egl_dri2.c:1311: warning: implicit declaration of function
'xcb_dri2_copy_region_reply'
egl_dri2.c: In function 'dri2_swap_buffers':
#!/bin/bash
egl_dri2.c:1321: error: 'struct dri2_egl_surface' has no member named 'region'
egl_dri2.c:1321: error: too many arguments to function 'dri2_copy_region'
egl_dri2.c: In function 'dri2_swap_buffers_region':
egl_dri2.c:1331: error: 'xcb_xfixes_region_t' undeclared (first use in
this function)
egl_dri2.c:1331: error: expected ';' before 'region'
egl_dri2.c:1336: error: 'struct dri2_egl_surface' has no member named 'region'
egl_dri2.c:1336: error: too many arguments to function 'dri2_copy_region'
egl_dri2.c:1346: error: 'region' undeclared (first use in this function)
egl_dri2.c:1348: error: too many arguments to function 'dri2_copy_region'
egl_dri2.c: In function 'dri2_create_image_khr_pixmap':
egl_dri2.c:1479: error: 'xcb_dri2_get_buffers_cookie_t' undeclared
(first use in this function)
egl_dri2.c:1479: error: expected ';' before 'buffers_cookie'
egl_dri2.c:1480: error: 'xcb_dri2_get_buffers_reply_t' undeclared
(first use in this function)
egl_dri2.c:1480: error: 'buffers_reply' undeclared (first use in this function)
egl_dri2.c:1481: error: 'xcb_dri2_dri2_buffer_t' undeclared (first use
in this function)
egl_dri2.c:1481: error: 'buffers' undeclared (first use in this function)
egl_dri2.c:1489: error: 'XCB_DRI2_ATTACHMENT_BUFFER_FRONT_LEFT'
undeclared (first use in this function)
egl_dri2.c:1490: error: 'buffers_cookie' undeclared (first use in this function)
make[4]: *** [egl_dri2.o] Error 1
make[4]: Leaving directory `/home/sd/src/mesa/mesa/src/egl/drivers/dri2'
make[3]: *** [subdirs] Error 1
make[3]: Leaving directory `/home/sd/src/mesa/mesa/src/egl/drivers'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/home/sd/src/mesa/mesa/src/egl'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/sd/src/mesa/mesa/src'
make: *** [default] Error 1
real 2m25.097s
user 3m46.417s
sys 0m18.615s
[1]+ Exit 2 ./build_mesa-with-gallium-radeon.sh >
build.log 2>&1
|
|
From: Brian P. <br...@vm...> - 2010-07-02 15:41:59
|
Matej Urbas wrote: > Hi, > > I am trying to build mesa. I did this: > > ./autogen.sh > gmake > > All dependencies are satisfied and 'autoreconf' passes without > complaints. > > However, I get the following build-time error: > > mklib: Making Linux shared library: i810_dri.so.tmp > gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math > -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM > -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE > -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 > -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING > -DHAVE_ALIAS -DFEATURE_GL=1 -o > i810_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o i810_dri.so.tmp -ldrm -lexpat -lm -lpthread -ldl > i810_dri.so.tmp: undefined reference to `sl_pp_version' > i810_dri.so.tmp: undefined reference to `sl_pp_context_destroy' > i810_dri.so.tmp: undefined reference to `sl_cl_compile' > i810_dri.so.tmp: undefined reference to `sl_pp_context_create' > i810_dri.so.tmp: undefined reference to > `sl_pp_context_error_message' > i810_dri.so.tmp: undefined reference to > `sl_pp_context_add_extension' > collect2: ld returned 1 exit status > gmake[6]: *** [i810_dri.so] Error 1 > gmake[6]: Leaving directory > `myfolder/mesa/src/mesa/drivers/dri/i810' > gmake[5]: *** [lib] Error 2 > gmake[5]: Leaving directory > `myfolder/mesa/src/mesa/drivers/dri/i810' > gmake[4]: *** [subdirs] Error 1 > gmake[4]: Leaving directory `myfolder/mesa/src/mesa/drivers/dri' > gmake[3]: *** [default] Error 1 > gmake[3]: Leaving directory `myfolder/mesa/src/mesa/drivers' > gmake[2]: *** [driver_subdirs] Error 2 > gmake[2]: Leaving directory `myfolder/mesa/src/mesa' > gmake[1]: *** [subdirs] Error 1 > gmake[1]: Leaving directory `myfolder/mesa/src' > gmake: *** [default] Error 1 > > Could I please ask you for some info on how to alleviate the problem? Nobody else has reported this, AFAIK. Did you try a 'make clean' first? -Brian |
|
From: Maxim L. <max...@gm...> - 2010-06-30 23:13:34
|
On Tue, 2010-06-29 at 15:49 -0700, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Corbin Simpson wrote: > > Curious. Admittedly I can't look at the content of that commit, but they > > can't be too useless if compiz selects them. IIRC the point was to limit > > the runtime of Intel internal tests; can't those tests be amended > > instead? The number of configs will only grow; r300g has over 200 now > > thanks to multisampling. > > The configs are useless. Applications can only ask for "bits >= X". > There are still 24-bit depth / 8-bit stencil configs, and, last time I > checked, 8 >= 0. There is no way to ask for a 24/0 config that wouldn't > instead give a 24/8 config. > > > Posting from a mobile, pardon my terseness. ~ C. > > > >> On Jun 29, 2010 1:28 PM, "Maxim Levitsky" <max...@gm... > >> <mailto:max...@gm...>> wrote: > >> > >> On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote: > >> > On Sun, 2010-06-27 at 19:07 +0300, Maxim ... > >> > >> Bisected this to > >> > >> 73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit > >> commit 73e24cd5a7a0760726a681dda5b88805ddcf1555 > >> Author: Ian Romanick <ian...@in... > >> <mailto:ian...@in...>> > >> Date: Mon Feb 8 10:34:52 2010 -0800 > >> > >> intel: Stop exposing useless 24 depth/0 stencil configs > > I need two pieces of information: > > - A diff of the output of glxinfo immediately before and immediately > after this commit. > > - A list of what config attributes compiz is requesting. It should > be easy enough to instrument choose_visual in glxcmds.c to dump out > attribList. > > It should be pretty easy to root-cause this problem with that data. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkwqeGwACgkQX1gOwKyEAw9MfQCZAUWS6wXUjRWYaX++6YRjl4Pk > XMsAn06cgcjJf/dDMCBDTr/tdaFoBsGM > =rGTt > -----END PGP SIGNATURE----- --- ./glxinfo_good 2010-07-01 02:01:08.332346000 +0300 +++ ./glxinfo_bad 2010-07-01 02:01:28.115633852 +0300 @@ -84,7 +84,7 @@ GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays, GL_OES_EGL_image -28 GLX Visuals +20 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- @@ -92,32 +92,24 @@ 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0xe3 24 tc 0 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0xe5 24 tc 0 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None -0xeb 24 tc 0 24 0 r . . 8 8 8 0 0 24 0 0 0 0 0 0 0 None -0xed 24 tc 0 24 0 r y . 8 8 8 0 0 24 0 0 0 0 0 0 0 None 0xef 24 tc 0 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0xf1 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0xf2 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0xf3 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0xf5 24 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None -0xfb 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0xfe 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x100 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x101 24 dc 0 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0x103 24 dc 0 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None -0x109 24 dc 0 24 0 r . . 8 8 8 0 0 24 0 0 0 0 0 0 0 None -0x10b 24 dc 0 24 0 r y . 8 8 8 0 0 24 0 0 0 0 0 0 0 None 0x10d 24 dc 0 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x10f 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x110 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0x111 24 dc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x113 24 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None -0x119 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None -0x11b 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x11d 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x11f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow -0x62 32 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None -38 GLXFBConfigs: +30 GLXFBConfigs: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- @@ -128,15 +120,11 @@ 0x7e 0 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x83 0 tc 0 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0x85 0 tc 0 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None -0x8b 0 tc 0 24 0 r . . 8 8 8 0 0 24 0 0 0 0 0 0 0 None -0x8d 0 tc 0 24 0 r y . 8 8 8 0 0 24 0 0 0 0 0 0 0 None 0x8f 0 tc 0 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x91 0 tc 0 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x92 0 tc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0x93 0 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x95 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None -0x9b 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None -0x9d 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x9f 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0xa1 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0xa2 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow @@ -147,15 +135,11 @@ 0xbe 0 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0xc3 0 dc 0 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0xc5 0 dc 0 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None -0xcb 0 dc 0 24 0 r . . 8 8 8 0 0 24 0 0 0 0 0 0 0 None -0xcd 0 dc 0 24 0 r y . 8 8 8 0 0 24 0 0 0 0 0 0 0 None 0xcf 0 dc 0 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0xd1 0 dc 0 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0xd2 0 dc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0xd3 0 dc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0xd5 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None -0xdb 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None -0xdd 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0xdf 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0xe1 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0xe2 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow What is interesting is this: -0x62 32 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None This is only visual with depth==32, and it is removed. Compiz complained about depth 32... Best regards, Maxim Levitsky |
|
From: Ian R. <id...@fr...> - 2010-06-29 23:13:38
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Corbin Simpson wrote:
> Curious. Admittedly I can't look at the content of that commit, but they
> can't be too useless if compiz selects them. IIRC the point was to limit
> the runtime of Intel internal tests; can't those tests be amended
> instead? The number of configs will only grow; r300g has over 200 now
> thanks to multisampling.
The configs are useless. Applications can only ask for "bits >= X".
There are still 24-bit depth / 8-bit stencil configs, and, last time I
checked, 8 >= 0. There is no way to ask for a 24/0 config that wouldn't
instead give a 24/8 config.
> Posting from a mobile, pardon my terseness. ~ C.
>
>> On Jun 29, 2010 1:28 PM, "Maxim Levitsky" <max...@gm...
>> <mailto:max...@gm...>> wrote:
>>
>> On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote:
>> > On Sun, 2010-06-27 at 19:07 +0300, Maxim ...
>>
>> Bisected this to
>>
>> 73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
>> commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
>> Author: Ian Romanick <ian...@in...
>> <mailto:ian...@in...>>
>> Date: Mon Feb 8 10:34:52 2010 -0800
>>
>> intel: Stop exposing useless 24 depth/0 stencil configs
I need two pieces of information:
- A diff of the output of glxinfo immediately before and immediately
after this commit.
- A list of what config attributes compiz is requesting. It should
be easy enough to instrument choose_visual in glxcmds.c to dump out
attribList.
It should be pretty easy to root-cause this problem with that data.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwqeGwACgkQX1gOwKyEAw9MfQCZAUWS6wXUjRWYaX++6YRjl4Pk
XMsAn06cgcjJf/dDMCBDTr/tdaFoBsGM
=rGTt
-----END PGP SIGNATURE-----
|
|
From: Corbin S. <mos...@gm...> - 2010-06-29 20:47:25
|
Curious. Admittedly I can't look at the content of that commit, but they
can't be too useless if compiz selects them. IIRC the point was to limit the
runtime of Intel internal tests; can't those tests be amended instead? The
number of configs will only grow; r300g has over 200 now thanks to
multisampling.
Posting from a mobile, pardon my terseness. ~ C.
On Jun 29, 2010 1:28 PM, "Maxim Levitsky" <max...@gm...> wrote:
On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote:
> On Sun, 2010-06-27 at 19:07 +0300, Maxim ...
Bisected this to
73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
Author: Ian Romanick <ian...@in...>
Date: Mon Feb 8 10:34:52 2010 -0800
intel: Stop exposing useless 24 depth/0 stencil configs
Signed-off-by: Ian Romanick <ian...@in...>
Reviewed-by: Kristian Høgsberg <kr...@bi...>
:040000 040000 5ba858b23d6502d9eaa39a8ec612a38ffae50e2c
0060acef28a49d519aed5a21cbde2bc833f840a8 M src
Reverting this, and removing one assert, fixes compiz
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 61803cf..0f6d1da 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -306,7 +306,7 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
}
if (mesaVis->depthBits == 24) {
- assert(mesaVis->stencilBits == 8);
+ //assert(mesaVis->stencilBits == 8);
/* combined depth/stencil buffer */
struct intel_renderbuffer *depthStencilRb
= intel_create_renderbuffer(MESA_FORMAT_S8_Z24);
Best regards,
Maxim Levitsku
------------------------------------------------------------------------------
This SF.net email i...
|
|
From: Maxim L. <max...@gm...> - 2010-06-29 20:27:53
|
On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote:
> On Sun, 2010-06-27 at 19:07 +0300, Maxim Levitsky wrote:
> > Hi,
> >
> > Today I updated the graphical modules from long time ago.
> >
> > Do you know what causes this:
> >
> > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
> > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
> > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
> > WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug!
> > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
> > /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x4000fb to texture
> >
> > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
> > /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x3a00016 to texture
> >
> > /usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format
> > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
> > /usr/bin/compiz.real (resizeinfo) - Warn: Bind Pixmap to Texture failure
> > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
> > /usr/bin/compiz.real (resizeinfo) - Warn: Bind Pixmap to Texture failure
> > /usr/bin/compiz.real (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png
> > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
> > /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x4000fb to texture
> >
> > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32
> > /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x3a00016 to texture
> >
> >
> > The 'good' output was:
> >
> > ....
> > Checking for Xgl: not present.
> > WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug!
> > /usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format
> > /usr/bin/compiz.real (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png
> > WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug!
> >
> >
> >
> >
> > As a result of this, most windows are white, and decorations are missing.
> >
> >
> > glxinfo output indeed shrunk indeed, so maybe this is result of removal of many glx visuals?
> >
> >
> > I attach glxinfo output from bad and good versions of mesa.
> >
> > You will see that I didn't update the stack for some prolonged time, so bisect would be painful.
> >
> >
> > Best regards,
> > Maxim Levitsky
>
Bisected this to
73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
Author: Ian Romanick <ian...@in...>
Date: Mon Feb 8 10:34:52 2010 -0800
intel: Stop exposing useless 24 depth/0 stencil configs
Signed-off-by: Ian Romanick <ian...@in...>
Reviewed-by: Kristian Høgsberg <kr...@bi...>
:040000 040000 5ba858b23d6502d9eaa39a8ec612a38ffae50e2c 0060acef28a49d519aed5a21cbde2bc833f840a8 M src
Reverting this, and removing one assert, fixes compiz
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c b/src/mesa/drivers/dri/intel/intel_screen.c
index 61803cf..0f6d1da 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -306,7 +306,7 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
}
if (mesaVis->depthBits == 24) {
- assert(mesaVis->stencilBits == 8);
+ //assert(mesaVis->stencilBits == 8);
/* combined depth/stencil buffer */
struct intel_renderbuffer *depthStencilRb
= intel_create_renderbuffer(MESA_FORMAT_S8_Z24);
Best regards,
Maxim Levitsku
|
|
From: Maxim L. <max...@gm...> - 2010-06-29 17:34:13
|
On Sun, 2010-06-27 at 19:07 +0300, Maxim Levitsky wrote: > Hi, > > Today I updated the graphical modules from long time ago. > > Do you know what causes this: > > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 > WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug! > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 > /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x4000fb to texture > > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 > /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x3a00016 to texture > > /usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 > /usr/bin/compiz.real (resizeinfo) - Warn: Bind Pixmap to Texture failure > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 > /usr/bin/compiz.real (resizeinfo) - Warn: Bind Pixmap to Texture failure > /usr/bin/compiz.real (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 > /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x4000fb to texture > > /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 > /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x3a00016 to texture > > > The 'good' output was: > > .... > Checking for Xgl: not present. > WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug! > /usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format > /usr/bin/compiz.real (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png > WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug! > > > > > As a result of this, most windows are white, and decorations are missing. > > > glxinfo output indeed shrunk indeed, so maybe this is result of removal of many glx visuals? > > > I attach glxinfo output from bad and good versions of mesa. > > You will see that I didn't update the stack for some prolonged time, so bisect would be painful. > > > Best regards, > Maxim Levitsky ping |
|
From: Maxim L. <max...@gm...> - 2010-06-27 16:07:25
|
Hi, Today I updated the graphical modules from long time ago. Do you know what causes this: /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug! /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x4000fb to texture /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x3a00016 to texture /usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (resizeinfo) - Warn: Bind Pixmap to Texture failure /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (resizeinfo) - Warn: Bind Pixmap to Texture failure /usr/bin/compiz.real (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x4000fb to texture /usr/bin/compiz.real (core) - Warn: No GLXFBConfig for depth 32 /usr/bin/compiz.real (core) - Info: Couldn't bind redirected window 0x3a00016 to texture The 'good' output was: .... Checking for Xgl: not present. WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug! /usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format /usr/bin/compiz.real (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug! As a result of this, most windows are white, and decorations are missing. glxinfo output indeed shrunk indeed, so maybe this is result of removal of many glx visuals? I attach glxinfo output from bad and good versions of mesa. You will see that I didn't update the stack for some prolonged time, so bisect would be painful. Best regards, Maxim Levitsky |
|
From: Matej U. <mat...@gm...> - 2010-06-27 09:28:13
|
Hi,
I am trying to build mesa. I did this:
./autogen.sh
gmake
All dependencies are satisfied and 'autoreconf' passes without
complaints.
However, I get the following build-time error:
mklib: Making Linux shared library: i810_dri.so.tmp
gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING
-DHAVE_ALIAS -DFEATURE_GL=1 -o
i810_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o i810_dri.so.tmp -ldrm -lexpat -lm -lpthread -ldl
i810_dri.so.tmp: undefined reference to `sl_pp_version'
i810_dri.so.tmp: undefined reference to `sl_pp_context_destroy'
i810_dri.so.tmp: undefined reference to `sl_cl_compile'
i810_dri.so.tmp: undefined reference to `sl_pp_context_create'
i810_dri.so.tmp: undefined reference to
`sl_pp_context_error_message'
i810_dri.so.tmp: undefined reference to
`sl_pp_context_add_extension'
collect2: ld returned 1 exit status
gmake[6]: *** [i810_dri.so] Error 1
gmake[6]: Leaving directory
`myfolder/mesa/src/mesa/drivers/dri/i810'
gmake[5]: *** [lib] Error 2
gmake[5]: Leaving directory
`myfolder/mesa/src/mesa/drivers/dri/i810'
gmake[4]: *** [subdirs] Error 1
gmake[4]: Leaving directory `myfolder/mesa/src/mesa/drivers/dri'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `myfolder/mesa/src/mesa/drivers'
gmake[2]: *** [driver_subdirs] Error 2
gmake[2]: Leaving directory `myfolder/mesa/src/mesa'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `myfolder/mesa/src'
gmake: *** [default] Error 1
Could I please ask you for some info on how to alleviate the problem?
Thank you very much!
Regards
---
Matej
|
|
From: nitesh s. <nit...@gm...> - 2010-06-19 04:23:02
|
On Fri, Jun 18, 2010 at 10:06 PM, Jerome Glisse <gl...@fr...>wrote: > On Fri, Jun 18, 2010 at 08:40:35PM +0530, nitesh suthar wrote: > > Hello All > > > > I want to continue to write DRI Driver s3c6410. > > > > For now I have complete user manual of that hardware. > > > > I have kernel side driver & code for hardware call. > > > > A user space compiled shaired library. > > > > I am able to compile opengl-es application and run over board easily. > > > > What would be easiest way to convert that library or link that shared > > library to work with Mesa ? > > > > or Does mesa provide any framework where I just need to make hardware > call > > fur functions ? > > > > Please suggest us some idea or link where we could start developing Mesa > lib > > for s3c6410. > > > > > > Thanks &Regards > > > > Nitesh Suthar > > Software Developer and IT Engineer > > (Prosoftworld Pvt Lt.) > > Do you want to reimplement a full opensource driver using mesa ? If > so you can forget about the GL ES library you are using and start > looking at how to implement a driver in mesa from scratch (this is > a complex and time consuming task) First you will have to choose > btw classic mesa or gallium, if your hw support glsl shader then > you should choose gallium (looks at src/gallium/drivers for example). > > Also it's not clear what kind of documentation you have, does user > manual you have cover hw and how to program it ? (not how to use > the library provided). > > Maybe if you tell us why you want to do a mesa driver it would allow > us to give you more proper advices. > > Cheers, > Jerome > Our objective is to design UI using GtkGlExt , GLES and Clutter. and all those goes through x-window and mesa structure we have user manual which cover hardware and also have driver source code. so is it possible to write driver from scratch ? but first preferrence would be just call exist shared library from mesa library. so how could we achieve this ? , let us know if any other suggestion thanks & regards Nitesh |
|
From: Jerome G. <gl...@fr...> - 2010-06-18 16:36:13
|
On Fri, Jun 18, 2010 at 08:40:35PM +0530, nitesh suthar wrote: > Hello All > > I want to continue to write DRI Driver s3c6410. > > For now I have complete user manual of that hardware. > > I have kernel side driver & code for hardware call. > > A user space compiled shaired library. > > I am able to compile opengl-es application and run over board easily. > > What would be easiest way to convert that library or link that shared > library to work with Mesa ? > > or Does mesa provide any framework where I just need to make hardware call > fur functions ? > > Please suggest us some idea or link where we could start developing Mesa lib > for s3c6410. > > > Thanks &Regards > > Nitesh Suthar > Software Developer and IT Engineer > (Prosoftworld Pvt Lt.) Do you want to reimplement a full opensource driver using mesa ? If so you can forget about the GL ES library you are using and start looking at how to implement a driver in mesa from scratch (this is a complex and time consuming task) First you will have to choose btw classic mesa or gallium, if your hw support glsl shader then you should choose gallium (looks at src/gallium/drivers for example). Also it's not clear what kind of documentation you have, does user manual you have cover hw and how to program it ? (not how to use the library provided). Maybe if you tell us why you want to do a mesa driver it would allow us to give you more proper advices. Cheers, Jerome |
|
From: nitesh s. <nit...@gm...> - 2010-06-18 15:10:43
|
Hello All I want to continue to write DRI Driver s3c6410. For now I have complete user manual of that hardware. I have kernel side driver & code for hardware call. A user space compiled shaired library. I am able to compile opengl-es application and run over board easily. What would be easiest way to convert that library or link that shared library to work with Mesa ? or Does mesa provide any framework where I just need to make hardware call fur functions ? Please suggest us some idea or link where we could start developing Mesa lib for s3c6410. Thanks &Regards Nitesh Suthar Software Developer and IT Engineer (Prosoftworld Pvt Lt.) |
|
From: Ian R. <id...@fr...> - 2010-06-15 17:48:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Romanick wrote: > It looks like a few bug fixes have accumulated on the branch. Could > folks spend some time this week to cherry-pick stable patches from > master, update the release notes, etc. so that we can do a release > either on Friday or Monday? > > This will be our first test of the light-weight, cherry-pick oriented, > point release... If there are no objections, I will clean up the release notes and make the release tomorrow (Wednesday) morning. It looks like a few things got cherry-picked in the last week, so I'm assuming everything is in that people care about. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwXvCsACgkQX1gOwKyEAw9KeQCfY2WJ2zbbPMlEwnLd0fDO4A4f OEcAnR6TgrR+t7+IrdOARh9IJG21zX9z =jvY+ -----END PGP SIGNATURE----- |
|
From: Brian P. <br...@vm...> - 2010-06-08 14:52:28
|
Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It looks like a few bug fixes have accumulated on the branch. Could > folks spend some time this week to cherry-pick stable patches from > master, update the release notes, etc. so that we can do a release > either on Friday or Monday? Sounds good. In theory it should be fine to make a new release off of the stable branch at almost any time. I've got a couple patches to cherry-pick... -Brian |
|
From: Ian R. <id...@fr...> - 2010-06-08 02:03:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It looks like a few bug fixes have accumulated on the branch. Could folks spend some time this week to cherry-pick stable patches from master, update the release notes, etc. so that we can do a release either on Friday or Monday? This will be our first test of the light-weight, cherry-pick oriented, point release... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwNnA4ACgkQX1gOwKyEAw+uHwCdGp6k40q6utlknzoRdgsaSDTU zR4AnjUgA8tGgmHeHwtp0mQyq6gRV8j4 =IkVX -----END PGP SIGNATURE----- |
|
From: Francis G. <fga...@gm...> - 2010-05-03 13:39:40
|
On Mon, May 3, 2010 at 3:03 PM, Török Edwin <edw...@gm...> wrote: [...] > > Sounds good, make udis86 optional now, and when someone has time to > write a patch for using llvm's disassembler then udis86 can be dropped > completely. > Untested (I have disabled LLVM support since I have encountered these problems), but there is an llvm-config command, IIRC, similarly to pkg-config, which can tell us which LDFLAGS/CPPFLAGS to use. Why not use this command, if the only requirement for Mesa is LLVM and not udis86? -- Francis Galiegue, fga...@gm... "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5) |
|
From: Marek O. <ma...@gm...> - 2010-05-03 13:25:35
|
On Mon, May 3, 2010 at 1:57 PM, José Fonseca <jfo...@vm...> wrote: > On Mon, 2010-05-03 at 01:36 -0700, Xavier Chantry wrote: > > I am trying to understand the s3tc init code as nv50 gallium has a > > problem with that. > > > > It looks like some drivers (r300g and llvmpipe) actually inits s3tc in > > two places : > > ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() > > ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() > > > > Here is an extract of the backtrace calls while loading fgfs on llvmpipe > : > > driCreateScreen -> llvmpipe_create_screen -> util_format_s3tc_init > > driCreateContext -> st_create_context -> _mesa_create_context_for_api > > -> init_attrib_groups -> _mesa_init_texture_s3tc > > > > These two functions seem to do more or less the same job, and > > apparently, the classic mesa init is unused for a gallium driver. > > So I suppose that init is not necessary, but it happens because > > gallium and mesa are tightly tied together, and create context is > > handled similarly, but it shouldn't hurt ? > > Both inits are necessary. The same .so is used for both paths, but given > that gallium and mesa do not depend on each other that's the way to do > it. Gallium and mesa also have seperate format translation functions. > > At least until we start factoring code into a separate library. (I said > I'd do it, but stuff came up and I couldn't do when I thought, and I > don't know when I'll be able to do it...) > > > Additionally r300g and llvmpipe added util_format_s3tc_init to their > > create_screen functions, and util/u_format_s3tc.c apparently contains > > all the functions that a gallium driver uses. > > So I suppose that nvfx and nv50 should do the same ? > > > > If that's correct, the patch below might not be completely wrong. > > > > On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry > > <cha...@gm...> wrote: > > > flightgear now dies with : > > > Mesa warning: external dxt library not available: texstore_rgba_dxt3 > > > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' > failed. > > > > > > I don't really understand what these stubs are about, they were > > > introduced by following commit : > > > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 > > > Author: José Fonseca <jfo...@vm...> > > > Date: Wed Apr 7 20:47:38 2010 +0100 > > > > > > util: Use stubs for the dynamically loaded S3TC functions. > > > > > > Loosely based on Luca Barbieri's commit > > > 52e9b990a192a9329006d5f7dd2ac222effea5a5. > > > > > > Looking at llvm and r300 code and trying to guess, I came up with the > > > following patch that allows flightgear to start again. But I don't > > > really understand that stuff so it could be wrong. > > > nvfx is probably affected as well. > > > > > > > > > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c > > > b/src/gallium/drivers/nouveau/nouveau_screen.c > > > index 233a91a..a91b00b 100644 > > > --- a/src/gallium/drivers/nouveau/nouveau_screen.c > > > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c > > > @@ -5,6 +5,7 @@ > > > #include "util/u_memory.h" > > > #include "util/u_inlines.h" > > > #include "util/u_format.h" > > > +#include "util/u_format_s3tc.h" > > > > > > #include <stdio.h> > > > #include <errno.h> > > > @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen, > > > struct nouveau_device *dev) > > > pscreen->fence_signalled = nouveau_screen_fence_signalled; > > > pscreen->fence_finish = nouveau_screen_fence_finish; > > > > > > + util_format_s3tc_init(); > > > + > > > return 0; > > > } > > > > > > diff --git a/src/gallium/drivers/nv50/nv50_screen.c > > > b/src/gallium/drivers/nv50/nv50_screen.c > > > index 2dd1042..0d74c90 100644 > > > --- a/src/gallium/drivers/nv50/nv50_screen.c > > > +++ b/src/gallium/drivers/nv50/nv50_screen.c > > > @@ -20,6 +20,7 @@ > > > * SOFTWARE. > > > */ > > > > > > +#include "util/u_format_s3tc.h" > > > #include "pipe/p_screen.h" > > > > > > #include "nv50_context.h" > > > @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen > *pscreen, > > > case PIPE_FORMAT_A8_UNORM: > > > case PIPE_FORMAT_I8_UNORM: > > > case PIPE_FORMAT_L8A8_UNORM: > > > - case PIPE_FORMAT_DXT1_RGB: > > > - case PIPE_FORMAT_DXT1_RGBA: > > > - case PIPE_FORMAT_DXT3_RGBA: > > > - case PIPE_FORMAT_DXT5_RGBA: > > > case PIPE_FORMAT_S8_USCALED_Z24_UNORM: > > > case PIPE_FORMAT_Z24_UNORM_S8_USCALED: > > > case PIPE_FORMAT_Z32_FLOAT: > > > @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen > *pscreen, > > > case PIPE_FORMAT_R16G16_SNORM: > > > case PIPE_FORMAT_R16G16_UNORM: > > > return TRUE; > > > + case PIPE_FORMAT_DXT1_RGB: > > > + case PIPE_FORMAT_DXT1_RGBA: > > > + case PIPE_FORMAT_DXT3_RGBA: > > > + case PIPE_FORMAT_DXT5_RGBA: > > > + return util_format_s3tc_enabled; > > > default: > > > break; > > > } > > > > > You should only advertise PIPE_FORMAT_DXT* for BIND_SAMPLER_VIEW, or you > may end up in very weird paths. Same for YUV. > I think my hw supports rendering to YUV textures, it's been even implemented in r300g but not tested. I am not sure who's gonna use such a feature. Should I disable it then? -Marek |
|
From: Török E. <edw...@gm...> - 2010-05-03 13:03:41
|
On 05/03/2010 12:22 PM, José Fonseca wrote: > On Mon, 2010-05-03 at 01:42 -0700, Török Edwin wrote: >> On 05/03/2010 11:36 AM, mes...@li... wrote: >>> From: Francis Galiegue <fga...@gm...> >>> Subject: [Mesa3d-dev] LLVM and udis86 dependencies >>> To: mes...@li... >>> Message-ID: >>> <x2z...@ma...> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> In the current HEAD, in configure.ac: >>> >>> ---- >>> 1182- [enable_gallium=yes]) >>> 1183-if test "x$enable_gallium" = xyes; then >>> 1184- SRC_DIRS="$SRC_DIRS gallium gallium/winsys gallium/targets" >>> 1185: AC_CHECK_HEADER([udis86.h], [HAS_UDIS86="yes"], >>> 1186- [HAS_UDIS86="no"]) >>> 1187- AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) >>> 1188-fi >>> -- >>> 1340- LLVM_LIBS="`$LLVM_CONFIG --libs jit interpreter nativecodegen >>> bitwriter` -lstdc++" >>> 1341- >>> 1342- if test "x$HAS_UDIS86" != xno; then >>> 1343: LLVM_LIBS="$LLVM_LIBS -ludis86" >>> 1344- DEFINES="$DEFINES -DHAVE_UDIS86" >>> 1345- fi >>> 1346- LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` >>> ---- >>> >>> This means basically that the udis86 dependency is "automagic" if you >>> elect to build with LLVM support. >>> >>> I have a case here of a miscompiled udis86 (missing -fPIC, preventing >>> relocation) on a setup where LLVM was NOT compiled with udis86. >>> >>> Would it be possible to make the udis86 dependency optional (ie, >>> --with-udis86 option to ./configure)? >> >> LLVM 2.7 includes a disassembler of its own (libEnhancedDisassembly.so), >> could that one be used instead of udis86? > > Yes, that would be nice. > > udis86 seems a bit unmaintained a the moment. I've sent a few patches > for some SSE4 opcodes to the maintainer and they weren't checked in yet. > I thought about bundling its source in mesa, but when I saw news of > LLVM's disassembler plans I thought it was better to wait. > > But I don't have time to look into this myself. If you don't have time > either then a simple patch to make udis86 optional should be good enough > for now. Sounds good, make udis86 optional now, and when someone has time to write a patch for using llvm's disassembler then udis86 can be dropped completely. Best regards, --Edwin |
|
From: José F. <jfo...@vm...> - 2010-05-03 12:35:03
|
On Mon, 2010-05-03 at 05:18 -0700, Marek Olšák wrote: > On Mon, May 3, 2010 at 1:57 PM, José Fonseca <jfo...@vm...> > wrote: > On Mon, 2010-05-03 at 01:36 -0700, Xavier Chantry wrote: > > I am trying to understand the s3tc init code as nv50 gallium > has a > > problem with that. > > > > It looks like some drivers (r300g and llvmpipe) actually > inits s3tc in > > two places : > > ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() > > ./src/gallium/auxiliary/util/u_format_s3tc.c > util_format_s3tc_init() > > > > Here is an extract of the backtrace calls while loading fgfs > on llvmpipe : > > driCreateScreen -> llvmpipe_create_screen -> > util_format_s3tc_init > > driCreateContext -> st_create_context -> > _mesa_create_context_for_api > > -> init_attrib_groups -> _mesa_init_texture_s3tc > > > > These two functions seem to do more or less the same job, > and > > apparently, the classic mesa init is unused for a gallium > driver. > > So I suppose that init is not necessary, but it happens > because > > gallium and mesa are tightly tied together, and create > context is > > handled similarly, but it shouldn't hurt ? > > > Both inits are necessary. The same .so is used for both paths, > but given > that gallium and mesa do not depend on each other that's the > way to do > it. Gallium and mesa also have seperate format translation > functions. > > At least until we start factoring code into a separate > library. (I said > I'd do it, but stuff came up and I couldn't do when I thought, > and I > don't know when I'll be able to do it...) > > > > Additionally r300g and llvmpipe added util_format_s3tc_init > to their > > create_screen functions, and util/u_format_s3tc.c apparently > contains > > all the functions that a gallium driver uses. > > So I suppose that nvfx and nv50 should do the same ? > > > > If that's correct, the patch below might not be completely > wrong. > > > > On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry > > <cha...@gm...> wrote: > > > flightgear now dies with : > > > Mesa warning: external dxt library not available: > texstore_rgba_dxt3 > > > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: > Assertion `0' failed. > > > > > > I don't really understand what these stubs are about, they > were > > > introduced by following commit : > > > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 > > > Author: José Fonseca <jfo...@vm...> > > > Date: Wed Apr 7 20:47:38 2010 +0100 > > > > > > util: Use stubs for the dynamically loaded S3TC > functions. > > > > > > Loosely based on Luca Barbieri's commit > > > 52e9b990a192a9329006d5f7dd2ac222effea5a5. > > > > > > Looking at llvm and r300 code and trying to guess, I came > up with the > > > following patch that allows flightgear to start again. But > I don't > > > really understand that stuff so it could be wrong. > > > nvfx is probably affected as well. > > > > > > > > > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c > > > b/src/gallium/drivers/nouveau/nouveau_screen.c > > > index 233a91a..a91b00b 100644 > > > --- a/src/gallium/drivers/nouveau/nouveau_screen.c > > > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c > > > @@ -5,6 +5,7 @@ > > > #include "util/u_memory.h" > > > #include "util/u_inlines.h" > > > #include "util/u_format.h" > > > +#include "util/u_format_s3tc.h" > > > > > > #include <stdio.h> > > > #include <errno.h> > > > @@ -248,6 +249,8 @@ nouveau_screen_init(struct > nouveau_screen *screen, > > > struct nouveau_device *dev) > > > pscreen->fence_signalled = > nouveau_screen_fence_signalled; > > > pscreen->fence_finish = > nouveau_screen_fence_finish; > > > > > > + util_format_s3tc_init(); > > > + > > > return 0; > > > } > > > > > > diff --git a/src/gallium/drivers/nv50/nv50_screen.c > > > b/src/gallium/drivers/nv50/nv50_screen.c > > > index 2dd1042..0d74c90 100644 > > > --- a/src/gallium/drivers/nv50/nv50_screen.c > > > +++ b/src/gallium/drivers/nv50/nv50_screen.c > > > @@ -20,6 +20,7 @@ > > > * SOFTWARE. > > > */ > > > > > > +#include "util/u_format_s3tc.h" > > > #include "pipe/p_screen.h" > > > > > > #include "nv50_context.h" > > > @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct > pipe_screen *pscreen, > > > case PIPE_FORMAT_A8_UNORM: > > > case PIPE_FORMAT_I8_UNORM: > > > case PIPE_FORMAT_L8A8_UNORM: > > > - case PIPE_FORMAT_DXT1_RGB: > > > - case PIPE_FORMAT_DXT1_RGBA: > > > - case PIPE_FORMAT_DXT3_RGBA: > > > - case PIPE_FORMAT_DXT5_RGBA: > > > case PIPE_FORMAT_S8_USCALED_Z24_UNORM: > > > case PIPE_FORMAT_Z24_UNORM_S8_USCALED: > > > case PIPE_FORMAT_Z32_FLOAT: > > > @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct > pipe_screen *pscreen, > > > case PIPE_FORMAT_R16G16_SNORM: > > > case PIPE_FORMAT_R16G16_UNORM: > > > return TRUE; > > > + case PIPE_FORMAT_DXT1_RGB: > > > + case PIPE_FORMAT_DXT1_RGBA: > > > + case PIPE_FORMAT_DXT3_RGBA: > > > + case PIPE_FORMAT_DXT5_RGBA: > > > + return util_format_s3tc_enabled; > > > default: > > > break; > > > } > > > > > > You should only advertise PIPE_FORMAT_DXT* for > BIND_SAMPLER_VIEW, or you > may end up in very weird paths. Same for YUV. > > I think my hw supports rendering to YUV textures, it's been even > implemented in r300g but not tested. I am not sure who's gonna use > such a feature. Should I disable it then? The only use I can think for YUV rendering is for automatic YUV mipmap generation. But I don't know if the u_gen_mipmap.c actually copes with it. It will surely require proper surface_copy support as well. So I wouldn't remove the code, but just disable it, until you or somebody is willing to go through mesa and make sure the plumbing actually works. Jose |
|
From: Xavier C. <cha...@gm...> - 2010-05-03 12:03:22
|
On Sun, May 2, 2010 at 3:16 PM, Marek Olšák <ma...@gm...> wrote: > On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky <max...@gm...> > wrote: >> >> This commit breaks compiz completely here on nvidia G50 (Geforce 8400M) >> Compiz shows dark screen. >> (Using nouveau drivers) >> >> Without this commit compiz works almost perfectly. >> >> The error messages from compiz: >> >> >> debug_get_bool_option: NV50_ALWAYS_PUSH = FALSE >> debug_get_bool_option: DRAW_FSE = FALSE >> debug_get_bool_option: DRAW_NO_FSE = FALSE >> debug_get_bool_option: GALLIUM_DUMP_VS = FALSE >> Mesa: Mesa 7.9-devel DEBUG build May 1 2010 19:02:06 >> Mesa warning: software DXTn compression/decompression available >> debug_get_bool_option: MESA_MVP_DP4 = FALSE >> debug_get_flags_option: ST_DEBUG = 0x0 >> Mesa: User error: GL_OUT_OF_MEMORY in glTexImage >> compiz (cube) - Warn: Failed to load >> slide: /usr/share/gdm/themes/Human/ubuntu.png >> ^CMesa: User error: GL_OUT_OF_MEMORY in glTexImage > > The commit also causes surface_copy to be called with S3TC textures, > breaking loading of such textures in r300g. I am working on a fix for r300g > but I haven't expected to get such weird formats in surface_copy. > > FYI Maxim, please use mes...@li... instead. > > -Marek > This commit also causes piglit fbo-3d test to fail with both llvmpipe and nv50 gallium. http://img163.imageshack.us/img163/535/fbo3d.png |
|
From: José F. <jfo...@vm...> - 2010-05-03 11:57:21
|
On Mon, 2010-05-03 at 01:36 -0700, Xavier Chantry wrote: > I am trying to understand the s3tc init code as nv50 gallium has a > problem with that. > > It looks like some drivers (r300g and llvmpipe) actually inits s3tc in > two places : > ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() > ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() > > Here is an extract of the backtrace calls while loading fgfs on llvmpipe : > driCreateScreen -> llvmpipe_create_screen -> util_format_s3tc_init > driCreateContext -> st_create_context -> _mesa_create_context_for_api > -> init_attrib_groups -> _mesa_init_texture_s3tc > > These two functions seem to do more or less the same job, and > apparently, the classic mesa init is unused for a gallium driver. > So I suppose that init is not necessary, but it happens because > gallium and mesa are tightly tied together, and create context is > handled similarly, but it shouldn't hurt ? Both inits are necessary. The same .so is used for both paths, but given that gallium and mesa do not depend on each other that's the way to do it. Gallium and mesa also have seperate format translation functions. At least until we start factoring code into a separate library. (I said I'd do it, but stuff came up and I couldn't do when I thought, and I don't know when I'll be able to do it...) > Additionally r300g and llvmpipe added util_format_s3tc_init to their > create_screen functions, and util/u_format_s3tc.c apparently contains > all the functions that a gallium driver uses. > So I suppose that nvfx and nv50 should do the same ? > > If that's correct, the patch below might not be completely wrong. > > On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry > <cha...@gm...> wrote: > > flightgear now dies with : > > Mesa warning: external dxt library not available: texstore_rgba_dxt3 > > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' failed. > > > > I don't really understand what these stubs are about, they were > > introduced by following commit : > > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 > > Author: José Fonseca <jfo...@vm...> > > Date: Wed Apr 7 20:47:38 2010 +0100 > > > > util: Use stubs for the dynamically loaded S3TC functions. > > > > Loosely based on Luca Barbieri's commit > > 52e9b990a192a9329006d5f7dd2ac222effea5a5. > > > > Looking at llvm and r300 code and trying to guess, I came up with the > > following patch that allows flightgear to start again. But I don't > > really understand that stuff so it could be wrong. > > nvfx is probably affected as well. > > > > > > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c > > b/src/gallium/drivers/nouveau/nouveau_screen.c > > index 233a91a..a91b00b 100644 > > --- a/src/gallium/drivers/nouveau/nouveau_screen.c > > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c > > @@ -5,6 +5,7 @@ > > #include "util/u_memory.h" > > #include "util/u_inlines.h" > > #include "util/u_format.h" > > +#include "util/u_format_s3tc.h" > > > > #include <stdio.h> > > #include <errno.h> > > @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen, > > struct nouveau_device *dev) > > pscreen->fence_signalled = nouveau_screen_fence_signalled; > > pscreen->fence_finish = nouveau_screen_fence_finish; > > > > + util_format_s3tc_init(); > > + > > return 0; > > } > > > > diff --git a/src/gallium/drivers/nv50/nv50_screen.c > > b/src/gallium/drivers/nv50/nv50_screen.c > > index 2dd1042..0d74c90 100644 > > --- a/src/gallium/drivers/nv50/nv50_screen.c > > +++ b/src/gallium/drivers/nv50/nv50_screen.c > > @@ -20,6 +20,7 @@ > > * SOFTWARE. > > */ > > > > +#include "util/u_format_s3tc.h" > > #include "pipe/p_screen.h" > > > > #include "nv50_context.h" > > @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen *pscreen, > > case PIPE_FORMAT_A8_UNORM: > > case PIPE_FORMAT_I8_UNORM: > > case PIPE_FORMAT_L8A8_UNORM: > > - case PIPE_FORMAT_DXT1_RGB: > > - case PIPE_FORMAT_DXT1_RGBA: > > - case PIPE_FORMAT_DXT3_RGBA: > > - case PIPE_FORMAT_DXT5_RGBA: > > case PIPE_FORMAT_S8_USCALED_Z24_UNORM: > > case PIPE_FORMAT_Z24_UNORM_S8_USCALED: > > case PIPE_FORMAT_Z32_FLOAT: > > @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen *pscreen, > > case PIPE_FORMAT_R16G16_SNORM: > > case PIPE_FORMAT_R16G16_UNORM: > > return TRUE; > > + case PIPE_FORMAT_DXT1_RGB: > > + case PIPE_FORMAT_DXT1_RGBA: > > + case PIPE_FORMAT_DXT3_RGBA: > > + case PIPE_FORMAT_DXT5_RGBA: > > + return util_format_s3tc_enabled; > > default: > > break; > > } > > You should only advertise PIPE_FORMAT_DXT* for BIND_SAMPLER_VIEW, or you may end up in very weird paths. Same for YUV. Jose |
102 messages has been excluded from this view by a project administrator.