Re: [Mesa-dev] [PATCH 00/15] i965, mesa, glapi: Build libi965_dri on Android
On Fri, Aug 5, 2011 at 12:27 PM, Chad Versace wrote: > On 08/04/2011 11:25 AM, Chia-I Wu wrote: >> Hi Chad, >> >> On Thu, Aug 4, 2011 at 6:47 PM, Chad Versace wrote: >>> This is the first step in porting i965 to Android, initially to Gingerbread. >>> Android is ubiquituous now, and the platform's importance can't be denied. >>> The >>> Intel drivers really should support it. >>> >>> The series first builds libglapi, then libmesa, and then libi965_dri. >>> lib965_dri doens't work yet; it doesn't even link to libdrm. This is just >>> the >>> initial work to get it to build. >>> >>> I'm aware that this may be controversial, so I've attempted to integrate the >>> Android makefiles as non-disruptively as possible. >>> - The Android makefiles attempt to duplicate as little as possible from the >>> existing makefiles. In one case, this dictated that some Makefile code be >>> extracted into a shared makefile. >>> - I've avoided modifying the existsing makefiles except when absolutely >>> necessary. When a modification or cleanup was necessary, I have attempted >>> to keep the changes minimal and do them incrementally. >>> - The locations of the Android makefiles mirror those of the existing >>> makefiles. >>> >>> The series does not break the Linux i965 build. I doubt it breaks other >>> drivers' builds, but I haven't tested it. If you want me to check that it >>> doesn't break your build, just let me know the autoconf options. >>> >>> The series lives on my android-gingerbread-i965 branch. If you'd like to try >>> the Android build yourself, you should pull from my personal Android >>> manifest >>> [1], which closely mirrors android-x86, and set `BOARD_USES_I965 := true` in >>> buildspeck.mk. >>> >>> [1] repo init -u >>> git://anongit.freedesktop.git/~chadversary/android.manifeset.git -b >>> gingerbread-i965 >> Thanks for bringing this up and working on it. Before commenting on >> the changes to Mesa, I'd like to talk a little bit about the external >> dependencies. >> >> To have a working build of Mesa for the Android Gingerbread source >> tree, these external changes are needed >> >> 1) modify Android's init (pid 1) to create DRI device nodes under /dev >> 2) make off_t 64-bit so that mmap() a GEM object works >> 3) figure out how to authenticate a DRM fd >> 4) add libdrm to Android source tree >> 5) add drm_gralloc (the DDX driver, sort of) to Android source tree >> >> There may be more that I cannot recall now. >> >> Of these changes, only 3), 4), and 5) affect how Mesa is built. >> It is safe to assume 4) and 5) are already there, as we have >> good relationship with those projects. But how to solve 3) is still >> an open question. > > Luckily, some key people who can help us with 3 belong to my team: the author > of > Wayland, and the authors of Intel's DRM module, i915.ko. I will probe them > when > we reach that bridge. > >> We can either spend several months discussing 3) with the Android team >> before landing Android support to Mesa. > > I have been given a timeframe to complete this, and though I cannot discuss > the > details, several months is unacceptable. The Mesa port needs to be completed > before yesterday. > >> Or we can assume it is >> solved, land the Android support for Mesa probably over the next few >> weeks, and initiate the discussion with the Android team with >> something concrete. Now that we are at this, my preference is the >> latter. > > Yes. We should take the latter approach. I forgot to mention that we need to do 1), 2), ..., 5) only when we target for integrating into the vanilla Android tree. When we target for integration with Android-x86, these tasks are either done or worked around. >> Back to your changes. I am fine with landing your version and is >> willing to help review them, proivided your work won't stop after >> i915/i965 is supported. Otherwise, I prefer to prepare my version[1] >> for upstreaming, which can build all actively maintained drivers >> including Gallium ones. It would also be really great you can help, >> and suppose the list is fine with yet another build system for Mesa. >> >> [1] http://cgit.freedesktop.org/~olv/mesa/log/?h=android-gingerbread-7.11 > > You have done a lot of work on the Mesa port, and I want to acknowledge your > expertise there. Please don't interpret my submission of this series as a > dismissal of that work. My intent in submitting my own patches was just to > start > the process of getting Android support upstream, incrementally, in a public, > code-reviewed forum. > > Other drivers, of course, should also be supported. I do not want to place any > obstacle in way of that goal. At each step of the review process, we should > check with each other that the approach taken is compatible with both Gallium > and non-Gallium drivers. We will be basically doing everything from scratch, in smaller steps. In that case, I see no reason not to do this based on what is already there. I did plan to
[Mesa-dev] [Bug 39846] can' t compile mesa ‘__u64’problem .
https://bugs.freedesktop.org/show_bug.cgi?id=39846 --- Comment #1 from Michel Dänzer 2011-08-04 22:51:25 PDT --- __u64 is supposed to be defined by the userspace headers from the Linux kernel (/usr/include/linux/, /usr/include/asm*). Where are you getting those from? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39846] New: can' t compile mesa ‘__u64’problem .
https://bugs.freedesktop.org/show_bug.cgi?id=39846 Summary: can't compile mesa ‘__u64’problem. Product: Mesa Version: 7.10 Platform: Other OS/Version: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Drivers/X11 AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: sol...@ucsd.edu Hi, I am having trouble compiling mesa due to this problem. I tried an internet solution of removing std=c99, but still does not work. (http://lists.freedesktop.org/archives/mesa-users/2011-February/000197.html) [root@localhost Mesa-7.10.3]# gmake gmake[1]: Entering directory `/home/sol013/Mesa-7.10.3/src' Making sources for autoconf gmake[2]: Entering directory `/home/sol013/Mesa-7.10.3/src/mapi/glapi' gmake[2]: `default'를 위해 할 일이 없습니다 gmake[2]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mapi/glapi' gmake[2]: Entering directory `/home/sol013/Mesa-7.10.3/src/glsl' gmake[2]: `default'를 위해 할 일이 없습니다 gmake[2]: Leaving directory `/home/sol013/Mesa-7.10.3/src/glsl' gmake[2]: Entering directory `/home/sol013/Mesa-7.10.3/src/mesa' gmake[3]: Entering directory `/home/sol013/Mesa-7.10.3/src/mesa/x86' gmake[3]: `default'를 위해 할 일이 없습니다 gmake[3]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mesa/x86' gmake[3]: Entering directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers' gmake[4]: Entering directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri' gmake[5]: Entering directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri/i810' gmake[6]: Entering directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri/i810' gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mapi -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/local/include -I/usr/local/include/libdrm-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 -DHAVE_XCB_DRI2 -DFEATURE_GL=1 ../common/utils.c -o ../common/utils.o In file included from ../../../../../include/GL/internal/dri_interface.h:51, from ../common/utils.h:32, from ../common/utils.c:37: /usr/local/include/libdrm/drm.h:612: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm.h:617: error: expected specifier-qualifier-list before ‘__u64’ In file included from /usr/local/include/libdrm/drm.h:621, from ../../../../../include/GL/internal/dri_interface.h:51, from ../common/utils.h:32, from ../common/utils.c:37: /usr/local/include/libdrm/drm_mode.h:97: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:110: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:168: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:194: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:199: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:211: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:219: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:268: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:309: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:344: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:356: error: expected specifier-qualifier-list before ‘__u64’ /usr/local/include/libdrm/drm_mode.h:369: error: expected specifier-qualifier-list before ‘__u64’ In file included from ../../../../../include/GL/internal/dri_interface.h:51, from ../common/utils.h:32, from ../common/utils.c:37: /usr/local/include/libdrm/drm.h:750: error: expected specifier-qualifier-list before ‘__u64’ gmake[6]: *** [../common/utils.o] 오류 1 gmake[6]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri/i810' gmake[5]: *** [lib] 오류 2 gmake[5]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri/i810' gmake[4]: *** [subdirs] 오류 1 gmake[4]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers/dri' gmake[3]: *** [default] 오류 1 gmake[3]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mesa/drivers' gmake[2]: *** [driver_subdirs] 오류 2 gmake[2]: Leaving directory `/home/sol013/Mesa-7.10.3/src/mesa' gmake[1]: *** [subdirs] 오류 1 gmake[1]: Leaving directory `/home/sol013/Mesa-7.10.3/src' gmake: *** [default] 오류 1 -- Configure bugmail: https://bugs.freedesktop.org/userpref
Re: [Mesa-dev] [PATCH] glsl: empty declarations should be valid
On 08/04/2011 06:18 PM, Chad Versace wrote: > On 08/04/2011 01:29 PM, Eric Anholt wrote: >> On Thu, 4 Aug 2011 12:59:35 +0900, Chia-I Wu wrote: >>> From: Chia-I Wu >>> >>> Unlike C++, empty declarations such as >>> >>> float; >>> >>> should be valid. The spec is not explicit about this actually. >>> >>> Some apps that generate their shader sources may rely on this. This was >>> noted when porting one of them to Linux from Windows. >> >> Ew. Looking the GLSL 1.20 spec, I see: >> >> statement: >> declaration_statement >> >> declaration_statement: >> declaration >> >> declaration: >> init_declarator_list SEMICOLON >> >> init_declarator_list: >> single_declaration >> >> single_declaration: >> fully_specified_type >> fully_specified_type IDENTIFIER >> >> so it looks like that is actually valid code. That's awful. > > I first suspected that this was a spec grammar bug. But it is still present in > the GLSL 4.10 spec, so it's unlikely to be a bug. > > Surprisingly, C also allows empty declarations. Compiling this > float; > int main() { return 0; } > with `gcc --std=c99` succeeds and emits this warning: > warning: useless type name in empty declaration [enabled by default] > > I hate to say this, but I believe the spec grammar intentionally allows empty > declarations. C allows it, and GLSL tries to mimic C. > > Even though I don't like empty declarations, this patch is > Reviewed-by: Chad Versace Also, please update the commit message to say that `gcc --std=c99` allows empty declrations and include the appropriate quotation from the GLSL 1.20 spec's grammar. Without that extra info, someone may stumble onto this commit and say WTF. -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/15] i965, mesa, glapi: Build libi965_dri on Android
On 08/04/2011 11:25 AM, Chia-I Wu wrote: > Hi Chad, > > On Thu, Aug 4, 2011 at 6:47 PM, Chad Versace wrote: >> This is the first step in porting i965 to Android, initially to Gingerbread. >> Android is ubiquituous now, and the platform's importance can't be denied. >> The >> Intel drivers really should support it. >> >> The series first builds libglapi, then libmesa, and then libi965_dri. >> lib965_dri doens't work yet; it doesn't even link to libdrm. This is just the >> initial work to get it to build. >> >> I'm aware that this may be controversial, so I've attempted to integrate the >> Android makefiles as non-disruptively as possible. >> - The Android makefiles attempt to duplicate as little as possible from the >>existing makefiles. In one case, this dictated that some Makefile code be >>extracted into a shared makefile. >> - I've avoided modifying the existsing makefiles except when absolutely >>necessary. When a modification or cleanup was necessary, I have attempted >>to keep the changes minimal and do them incrementally. >> - The locations of the Android makefiles mirror those of the existing >>makefiles. >> >> The series does not break the Linux i965 build. I doubt it breaks other >> drivers' builds, but I haven't tested it. If you want me to check that it >> doesn't break your build, just let me know the autoconf options. >> >> The series lives on my android-gingerbread-i965 branch. If you'd like to try >> the Android build yourself, you should pull from my personal Android manifest >> [1], which closely mirrors android-x86, and set `BOARD_USES_I965 := true` in >> buildspeck.mk. >> >> [1] repo init -u >> git://anongit.freedesktop.git/~chadversary/android.manifeset.git -b >> gingerbread-i965 > Thanks for bringing this up and working on it. Before commenting on > the changes to Mesa, I'd like to talk a little bit about the external > dependencies. > > To have a working build of Mesa for the Android Gingerbread source > tree, these external changes are needed > > 1) modify Android's init (pid 1) to create DRI device nodes under /dev > 2) make off_t 64-bit so that mmap() a GEM object works > 3) figure out how to authenticate a DRM fd > 4) add libdrm to Android source tree > 5) add drm_gralloc (the DDX driver, sort of) to Android source tree > > There may be more that I cannot recall now. > > Of these changes, only 3), 4), and 5) affect how Mesa is built. > It is safe to assume 4) and 5) are already there, as we have > good relationship with those projects. But how to solve 3) is still > an open question. Luckily, some key people who can help us with 3 belong to my team: the author of Wayland, and the authors of Intel's DRM module, i915.ko. I will probe them when we reach that bridge. > We can either spend several months discussing 3) with the Android team > before landing Android support to Mesa. I have been given a timeframe to complete this, and though I cannot discuss the details, several months is unacceptable. The Mesa port needs to be completed before yesterday. > Or we can assume it is > solved, land the Android support for Mesa probably over the next few > weeks, and initiate the discussion with the Android team with > something concrete. Now that we are at this, my preference is the > latter. Yes. We should take the latter approach. > Back to your changes. I am fine with landing your version and is > willing to help review them, proivided your work won't stop after > i915/i965 is supported. Otherwise, I prefer to prepare my version[1] > for upstreaming, which can build all actively maintained drivers > including Gallium ones. It would also be really great you can help, > and suppose the list is fine with yet another build system for Mesa. > > [1] http://cgit.freedesktop.org/~olv/mesa/log/?h=android-gingerbread-7.11 You have done a lot of work on the Mesa port, and I want to acknowledge your expertise there. Please don't interpret my submission of this series as a dismissal of that work. My intent in submitting my own patches was just to start the process of getting Android support upstream, incrementally, in a public, code-reviewed forum. Other drivers, of course, should also be supported. I do not want to place any obstacle in way of that goal. At each step of the review process, we should check with each other that the approach taken is compatible with both Gallium and non-Gallium drivers. My work won't stop once i965 support is completed. I will continue to maintain Android i965 for the forseeable future. I expect that we will be collaborating on this for a long time. -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
On 08/04/2011 04:17 PM, Jose Fonseca wrote: > - Original Message - >> On Thu, Aug 4, 2011 at 2:47 AM, Chad Versace >> wrote: >>> This is the first step in porting libGLES* and libEGL to Android. >>> >>> The makefile doesn't build anything yet; it just defines common >>> variables. >>> >>> The values for MESA_COMMON_C_FLAGS and MESA_COMMON_CPP_FLAGS, I >>> obtained >>> by invoking autogen.sh with the options below and then inspecting >>> MESA_TOP/configs/autoconf. My immediate goal is to port i965 to >>> Android, >>> so I used the typical flags for building i965. >>>--disable-gallium >>>--disable-glu >>>--disable-glw >>>--disable-glut >>>--enable-32-bit >>>--enable-egl >>>--enable-gles2 >>>--enable-gles1 >>>--enable-texture-float >>>--with-dri-drivers=i965 >>>--with-gallium-drivers= >>> >>> Note: This is in preparation for porting i965 to Android. >>> CC: Chia-I Wu , >>> CC: Chih-Wei Huang >>> Signed-off-by: Chad Versace >>> --- >>> Android.mk | 66 >>> >>> android/mesa_local_vars.mk | 32 + >>> 2 files changed, 98 insertions(+), 0 deletions(-) >>> create mode 100644 Android.mk >>> create mode 100644 android/mesa_local_vars.mk >> >> There's quite a bit of new build infrastructure here. What would it >> take to fit this into either the existing autoconf support or add a >> targeted configs/android? Duplicating a pile of make targets and >> adding another way to configure/build mesa seems like it might not be >> the best way to go. What are the current constraints that make >> building mesa on android difficult? > > I agree. I'd prefer not have yet another build infrastructure in the mix, > unless there's a very good reason. > > Jose I also agree. I would prefer to not add another build system to Mesa. We have too many as it is. To address Dan's questions, the Android build cannot be fitted into autoconf or configs/android. I explored this option, and discovered that it was impossible. The Android build system is... well... interesting. Allow me to explain. The entirety of the Android project --- libc, webkit, the window manager, *everything* --- exists in a single source tree [1]. And that source tree is built with a single, non-recursive invocation of make. Every time I say that, I find it hard to believe myself, so I'll say it again: The entirety of the Android OS, all core libraries and apps, are built with a single, non-recursive invocation of make. (The kernel is the special exception to this all-encompassing build). The final build artifact is a bootable iso image. [1] http://android.git.kernel.org/ Given this unified design of the Android source tree and build process, it requires system components, such as Mesa, to be integrated into its build system. If Mesa is going to support Android, the Android.mk's are necessary. To address another concern of Dan's, this will not add another way to configure the Mesa build. Android handles the system's build configuration in a single location which is outside of Mesa. I'm aware that the extra set of makefiles is unwelcome, but their presence will be innocuous. The only people that will need to touch them are those maintaining the Android build. -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/15] dri/Makefile.defines: Only add -Iserver to includes if the dir exists
On 08/04/2011 08:45 AM, Eric Anholt wrote: > On Thu, 4 Aug 2011 02:47:20 -0700, Chad Versace wrote: >> Without this change, the next commit breaks the i915 and i965 builds. >> >> CC: Chia-I Wu , >> CC: Chih-Wei Huang >> Signed-off-by: Chad Versace >> --- >> src/mesa/drivers/dri/Makefile.defines |5 - >> 1 files changed, 4 insertions(+), 1 deletions(-) >> >> diff --git a/src/mesa/drivers/dri/Makefile.defines >> b/src/mesa/drivers/dri/Makefile.defines >> index 1ee6ce2..3235bdc 100644 >> --- a/src/mesa/drivers/dri/Makefile.defines >> +++ b/src/mesa/drivers/dri/Makefile.defines >> @@ -15,13 +15,16 @@ COMMON_SOURCES := $(COMMON_GALLIUM_SOURCES) \ >> SHARED_INCLUDES := \ >> -I. \ >> -I$(TOP)/src/mesa/drivers/dri/common \ >> --Iserver \ >> -I$(TOP)/include \ >> -I$(TOP)/src/mapi \ >> -I$(TOP)/src/mesa \ >> -I$(TOP)/src/egl/main \ >> $(LIBDRM_CFLAGS) >> >> +ifeq (0, $(shell test -d server; echo $?)) >> +SHARED_INCLUDES += -Iserver >> +endif >> + >> INCLUDES := $(SHARED_INCLUDES) $(EXPAT_INCLUDES) >> INCLUDES += $(API_DEFINES) > > Or we could just shove the -Iserver down into the DRI1 drivers. Agreed. I like that solution much more than my ugly make/shell hack. -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/15] main: Remove problematic #include on Android
On 08/04/2011 08:43 AM, Eric Anholt wrote: > On Thu, 4 Aug 2011 02:47:15 -0700, Chad Versace wrote: >> Remove ``#include `` from compiler.h. >> >> Note: This is in preparation for porting i965 to Android. >> CC: Chia-I Wu , >> CC: Chih-Wei Huang >> Signed-off-by: Chad Versace >> --- >> src/mesa/main/compiler.h |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h >> index d736fdf..3981644 100644 >> --- a/src/mesa/main/compiler.h >> +++ b/src/mesa/main/compiler.h >> @@ -45,7 +45,7 @@ >> #include >> #include >> #include >> -#if defined(__linux__) && defined(__i386__) >> +#if defined(__linux__) && defined(__i386__) && !defined(ANDROID) >> #include >> #endif >> #include >> -- >> 1.7.6 > > I've noticed that this include is missing on my debian cross-build > environment too. Can we tell if it's even required on linux 386 any > more? I doesn't appear to be to me. You're right. compiler.h uses no symbols from fpu_control.h. -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] glsl: Perform implicit type conversions on function call out parameters.
On 08/02/2011 05:38 PM, Paul Berry wrote: > When an out parameter undergoes an implicit type conversion, we need > to store it in a temporary, and then after the call completes, convert > the resulting value. In other words, we convert code like the > following: > > void f(out int x); > float value; > f(value); > > Into IR that's equivalent to this: > > void f(out int x); > float value; > int x_converted; > f(x_converted); > value = float(x_converted); > > This transformation needs to happen during ast-to-IR convertion (as > opposed to, say, a lowering pass), because it is invalid IR for formal > and actual parameters to have types that don't match. It is odd that we generate the post_call_conversions IR during ast-to-hir. It is even more odd that we generate it in a function named match_function_by_name(); after all, it now does much more than a match. After exploring the code, though, I discovered that match_function_by_name() is really a misnomer. It is already doing conversion for 'in' parameters, so it also seems the proper place to do conversion of 'out' parameters. > > Fixes piglit tests spec/glsl-1.20/compiler/qualifiers/out-03.vert and > spec/glsl-1.20/execution/qualifiers/vs-out-{01,02,03}.shader_test, and > bug 39651. The Piglit names will need updating after you rename them. Please rename and commit the Piglit tests before committing this patch. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39651 > --- > src/glsl/ast_function.cpp | 64 +--- > 1 files changed, 59 insertions(+), 5 deletions(-) > > diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp > index 8bcf48d..f945a94 100644 > --- a/src/glsl/ast_function.cpp > +++ b/src/glsl/ast_function.cpp > @@ -134,6 +134,8 @@ match_function_by_name(exec_list *instructions, const > char *name, >} > } > > + exec_list post_call_conversions; > + > if (sig != NULL) { >/* Verify that 'out' and 'inout' actual parameters are lvalues. This > * isn't done in ir_function::matching_signature because that function > @@ -141,6 +143,13 @@ match_function_by_name(exec_list *instructions, const > char *name, > * > * Also, validate that 'const_in' formal parameters (an extension of > our > * IR) correspond to ir_constant actual parameters. > + * > + * Also, perform implicit conversion of arguments. Note: to > + * implicitly convert out parameters, we need to place them in a > + * temporary variable, and do the conversion after the call > + * takes place. Since we haven't emitted the call yet, we'll > + * place the post-call conversions in a temporary exec_list, and > + * emit them later. > */ >exec_list_iterator actual_iter = actual_parameters->iterator(); >exec_list_iterator formal_iter = sig->parameters.iterator(); > @@ -185,8 +194,50 @@ match_function_by_name(exec_list *instructions, const > char *name, >} > >if (formal->type->is_numeric() || formal->type->is_boolean()) { > - ir_rvalue *converted = convert_component(actual, formal->type); > - actual->replace_with(converted); > +switch (formal->mode) { > +case ir_var_in: > + { > + ir_rvalue *converted > + = convert_component(actual, formal->type); > + actual->replace_with(converted); > + } > + break; > +case ir_var_out: > + if (actual->type != formal->type) > + { > + /* Create a temporary variable to hold the out > + * parameter. Don't pass a hashtable to clone() > + * because we don't want this temporary variable to > + * be in scope. This comment would be more instructive if it contained this snippet from the commit message: As as example, this code void f(out int x); float value; f(value); is translated into IR equivalent to void f(out int x); float value; int x_converted; f(x_converted); value = float(x_converted); This example goes a long way to helping someone understand how you are juggling the IR. > + */ > + ir_variable *tmp = formal->clone(ctx, NULL); > + tmp->mode = ir_var_auto; > + instructions->push_tail(tmp); > + ir_dereference_variable *deref_tmp_1 > + = new(ctx) ir_dereference_variable(tmp); > + ir_dereference_variable *deref_tmp_2 > + = new(ctx) ir_dereference_variable(tmp); > + ir_rvalue *converted_tmp > + = convert_component(deref_tmp_1, actual->type); > + ir_assignment *assignment > + = new(ctx) ir_assignment(actual, converted_tmp); > +
Re: [Mesa-dev] [PATCH 2/3] glsl: Add validations for ir_call.
On 08/02/2011 06:15 PM, Ian Romanick wrote: > On 08/02/2011 05:38 PM, Paul Berry wrote: >> This patch extends ir_validate.cpp to check the following >> characteristics of each ir_call: > >> - The number of actual parameters must match the number of formal >> parameters in the signature. > >> - The type of each actual parameter must match the type of the >> corresponding formal parameter in the signature. > >> - Each "out" or "inout" actual parameter must be an lvalue. >> --- >> src/glsl/ir_validate.cpp | 35 +++ >> 1 files changed, 35 insertions(+), 0 deletions(-) > >> diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp >> index f3fceb2..72e4faf 100644 >> --- a/src/glsl/ir_validate.cpp >> +++ b/src/glsl/ir_validate.cpp >> @@ -541,7 +541,42 @@ ir_validate::visit_enter(ir_call *ir) >>abort(); >> } > >> + exec_list_iterator formal_param_iter = callee->parameters.iterator(); >> + exec_list_iterator actual_param_iter = ir->actual_parameters.iterator(); > > We stopped making new uses of the iterators a long time ago. As > implemented, they're a giant pile of fail. For what you're trying to do > here, just use node->next and node->is_tail_sentinel(). Note that > is_tail_sentinel tells you if you're at the first "node" *past* the end > of the list. > >> + while (true) { >> + if (formal_param_iter.has_next() != actual_param_iter.has_next()) { >> + printf("ir_call has the wrong number of parameters:\n"); >> + goto dump_ir; >> + } >> + if (!formal_param_iter.has_next()) { >> + break; >> + } >> + const ir_variable *formal_param >> + = (const ir_variable *) formal_param_iter.get(); >> + const ir_rvalue *actual_param >> + = (const ir_rvalue *) actual_param_iter.get(); >> + if (formal_param->type != actual_param->type) { >> + printf("ir_call parameter type mismatch:\n"); >> + goto dump_ir; >> + } >> + if (formal_param->mode == ir_var_out >> + || formal_param->mode == ir_var_inout) { >> + if (!actual_param->is_lvalue()) { >> +printf("ir_call out/inout parameters must be lvalues:\n"); >> +goto dump_ir; >> + } >> + } >> + formal_param_iter.next(); >> + actual_param_iter.next(); >> + } >> + >> return visit_continue; >> + >> +dump_ir: >> + ir->print(); >> + printf("callee:\n"); >> + callee->print(); >> + abort(); >> } I am not intimate with the implementation details of exec_list_iterator, and so have nothing to say on that topic. Regardless if you replace the iterators or not, the patch looks good to me. Reviewed-by: Chad Versace -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] glsl: Make is_lvalue() and variable_referenced() const.
On 08/02/2011 05:38 PM, Paul Berry wrote: > These functions don't modify the target instruction, so it makes sense > to make them const. This allows these functions to be called from ir > validation code (which uses const to ensure that it doesn't > accidentally modify the IR being validated). > --- > src/glsl/ir.cpp |4 ++-- > src/glsl/ir.h | 18 +- > 2 files changed, 11 insertions(+), 11 deletions(-) > > diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp > index 827fe8e..6f8676e 100644 > --- a/src/glsl/ir.cpp > +++ b/src/glsl/ir.cpp > @@ -1096,7 +1096,7 @@ > ir_dereference_record::ir_dereference_record(ir_variable *var, > } > > bool > -ir_dereference::is_lvalue() > +ir_dereference::is_lvalue() const > { > ir_variable *var = this->variable_referenced(); > > @@ -1310,7 +1310,7 @@ ir_swizzle::create(ir_rvalue *val, const char *str, > unsigned vector_length) > #undef I > > ir_variable * > -ir_swizzle::variable_referenced() > +ir_swizzle::variable_referenced() const > { > return this->val->variable_referenced(); > } > diff --git a/src/glsl/ir.h b/src/glsl/ir.h > index 50a9d6e..04fa97b 100644 > --- a/src/glsl/ir.h > +++ b/src/glsl/ir.h > @@ -144,7 +144,7 @@ public: > > ir_rvalue *as_rvalue_to_saturate(); > > - virtual bool is_lvalue() > + virtual bool is_lvalue() const > { >return false; > } > @@ -152,7 +152,7 @@ public: > /** > * Get the variable that is ultimately referenced by an r-value > */ > - virtual ir_variable *variable_referenced() > + virtual ir_variable *variable_referenced() const > { >return NULL; > } > @@ -1355,7 +1355,7 @@ public: > > virtual ir_visitor_status accept(ir_hierarchical_visitor *); > > - bool is_lvalue() > + bool is_lvalue() const > { >return val->is_lvalue() && !mask.has_duplicates; > } > @@ -1363,7 +1363,7 @@ public: > /** > * Get the variable that is ultimately referenced by an r-value > */ > - virtual ir_variable *variable_referenced(); > + virtual ir_variable *variable_referenced() const; > > ir_rvalue *val; > ir_swizzle_mask mask; > @@ -1387,12 +1387,12 @@ public: >return this; > } > > - bool is_lvalue(); > + bool is_lvalue() const; > > /** > * Get the variable that is ultimately referenced by an r-value > */ > - virtual ir_variable *variable_referenced() = 0; > + virtual ir_variable *variable_referenced() const = 0; > }; > > > @@ -1413,7 +1413,7 @@ public: > /** > * Get the variable that is ultimately referenced by an r-value > */ > - virtual ir_variable *variable_referenced() > + virtual ir_variable *variable_referenced() const > { >return this->var; > } > @@ -1462,7 +1462,7 @@ public: > /** > * Get the variable that is ultimately referenced by an r-value > */ > - virtual ir_variable *variable_referenced() > + virtual ir_variable *variable_referenced() const > { >return this->array->variable_referenced(); > } > @@ -1496,7 +1496,7 @@ public: > /** > * Get the variable that is ultimately referenced by an r-value > */ > - virtual ir_variable *variable_referenced() > + virtual ir_variable *variable_referenced() const > { >return this->record->variable_referenced(); > } This patch is sensible and straightforward. Reviwed-by: Chad Versace -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: empty declarations should be valid
On 08/04/2011 01:29 PM, Eric Anholt wrote: > On Thu, 4 Aug 2011 12:59:35 +0900, Chia-I Wu wrote: >> From: Chia-I Wu >> >> Unlike C++, empty declarations such as >> >> float; >> >> should be valid. The spec is not explicit about this actually. >> >> Some apps that generate their shader sources may rely on this. This was >> noted when porting one of them to Linux from Windows. > > Ew. Looking the GLSL 1.20 spec, I see: > > statement: > declaration_statement > > declaration_statement: > declaration > > declaration: > init_declarator_list SEMICOLON > > init_declarator_list: > single_declaration > > single_declaration: > fully_specified_type > fully_specified_type IDENTIFIER > > so it looks like that is actually valid code. That's awful. I first suspected that this was a spec grammar bug. But it is still present in the GLSL 4.10 spec, so it's unlikely to be a bug. Surprisingly, C also allows empty declarations. Compiling this float; int main() { return 0; } with `gcc --std=c99` succeeds and emits this warning: warning: useless type name in empty declaration [enabled by default] I hate to say this, but I believe the spec grammar intentionally allows empty declarations. C allows it, and GLSL tries to mimic C. Even though I don't like empty declarations, this patch is Reviewed-by: Chad Versace -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
- Original Message - > On Thu, Aug 4, 2011 at 2:47 AM, Chad Versace > wrote: > > This is the first step in porting libGLES* and libEGL to Android. > > > > The makefile doesn't build anything yet; it just defines common > > variables. > > > > The values for MESA_COMMON_C_FLAGS and MESA_COMMON_CPP_FLAGS, I > > obtained > > by invoking autogen.sh with the options below and then inspecting > > MESA_TOP/configs/autoconf. My immediate goal is to port i965 to > > Android, > > so I used the typical flags for building i965. > > --disable-gallium > > --disable-glu > > --disable-glw > > --disable-glut > > --enable-32-bit > > --enable-egl > > --enable-gles2 > > --enable-gles1 > > --enable-texture-float > > --with-dri-drivers=i965 > > --with-gallium-drivers= > > > > Note: This is in preparation for porting i965 to Android. > > CC: Chia-I Wu , > > CC: Chih-Wei Huang > > Signed-off-by: Chad Versace > > --- > > Android.mk | 66 > > > > android/mesa_local_vars.mk | 32 + > > 2 files changed, 98 insertions(+), 0 deletions(-) > > create mode 100644 Android.mk > > create mode 100644 android/mesa_local_vars.mk > > There's quite a bit of new build infrastructure here. What would it > take to fit this into either the existing autoconf support or add a > targeted configs/android? Duplicating a pile of make targets and > adding another way to configure/build mesa seems like it might not be > the best way to go. What are the current constraints that make > building mesa on android difficult? I agree. I'd prefer not have yet another build infrastructure in the mix, unless there's a very good reason. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
On Thu, Aug 4, 2011 at 2:47 AM, Chad Versace wrote: > This is the first step in porting libGLES* and libEGL to Android. > > The makefile doesn't build anything yet; it just defines common variables. > > The values for MESA_COMMON_C_FLAGS and MESA_COMMON_CPP_FLAGS, I obtained > by invoking autogen.sh with the options below and then inspecting > MESA_TOP/configs/autoconf. My immediate goal is to port i965 to Android, > so I used the typical flags for building i965. > --disable-gallium > --disable-glu > --disable-glw > --disable-glut > --enable-32-bit > --enable-egl > --enable-gles2 > --enable-gles1 > --enable-texture-float > --with-dri-drivers=i965 > --with-gallium-drivers= > > Note: This is in preparation for porting i965 to Android. > CC: Chia-I Wu , > CC: Chih-Wei Huang > Signed-off-by: Chad Versace > --- > Android.mk | 66 > > android/mesa_local_vars.mk | 32 + > 2 files changed, 98 insertions(+), 0 deletions(-) > create mode 100644 Android.mk > create mode 100644 android/mesa_local_vars.mk There's quite a bit of new build infrastructure here. What would it take to fit this into either the existing autoconf support or add a targeted configs/android? Duplicating a pile of make targets and adding another way to configure/build mesa seems like it might not be the best way to go. What are the current constraints that make building mesa on android difficult? -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): egl/gbm: Fix EGL_DEFAULT_DISPLAY
This commit *really* needs a more descriptive commit message. - What were the symptoms of the broken EGL_DEFAULT_DISPLAY? - What error in the code caused the problem? - What the hell did you do to fix it? This is not evident due to the length of the commit. For commits of this complexity, write descriptive messages for the sake of others. -- Chad Versace c...@chad-versace.us On 08/04/2011 05:18 AM, Benjamin Franzke wrote: > Module: Mesa > Branch: master > Commit: 32f4cf38085e4056b8e4a9fc78fea28897a1d05f > URL: > http://cgit.freedesktop.org/mesa/mesa/commit/?id=32f4cf38085e4056b8e4a9fc78fea28897a1d05f > > Author: Benjamin Franzke > Date: Wed Jun 29 08:49:39 2011 +0200 > > egl/gbm: Fix EGL_DEFAULT_DISPLAY > > --- > > src/egl/drivers/dri2/egl_dri2.c |7 ++ > src/egl/drivers/dri2/egl_dri2.h |1 + > src/egl/drivers/dri2/platform_drm.c | 25 +- > src/gallium/state_trackers/egl/drm/native_drm.c | 23 > src/gallium/state_trackers/egl/drm/native_drm.h |4 +++ > 5 files changed, 53 insertions(+), 7 deletions(-) > > diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c > index 0aca929..9a37ea4 100644 > --- a/src/egl/drivers/dri2/egl_dri2.c > +++ b/src/egl/drivers/dri2/egl_dri2.c > @@ -592,6 +592,13 @@ dri2_terminate(_EGLDriver *drv, _EGLDisplay *disp) > wl_display_destroy(dri2_dpy->wl_dpy); > break; > #endif > +#ifdef HAVE_DRM_PLATFORM > + case _EGL_PLATFORM_DRM: > + if (dri2_dpy->own_gbm_device) { > +gbm_device_destroy(&dri2_dpy->gbm_dri->base.base); > + } > + break; > +#endif >default: > break; >} > diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h > index 3854200..a729718 100644 > --- a/src/egl/drivers/dri2/egl_dri2.h > +++ b/src/egl/drivers/dri2/egl_dri2.h > @@ -86,6 +86,7 @@ struct dri2_egl_display > > #ifdef HAVE_DRM_PLATFORM > struct gbm_dri_device*gbm_dri; > + int own_gbm_device; > #endif > > char *device_name; > diff --git a/src/egl/drivers/dri2/platform_drm.c > b/src/egl/drivers/dri2/platform_drm.c > index 579baf9..04b10e2 100644 > --- a/src/egl/drivers/dri2/platform_drm.c > +++ b/src/egl/drivers/dri2/platform_drm.c > @@ -30,6 +30,10 @@ > #include > #include > #include > +#include > +#include > +#include > +#include > > #include "egl_dri2.h" > > @@ -90,6 +94,7 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp) > { > struct dri2_egl_display *dri2_dpy; > struct gbm_device *gbm; > + int fd = -1; > int i; > > dri2_dpy = malloc(sizeof *dri2_dpy); > @@ -100,7 +105,15 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp) > > disp->DriverData = (void *) dri2_dpy; > > - gbm = (struct gbm_device *) disp->PlatformDisplay; > + gbm = disp->PlatformDisplay; > + if (gbm == NULL) { > + fd = open("/dev/dri/card0", O_RDWR); > + dri2_dpy->own_gbm_device = 1; > + gbm = gbm_create_device(fd); > + if (gbm == NULL) > + return EGL_FALSE; > + } > + > if (strcmp(gbm_device_get_backend_name(gbm), "drm") != 0) { >free(dri2_dpy); >return EGL_FALSE; > @@ -112,7 +125,15 @@ dri2_initialize_drm(_EGLDriver *drv, _EGLDisplay *disp) >return EGL_FALSE; > } > > - dri2_dpy->fd = gbm_device_get_fd(gbm); > + if (fd < 0) { > + fd = dup(gbm_device_get_fd(gbm)); > + if (fd < 0) { > + free(dri2_dpy); > + return EGL_FALSE; > + } > + } > + > + dri2_dpy->fd = fd; > dri2_dpy->device_name = dri2_get_device_name_for_fd(dri2_dpy->fd); > dri2_dpy->driver_name = dri2_dpy->gbm_dri->base.driver_name; > > diff --git a/src/gallium/state_trackers/egl/drm/native_drm.c > b/src/gallium/state_trackers/egl/drm/native_drm.c > index 47910de..c013769 100644 > --- a/src/gallium/state_trackers/egl/drm/native_drm.c > +++ b/src/gallium/state_trackers/egl/drm/native_drm.c > @@ -134,8 +134,11 @@ drm_display_destroy(struct native_display *ndpy) > if (drmdpy->device_name) >FREE(drmdpy->device_name); > > - if (drmdpy->fd >= 0) > - close(drmdpy->fd); > + if (drmdpy->own_gbm) { > + gbm_device_destroy(&drmdpy->gbmdrm->base.base); > + if (drmdpy->fd >= 0) > + close(drmdpy->fd); > + } > > FREE(drmdpy); > } > @@ -258,7 +261,7 @@ drm_display_init_screen(struct native_display *ndpy) > } > > static struct native_display * > -drm_create_display(struct gbm_gallium_drm_device *gbmdrm, > +drm_create_display(struct gbm_gallium_drm_device *gbmdrm, int own_gbm, > const struct native_event_handler *event_handler) > { > struct drm_display *drmdpy; > @@ -267,6 +270,8 @@ drm_create_display(struct gbm_gallium_drm_device *gbmdrm, > if (!drmdpy) >return NULL; > > + drmdpy->gbmdrm = gbmdrm; > + drmdpy->ow
[Mesa-dev] Removing GLw from the main Mesa repository
Hey, I'd like to remove libGLw from the main Mesa repository. It never changes, and almost noone uses it...because GL and Motif is awesome, right? Since Debian still packages it, I pulled it into its own git repository, preserving history, and then autotooled it. You can get it here: git://people.freedesktop.org/~kwg/glw --Kenneth ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39841] Buffer access out-of-bounds in texcompress_rgtc_tmp.h
https://bugs.freedesktop.org/show_bug.cgi?id=39841 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Brian Paul 2011-08-04 14:34:59 PDT --- Fixed with commit 1c8d079e205919b24e04efdc2421c18d03f078ff -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: empty declarations should be valid
On Thu, 4 Aug 2011 12:59:35 +0900, Chia-I Wu wrote: > From: Chia-I Wu > > Unlike C++, empty declarations such as > > float; > > should be valid. The spec is not explicit about this actually. > > Some apps that generate their shader sources may rely on this. This was > noted when porting one of them to Linux from Windows. Ew. Looking the GLSL 1.20 spec, I see: statement: declaration_statement declaration_statement: declaration declaration: init_declarator_list SEMICOLON init_declarator_list: single_declaration single_declaration: fully_specified_type fully_specified_type IDENTIFIER so it looks like that is actually valid code. That's awful. pgpfJuk23mAKh.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39841] New: Buffer access out-of-bounds in texcompress_rgtc_tmp.h
https://bugs.freedesktop.org/show_bug.cgi?id=39841 Summary: Buffer access out-of-bounds in texcompress_rgtc_tmp.h Product: Mesa Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: timo.wi...@gmail.com Cppcheck found out-of-bounds buffer access in \mesa\main\texcompress_rgtc_tmp.h:185: acutValues. Array size is 7, but the loop is over 8 elements. Found in Mesa 7.11 release. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/15] i965, mesa, glapi: Build libi965_dri on Android
Hi Chad, On Thu, Aug 4, 2011 at 6:47 PM, Chad Versace wrote: > This is the first step in porting i965 to Android, initially to Gingerbread. > Android is ubiquituous now, and the platform's importance can't be denied. The > Intel drivers really should support it. > > The series first builds libglapi, then libmesa, and then libi965_dri. > lib965_dri doens't work yet; it doesn't even link to libdrm. This is just the > initial work to get it to build. > > I'm aware that this may be controversial, so I've attempted to integrate the > Android makefiles as non-disruptively as possible. > - The Android makefiles attempt to duplicate as little as possible from the > existing makefiles. In one case, this dictated that some Makefile code be > extracted into a shared makefile. > - I've avoided modifying the existsing makefiles except when absolutely > necessary. When a modification or cleanup was necessary, I have attempted > to keep the changes minimal and do them incrementally. > - The locations of the Android makefiles mirror those of the existing > makefiles. > > The series does not break the Linux i965 build. I doubt it breaks other > drivers' builds, but I haven't tested it. If you want me to check that it > doesn't break your build, just let me know the autoconf options. > > The series lives on my android-gingerbread-i965 branch. If you'd like to try > the Android build yourself, you should pull from my personal Android manifest > [1], which closely mirrors android-x86, and set `BOARD_USES_I965 := true` in > buildspeck.mk. > > [1] repo init -u > git://anongit.freedesktop.git/~chadversary/android.manifeset.git -b > gingerbread-i965 Thanks for bringing this up and working on it. Before commenting on the changes to Mesa, I'd like to talk a little bit about the external dependencies. To have a working build of Mesa for the Android Gingerbread source tree, these external changes are needed 1) modify Android's init (pid 1) to create DRI device nodes under /dev 2) make off_t 64-bit so that mmap() a GEM object works 3) figure out how to authenticate a DRM fd 4) add libdrm to Android source tree 5) add drm_gralloc (the DDX driver, sort of) to Android source tree There may be more that I cannot recall now. Of these changes, only 3), 4), and 5) affect how Mesa is built. It is safe to assume 4) and 5) are already there, as we have good relationship with those projects. But how to solve 3) is still an open question. We can either spend several months discussing 3) with the Android team before landing Android support to Mesa. Or we can assume it is solved, land the Android support for Mesa probably over the next few weeks, and initiate the discussion with the Android team with something concrete. Now that we are at this, my preference is the latter. Back to your changes. I am fine with landing your version and is willing to help review them, proivided your work won't stop after i915/i965 is supported. Otherwise, I prefer to prepare my version[1] for upstreaming, which can build all actively maintained drivers including Gallium ones. It would also be really great you can help, and suppose the list is fine with yet another build system for Mesa. [1] http://cgit.freedesktop.org/~olv/mesa/log/?h=android-gingerbread-7.11 > Chad Versace (15): > mesa: Add toplevel Android.mk > glapi: Build libmesa_glapi on Android > mesa/sources.mak: Convert all variables to be simply-expanded > mesa/sources.mak: Cleanup include paths for Android > mesa/sources.mak: Change handling of lex and yacc files for Android > main: Remove problematic #include on Android > main: Add -o option to es_generator.py > mesa: Build libmesa_main for Android > dri/Makefile.defines: Remove non-existent dir from include paths > dri/Makefile.defines: Convert all variables to be simply-expanded > dri/Makefile.defines: Only add -Iserver to includes if the dir exists > dri/Makefile.defines: Cleanup filepaths for Android > i965: New file sources.mk > i965: Include sources.mk in Makefile > i965: Build libi965_dri on Android > > Android.mk | 68 +++ > android/mesa_local_vars.mk | 32 + > src/Android.mk | 1 + > src/mapi/Android.mk | 1 + > src/mapi/shared-glapi/Android.mk | 95 ++ > src/mesa/Android.mk | 63 + > src/mesa/drivers/Android.mk | 1 + > src/mesa/drivers/dri/Android.mk | 33 + > src/mesa/drivers/dri/Makefile.defines | 61 ++--- > src/mesa/drivers/dri/Makefile.targets | 5 ++ > src/mesa/drivers/dri/i965/Android.mk | 61 + > src/mesa/drivers/dri/i965/Makefile | 119 > + > src/mesa/drivers/dri/i965/sources.mk | 115 +++ > src/mesa/main/compiler.h | 2 +- > src/mesa/main/es_generator.py
Re: [Mesa-dev] Status of the GLSL->TGSI translator, part 2
On 08/04/2011 10:53 AM, Bryan Cain wrote: On 08/04/2011 08:24 AM, Brian Paul wrote: On Tue, Aug 2, 2011 at 3:50 PM, Bryan Cain wrote: On 08/02/2011 11:27 AM, Brian Paul wrote: On 08/01/2011 12:38 PM, Bryan Cain wrote: Since Mesa 7.11 is released now, I figure it's time to discuss merging the glsl-to-tgsi branch to master again. The translator is more mature than last time. There are no regressions that I know of on any driver. The code generation has improved so that it's the same as or better than ir_to_mesa in almost every case. It also will still emit TGSI integer opcodes if you change ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers can use this to implement these opcodes in their drivers, since they will be needed for GLSL 1.30 eventually. Are there any objections to merging it to master now? If there aren't, I'll revise some of the commit messages for correctness and wrap long lines since cgit doesn't do that automatically, then merge it after getting approval. Sounds OK to me. I was just skimming over the new stuff - it looks like create_color_map_texture() is duplicated in two files and could be shared. -Brian Yes, where should the function go and what header should it be declared in? It appears to me that none of the functions in st_atom_*.c are declared directly in header files. How about st_texture.[ch]? That's where st_texture_create() lives. Okay, done. Is there anything else that should be done, or is it ready to merge to master? I have no objections. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL->TGSI translator, part 2
On 08/04/2011 08:24 AM, Brian Paul wrote: > On Tue, Aug 2, 2011 at 3:50 PM, Bryan Cain wrote: >> On 08/02/2011 11:27 AM, Brian Paul wrote: >>> On 08/01/2011 12:38 PM, Bryan Cain wrote: Since Mesa 7.11 is released now, I figure it's time to discuss merging the glsl-to-tgsi branch to master again. The translator is more mature than last time. There are no regressions that I know of on any driver. The code generation has improved so that it's the same as or better than ir_to_mesa in almost every case. It also will still emit TGSI integer opcodes if you change ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers can use this to implement these opcodes in their drivers, since they will be needed for GLSL 1.30 eventually. Are there any objections to merging it to master now? If there aren't, I'll revise some of the commit messages for correctness and wrap long lines since cgit doesn't do that automatically, then merge it after getting approval. >>> Sounds OK to me. >>> >>> I was just skimming over the new stuff - it looks like >>> create_color_map_texture() is duplicated in two files and could be >>> shared. >>> >>> -Brian >> Yes, where should the function go and what header should it be declared >> in? It appears to me that none of the functions in st_atom_*.c are >> declared directly in header files. > How about st_texture.[ch]? That's where st_texture_create() lives. Okay, done. Is there anything else that should be done, or is it ready to merge to master? Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600
fykc...@gmail.com wrote: Does it work now then? No, it renders a corrupted playback http://dev.lemote.com/files/upload/software/temp/newmobcal1920-playback.png I guess that may be related with driver or DRM stack, after playback, my desktop corrupts http://dev.lemote.com/files/upload/software/temp/newmobcal1920-desktop-corrupt.png (Similar with "-vc ffmpeg12vdpau -vo vdpau). I don't know how close to rv670 rs780 is, but I have artifact issues with my rv670 that don't show with my rv790. If you can get it to display I would interested what - http://www.andyqos.ukfsn.org/Pendulum.mpg No, this renders a corrupted playback http://dev.lemote.com/files/upload/software/temp/Pendulum-playback.png, but doesn't cause my desktop corruption. These look far worse than I see, and I get no desktop corruption, so as Christian says it's probably not the same issue. mplayer -lavdopts threads=4 will use all of your cores. That still doesn't use all CPU power(even with thread=8) according to top. I guess a single core is maxed - press 1 (one) while top is running to see separate lines for each core. By chance it seems that your big buck bunny does not work with multithread. I don't see any difference either - probably because it's too simple, mediainfo shows it as using Main@L3.1 with no CABAC If I test with something that uses High@L5.1 and CABAC eg. http://www.andyqos.ukfsn.org/Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv Then I see a 3x increase between 1 and 4 threads. With: 1. Option "SwapbuffersWait" "off" 2. xvattr -a XV_VSYNC -v 0 3. Use metacity instead of compiz 4. "mplayer -nosound -benchmark -lavdopts threads=N -vo xv video-test/big_buck_bunny_720p_h264.mov" threads=1 vs threads=4, the result showed little difference: * 1 thread: 1519.509s * 4 threads: 1486.825s The details http://dev.lemote.com/files/upload/software/temp/thread_1.log vs http://dev.lemote.com/files/upload/software/temp/thread_4.log Hmm, that's really slow. I guess I am spoiled by mplayer/ffmpeg using asm and mmx. Even if I force my CPUs to 800MHz I can play that stream at almost 2X speed. Maybe it would be worth researching whether there are compile tweaks you can use for your arch with ffmpeg and mplayer. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Implement HW accelerated GL_SELECT
--- src/mesa/SConscript |1 + src/mesa/main/fbobject.c | 16 +- src/mesa/main/fbobject.h |6 + src/mesa/sources.mak |1 + src/mesa/state_tracker/st_cb_feedback.c | 21 +- src/mesa/state_tracker/st_context.h | 10 + src/mesa/state_tracker/st_draw.h | 17 + src/mesa/state_tracker/st_draw_select_emul.c | 490 ++ 8 files changed, 549 insertions(+), 13 deletions(-) create mode 100644 src/mesa/state_tracker/st_draw_select_emul.c diff --git a/src/mesa/SConscript b/src/mesa/SConscript index 24e2155..288b162 100644 --- a/src/mesa/SConscript +++ b/src/mesa/SConscript @@ -262,6 +262,7 @@ statetracker_sources = [ 'state_tracker/st_debug.c', 'state_tracker/st_draw.c', 'state_tracker/st_draw_feedback.c', +'state_tracker/st_draw_select_emul.c', 'state_tracker/st_extensions.c', 'state_tracker/st_format.c', 'state_tracker/st_gen_mipmap.c', diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c index 82eb7fb..1aea62b 100644 --- a/src/mesa/main/fbobject.c +++ b/src/mesa/main/fbobject.c @@ -1560,8 +1560,8 @@ _mesa_IsFramebufferEXT(GLuint framebuffer) * (render to texture). Call ctx->Driver.RenderTexture() for such * attachments. */ -static void -check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb) +void +_mesa_check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb) { GLuint i; ASSERT(ctx->Driver.RenderTexture); @@ -1583,8 +1583,8 @@ check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb) * If so, call ctx->Driver.FinishRenderTexture() for each texture to * notify the device driver that the texture image may have changed. */ -static void -check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb) +void +_mesa_check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb) { if (is_winsys_fbo(fb)) return; /* can't render to texture with winsys framebuffers */ @@ -1713,7 +1713,7 @@ _mesa_BindFramebufferEXT(GLenum target, GLuint framebuffer) FLUSH_VERTICES(ctx, _NEW_BUFFERS); /* check if old readbuffer was render-to-texture */ - check_end_texture_render(ctx, oldReadFb); + _mesa_check_end_texture_render(ctx, oldReadFb); _mesa_reference_framebuffer(&ctx->ReadBuffer, newReadFb); } @@ -1723,13 +1723,13 @@ _mesa_BindFramebufferEXT(GLenum target, GLuint framebuffer) /* check if old read/draw buffers were render-to-texture */ if (!bindReadBuf) - check_end_texture_render(ctx, oldReadFb); + _mesa_check_end_texture_render(ctx, oldReadFb); if (oldDrawFb != oldReadFb) - check_end_texture_render(ctx, oldDrawFb); + _mesa_check_end_texture_render(ctx, oldDrawFb); /* check if newly bound framebuffer has any texture attachments */ - check_begin_texture_render(ctx, newDrawFb); + _mesa_check_begin_texture_render(ctx, newDrawFb); _mesa_reference_framebuffer(&ctx->DrawBuffer, newDrawFb); } diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h index 7eb2005..ca6251c 100644 --- a/src/mesa/main/fbobject.h +++ b/src/mesa/main/fbobject.h @@ -101,6 +101,12 @@ _mesa_is_legal_color_format(const struct gl_context *ctx, GLenum baseFormat); extern GLenum _mesa_base_fbo_format(struct gl_context *ctx, GLenum internalFormat); +extern void +_mesa_check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb); + +extern void +_mesa_check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb); + extern GLboolean GLAPIENTRY _mesa_IsRenderbufferEXT(GLuint renderbuffer); diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak index 4b2ec08..9af4079 100644 --- a/src/mesa/sources.mak +++ b/src/mesa/sources.mak @@ -229,6 +229,7 @@ STATETRACKER_SOURCES = \ state_tracker/st_debug.c \ state_tracker/st_draw.c \ state_tracker/st_draw_feedback.c \ + state_tracker/st_draw_select_emul.c \ state_tracker/st_extensions.c \ state_tracker/st_format.c \ state_tracker/st_gen_mipmap.c \ diff --git a/src/mesa/state_tracker/st_cb_feedback.c b/src/mesa/state_tracker/st_cb_feedback.c index 9b85a39..c96c97c 100644 --- a/src/mesa/state_tracker/st_cb_feedback.c +++ b/src/mesa/state_tracker/st_cb_feedback.c @@ -276,17 +276,28 @@ st_RenderMode(struct gl_context *ctx, GLenum newMode ) { struct st_context *st = st_context(ctx); struct draw_context *draw = st->draw; + bool hw_acc_path = _mesa_getenv("MESA_HW_SELECT") && !st->select_emul.hw_unsupported; if (newMode == GL_RENDER) { /* restore normal VBO draw function */ vbo_set_draw_func(ctx, st_draw_vbo); } else if (newMode == GL_SELECT) { - if (!st->selection_stage) - st->selection_stage = draw_glselect_stage(ctx, draw); - d
[Mesa-dev] [PATCH] Implement HW accelerated GL_SELECT
--- src/mesa/SConscript |1 + src/mesa/main/fbobject.c | 16 +- src/mesa/main/fbobject.h |6 + src/mesa/sources.mak |1 + src/mesa/state_tracker/st_cb_feedback.c | 21 +- src/mesa/state_tracker/st_context.h | 10 + src/mesa/state_tracker/st_draw.h | 17 + src/mesa/state_tracker/st_draw_select_emul.c | 468 ++ 8 files changed, 527 insertions(+), 13 deletions(-) create mode 100644 src/mesa/state_tracker/st_draw_select_emul.c diff --git a/src/mesa/SConscript b/src/mesa/SConscript index 24e2155..288b162 100644 --- a/src/mesa/SConscript +++ b/src/mesa/SConscript @@ -262,6 +262,7 @@ statetracker_sources = [ 'state_tracker/st_debug.c', 'state_tracker/st_draw.c', 'state_tracker/st_draw_feedback.c', +'state_tracker/st_draw_select_emul.c', 'state_tracker/st_extensions.c', 'state_tracker/st_format.c', 'state_tracker/st_gen_mipmap.c', diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c index 82eb7fb..1aea62b 100644 --- a/src/mesa/main/fbobject.c +++ b/src/mesa/main/fbobject.c @@ -1560,8 +1560,8 @@ _mesa_IsFramebufferEXT(GLuint framebuffer) * (render to texture). Call ctx->Driver.RenderTexture() for such * attachments. */ -static void -check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb) +void +_mesa_check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb) { GLuint i; ASSERT(ctx->Driver.RenderTexture); @@ -1583,8 +1583,8 @@ check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb) * If so, call ctx->Driver.FinishRenderTexture() for each texture to * notify the device driver that the texture image may have changed. */ -static void -check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb) +void +_mesa_check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb) { if (is_winsys_fbo(fb)) return; /* can't render to texture with winsys framebuffers */ @@ -1713,7 +1713,7 @@ _mesa_BindFramebufferEXT(GLenum target, GLuint framebuffer) FLUSH_VERTICES(ctx, _NEW_BUFFERS); /* check if old readbuffer was render-to-texture */ - check_end_texture_render(ctx, oldReadFb); + _mesa_check_end_texture_render(ctx, oldReadFb); _mesa_reference_framebuffer(&ctx->ReadBuffer, newReadFb); } @@ -1723,13 +1723,13 @@ _mesa_BindFramebufferEXT(GLenum target, GLuint framebuffer) /* check if old read/draw buffers were render-to-texture */ if (!bindReadBuf) - check_end_texture_render(ctx, oldReadFb); + _mesa_check_end_texture_render(ctx, oldReadFb); if (oldDrawFb != oldReadFb) - check_end_texture_render(ctx, oldDrawFb); + _mesa_check_end_texture_render(ctx, oldDrawFb); /* check if newly bound framebuffer has any texture attachments */ - check_begin_texture_render(ctx, newDrawFb); + _mesa_check_begin_texture_render(ctx, newDrawFb); _mesa_reference_framebuffer(&ctx->DrawBuffer, newDrawFb); } diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h index 7eb2005..ca6251c 100644 --- a/src/mesa/main/fbobject.h +++ b/src/mesa/main/fbobject.h @@ -101,6 +101,12 @@ _mesa_is_legal_color_format(const struct gl_context *ctx, GLenum baseFormat); extern GLenum _mesa_base_fbo_format(struct gl_context *ctx, GLenum internalFormat); +extern void +_mesa_check_begin_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb); + +extern void +_mesa_check_end_texture_render(struct gl_context *ctx, struct gl_framebuffer *fb); + extern GLboolean GLAPIENTRY _mesa_IsRenderbufferEXT(GLuint renderbuffer); diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak index 4b2ec08..9af4079 100644 --- a/src/mesa/sources.mak +++ b/src/mesa/sources.mak @@ -229,6 +229,7 @@ STATETRACKER_SOURCES = \ state_tracker/st_debug.c \ state_tracker/st_draw.c \ state_tracker/st_draw_feedback.c \ + state_tracker/st_draw_select_emul.c \ state_tracker/st_extensions.c \ state_tracker/st_format.c \ state_tracker/st_gen_mipmap.c \ diff --git a/src/mesa/state_tracker/st_cb_feedback.c b/src/mesa/state_tracker/st_cb_feedback.c index 9b85a39..c96c97c 100644 --- a/src/mesa/state_tracker/st_cb_feedback.c +++ b/src/mesa/state_tracker/st_cb_feedback.c @@ -276,17 +276,28 @@ st_RenderMode(struct gl_context *ctx, GLenum newMode ) { struct st_context *st = st_context(ctx); struct draw_context *draw = st->draw; + bool hw_acc_path = _mesa_getenv("MESA_HW_SELECT") && !st->select_emul.hw_unsupported; if (newMode == GL_RENDER) { /* restore normal VBO draw function */ vbo_set_draw_func(ctx, st_draw_vbo); } else if (newMode == GL_SELECT) { - if (!st->selection_stage) - st->selection_stage = draw_glselect_stage(ctx, draw); - d
Re: [Mesa-dev] [PATCH] intel: Set ctx's drawbuffer according to drawables visual
On Thu, 4 Aug 2011 14:31:01 +0200, Benjamin Franzke wrote: > Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588 > > egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and > WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to > GL_BACK. > If a pixmap surface is created egl_dri2 will use a single buffer config, > so MakeCurrent has to adjust DrawBuffer[0] to the current drawable. > --- > src/mesa/drivers/dri/intel/intel_context.c |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/src/mesa/drivers/dri/intel/intel_context.c > b/src/mesa/drivers/dri/intel/intel_context.c > index fe8be08..0eeffc0 100644 > --- a/src/mesa/drivers/dri/intel/intel_context.c > +++ b/src/mesa/drivers/dri/intel/intel_context.c > @@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv, >readFb = driReadPriv->driverPrivate; >driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1; >driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1; > + > + if (fb->Visual.doubleBufferMode) { > +intel->ctx.Color.DrawBuffer[0] = GL_BACK; > + } else { > +intel->ctx.Color.DrawBuffer[0] = GL_FRONT; > + } >} Something touching this seems like it should live in _mesa_make_current, not as a driver workaround. pgpzYuxltFRgk.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/15] dri/Makefile.defines: Only add -Iserver to includes if the dir exists
On Thu, 4 Aug 2011 02:47:20 -0700, Chad Versace wrote: > Without this change, the next commit breaks the i915 and i965 builds. > > CC: Chia-I Wu , > CC: Chih-Wei Huang > Signed-off-by: Chad Versace > --- > src/mesa/drivers/dri/Makefile.defines |5 - > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/src/mesa/drivers/dri/Makefile.defines > b/src/mesa/drivers/dri/Makefile.defines > index 1ee6ce2..3235bdc 100644 > --- a/src/mesa/drivers/dri/Makefile.defines > +++ b/src/mesa/drivers/dri/Makefile.defines > @@ -15,13 +15,16 @@ COMMON_SOURCES := $(COMMON_GALLIUM_SOURCES) \ > SHARED_INCLUDES := \ > -I. \ > -I$(TOP)/src/mesa/drivers/dri/common \ > - -Iserver \ > -I$(TOP)/include \ > -I$(TOP)/src/mapi \ > -I$(TOP)/src/mesa \ > -I$(TOP)/src/egl/main \ > $(LIBDRM_CFLAGS) > > +ifeq (0, $(shell test -d server; echo $?)) > + SHARED_INCLUDES += -Iserver > +endif > + > INCLUDES := $(SHARED_INCLUDES) $(EXPAT_INCLUDES) > INCLUDES += $(API_DEFINES) Or we could just shove the -Iserver down into the DRI1 drivers. pgp1jJMnij6Qc.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/15] main: Remove problematic #include on Android
On Thu, 4 Aug 2011 02:47:15 -0700, Chad Versace wrote: > Remove ``#include `` from compiler.h. > > Note: This is in preparation for porting i965 to Android. > CC: Chia-I Wu , > CC: Chih-Wei Huang > Signed-off-by: Chad Versace > --- > src/mesa/main/compiler.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h > index d736fdf..3981644 100644 > --- a/src/mesa/main/compiler.h > +++ b/src/mesa/main/compiler.h > @@ -45,7 +45,7 @@ > #include > #include > #include > -#if defined(__linux__) && defined(__i386__) > +#if defined(__linux__) && defined(__i386__) && !defined(ANDROID) > #include > #endif > #include > -- > 1.7.6 I've noticed that this include is missing on my debian cross-build environment too. Can we tell if it's even required on linux 386 any more? I doesn't appear to be to me. pgplPSV9dWTmX.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glsl: When linking, emit functions at the tail of the final linked program.
On Wed, 3 Aug 2011 17:07:42 -0700, Paul Berry wrote: > When link_functions.cpp adds a new function to the final linked > program, it needs to add it after any global variable declarations > that the function refers to, otherwise the IR will be invalid (because > variable declarations must occur before variable accesses). The > easiest way to do that is to have the linker emit functions to the > tail of the final linked program. > > The linker used to emit functions to the head of the final linked > program, in an effort to keep callees sorted before their callers. > However, this was not reliable: it didn't work for functions declared > or defined in the same compilation unit as main, for diamond-shaped > patterns in the call graph, or for some obscure cases involving > overloaded functions. And no code currently relies on this sort > order. Usually we'd swap the order of these around, so that if we have a testcase that would hit this, you don't get extra failures when a bisect lands on patch 1/2. pgp1UnG58uFg3.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Set ctx's drawbuffer according to drawables visual
2011/8/4 Brian Paul : > On 08/04/2011 07:39 AM, Benjamin Franzke wrote: >> >> 2011/8/4 Brian Paul: >>> >>> On 08/04/2011 06:31 AM, Benjamin Franzke wrote: Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588 egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to GL_BACK. If a pixmap surface is created egl_dri2 will use a single buffer config, so MakeCurrent has to adjust DrawBuffer[0] to the current drawable. --- src/mesa/drivers/dri/intel/intel_context.c | 6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index fe8be08..0eeffc0 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv, readFb = driReadPriv->driverPrivate; driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1; driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1; + + if (fb->Visual.doubleBufferMode) { + intel->ctx.Color.DrawBuffer[0] = GL_BACK; + } else { + intel->ctx.Color.DrawBuffer[0] = GL_FRONT; + } } intel_prepare_render(intel); >>> >>> This doesn't seem right to me. We shouldn't be changing context state >>> like >>> that during a make-current() call. >>> >>> During context initialization we call _mesa_init_color() where we set >>> ctx->Color.DrawBuffer[0] to either GL_BACK or GL_FRONT depending on the >>> visual's double-buffer flag. You might investigate why that's not doing >>> the >>> job. >> >> Yea, I saw that, but the problem is it sets GL_BACK/GL_FRONT depending >> on the contexts config, >> which may be different from the config used for the drawable (as >> described in the commit message). >> >> So mixing configs could be defined as invalid, but its also allowed in >> src/mesa/main/context.c:1324 >> >> Furthermore st/mesa also modifes the state in make_current, see >> st_manager.c:781. >> >> Any ideas where to put it instead? > > OK, I see. How about doing something like this instead: > > ctx->Color.DrawBuffer[0] = ctx->DrawBuffer->ColorDrawBuffer[0]; > > The gl_framebuffer also carries the current drawbuffer state (since > GL_EXT_framebuffer_object came along). The framebuffer's state gets set > upon creation and when glDrawBuffer() is called. > > I think this is the behaviour that I'd expect if I were alternately > rendering to single and double-buffered windows with one context. > > What do you think? That looks like the better solution. I now think its not really the drivers task, to update the contexts Draw/ReadBuffer, so I'd put it directly into _mesa_make_current. New patch attached. Of course this implies that the framebuffer's ColorDrawBuffer/ColorReadBuffer is setup properly by all drivers. So do you think its safe to always copy those over in _mesa_make_current? Thanks so far. > BTW, we'd probably want to copy/update all elements of the ColorDrawBuffer[] > array plus the ColorReadBuffer state. > > -Brian > 0001-mesa-Apply-drawables-draw-readbuffers-to-context-in-.patch Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600
On Thu, Aug 4, 2011 at 10:26 AM, Christian König wrote: > Am Donnerstag, den 04.08.2011, 13:41 +0800 schrieb fykc...@gmail.com: >> I guess that may be related with driver or DRM stack, after playback, >> my desktop corrupts >> http://dev.lemote.com/files/upload/software/temp/newmobcal1920-desktop-corrupt.png >> (Similar with "-vc ffmpeg12vdpau -vo vdpau). > > I've seen something very similar at the very beginning of pipe-video > development, back then it was related to some invalid offset > calculations inside the kernel module, but that was fixed long ago. > Might try a newer kernel. > What we see here is definitely some corruption of vram wich isn't > related to video playback all together, maybe a piglit run could help > narrowing down the problem a bit. > >> > I don't know how close to rv670 rs780 is, but I have artifact issues with >> > my >> > rv670 that don't show with my rv790. > Not very, if I remember correctly rs780 is an igp chipset with r7xx > instruction set directly wired to the motherboard, while rv670 is an > "normal" PCIe card with r6xx instruction set. I was able to narrow down > your problems with the rv670 to somewhere in the instruction set > compiler, so I don't think that these two bugs are related to each > other. > RS780 actually has an r6xx-based (rv610) 3d core. RS880 is also r6xx (rv620) based. >> > If you can get it to display I would interested what - >> > >> > http://www.andyqos.ukfsn.org/Pendulum.mpg >> No, this renders a corrupted playback >> http://dev.lemote.com/files/upload/software/temp/Pendulum-playback.png, >> but doesn't cause my desktop corruption. > I would bet that it has something todo with the resolution/ maximum > texture size. Try the tex3d-maxsize and fbo-maxsize tests in piglit, and > see what the outcome of this is. > > Christian. > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Set ctx's drawbuffer according to drawables visual
On 08/04/2011 07:39 AM, Benjamin Franzke wrote: 2011/8/4 Brian Paul: On 08/04/2011 06:31 AM, Benjamin Franzke wrote: Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588 egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to GL_BACK. If a pixmap surface is created egl_dri2 will use a single buffer config, so MakeCurrent has to adjust DrawBuffer[0] to the current drawable. --- src/mesa/drivers/dri/intel/intel_context.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index fe8be08..0eeffc0 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv, readFb = driReadPriv->driverPrivate; driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1; driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1; + + if (fb->Visual.doubleBufferMode) { +intel->ctx.Color.DrawBuffer[0] = GL_BACK; + } else { +intel->ctx.Color.DrawBuffer[0] = GL_FRONT; + } } intel_prepare_render(intel); This doesn't seem right to me. We shouldn't be changing context state like that during a make-current() call. During context initialization we call _mesa_init_color() where we set ctx->Color.DrawBuffer[0] to either GL_BACK or GL_FRONT depending on the visual's double-buffer flag. You might investigate why that's not doing the job. Yea, I saw that, but the problem is it sets GL_BACK/GL_FRONT depending on the contexts config, which may be different from the config used for the drawable (as described in the commit message). So mixing configs could be defined as invalid, but its also allowed in src/mesa/main/context.c:1324 Furthermore st/mesa also modifes the state in make_current, see st_manager.c:781. Any ideas where to put it instead? OK, I see. How about doing something like this instead: ctx->Color.DrawBuffer[0] = ctx->DrawBuffer->ColorDrawBuffer[0]; The gl_framebuffer also carries the current drawbuffer state (since GL_EXT_framebuffer_object came along). The framebuffer's state gets set upon creation and when glDrawBuffer() is called. I think this is the behaviour that I'd expect if I were alternately rendering to single and double-buffered windows with one context. What do you think? BTW, we'd probably want to copy/update all elements of the ColorDrawBuffer[] array plus the ColorReadBuffer state. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: ctx->Driver.Map/UnmapTextureImage() hooks
Am Mittwoch, den 03.08.2011, 22:55 -0700 schrieb Eric Anholt: > On Wed, 27 Jul 2011 20:52:00 -0600, Brian Paul wrote: > > On Wed, Jul 27, 2011 at 7:29 PM, Eric Anholt wrote: > > > On Sat, 23 Jul 2011 11:58:22 -0600, Brian Paul > > > wrote: > > >> On Sat, Jul 23, 2011 at 9:14 AM, Eric Anholt wrote: > > >> > On Fri, 22 Jul 2011 14:06:48 -0600, Brian Paul > > >> > wrote: > > >> >> On 07/22/2011 01:32 PM, Eric Anholt wrote: > > >> >> > On Thu, 23 Jun 2011 19:08:51 -0600, Brian Paul > > >> >> > wrote: > > >> >> >> > > >> >> >> I'd like to overhaul the part of Mesa related to texture memory > > >> >> >> reading/writing. > > >> >> > > > >> >> > OK, I'm taking a look at map-texture-image-v4. I like what I'm > > >> >> > seeing > > >> >> > overall, I just want to be sure that this isn't something that gets > > >> >> > squash-merged. There's going to be breakage, and I want to be able > > >> >> > to > > >> >> > bisect into it. > > >> >> > > > >> >> > In the metaops code, please use glBufferData instead of > > >> >> > glBufferSubData. If you BufferSubData, I have to block on the GPU > > >> >> > if it > > >> >> > was using that buffer already. > > >> >> > > >> >> It looks like we'd have to change that in several other places too. > > >> >> Can we do that change later? > > >> >> > > >> >> > > >> >> > In the comments for void (*MapTextureImage), please note what the > > >> >> > units > > >> >> > of rowStride are. I see that's present in swrast later, but I > > >> >> > think the > > >> >> > mtypes.h and dd.h files are used for reference a lot (I do, > > >> >> > certainly). > > >> >> > > >> >> Will do. The parameter comments in s_texture.c are out of date too. > > >> >> > > >> >> > > >> >> > c029312ad62039904818a8b1765c6bcdf50044df is huge, and it doesn't > > >> >> > even > > >> >> > build. Ouch. I think there's some room for splitting some of this > > >> >> > up > > >> >> > so that we can get a nice series. > > >> >> > > >> >> Where's the build breakage? I don't remember that. > > >> >> > > >> >> This was originally a long series of sometimes ugly WIP patches. At > > >> >> one point I had a git mishap and trashed some of the intermediate > > >> >> patches. I agree that splitting up this commit would be good, but it > > >> >> would be a lot of work that I don't really have time for. > > >> >> > > >> >> It would be great if you could do a full piglit run with the branch > > >> >> and check for i965/i915 regressions. I'm not aware of any with swrast > > >> >> or gallium. I'd help diagnose any regressions. > > >> > > > >> > The piglit run was in bad shape and then hung the GPU, something that > > >> > piglit hasn't done for me in a long time. > > >> > > > >> > I think I'm going to need to split up the commits to make progress. > > >> > > >> OK, I'll try to find some time to do a piglit run on my i945 and see > > >> what's up (I don't have a i965 handy). I may not get to it for a few > > >> days though. > > > > > > I'm cutting up your patches into a reasonable series so that we can > > > actually review and bisect the code. So far I've run my mti-tested > > > branch on snb, and mti is your code I'm rebasing onto it as I cut chunks > > > out. > > > > Thanks for doing that. > > > > I found that the map-texture-image-v4 branch is missing some stuff > > that I lost during my git accident. I think I'm nearly done restoring > > it. I'll push it to the branch asap, maybe tonight. > > New mti-tested branch is up. Splitting up commits has paid off for at > least 3 regressions due to driver bugs so far that would have been awful > to work out otherwise. I'd like to land these bits before we try > tackling the rest of this mess (particularly the move of fields to > swrast didn't look like it was going to work for hardware driver > fallbacks, the way it was done). I'd also love to see some serious > review of this code. > > mti-tested is not regressing on intel. > > radeon is down to 1 regression on the very tip commit now that I got > some hardware -- gen-compressed-teximage fails because the GetTexImage() > of the meta-decompressed texture returns garbage. > > softpipe is thoroughly regressed, probably because I missed a required > change there. Just noticed it tonight, will look into it next. > > I expect nouveau is rather broken for compressed textures, because I > didn't catch it up to things I noticed while working on other drivers. > I'm hoping I have some hardware that works (is gf 7600/7800 the right > kind for this driver?), but I might not get to it before siggraph. No, gf7xxx is nvfx generation and has only a gallium driver. To test the vieux driver the newest card generation you could use is a geforce 4. > > My DRI1 system is so slow and buggy that I'm having a hard time testing > it. This branch shouldn't break anything there as far as I can see, but > I'll try again on testing. Also, we could delete a bunch of dri1 driver > code by implementing mapteximage in them instead. >
Re: [Mesa-dev] [status][help]pipe-video on Loongson3A(mipsel) platform with r600
Am Donnerstag, den 04.08.2011, 13:41 +0800 schrieb fykc...@gmail.com: > I guess that may be related with driver or DRM stack, after playback, > my desktop corrupts > http://dev.lemote.com/files/upload/software/temp/newmobcal1920-desktop-corrupt.png > (Similar with "-vc ffmpeg12vdpau -vo vdpau). I've seen something very similar at the very beginning of pipe-video development, back then it was related to some invalid offset calculations inside the kernel module, but that was fixed long ago. What we see here is definitely some corruption of vram wich isn't related to video playback all together, maybe a piglit run could help narrowing down the problem a bit. > > I don't know how close to rv670 rs780 is, but I have artifact issues with my > > rv670 that don't show with my rv790. Not very, if I remember correctly rs780 is an igp chipset with r7xx instruction set directly wired to the motherboard, while rv670 is an "normal" PCIe card with r6xx instruction set. I was able to narrow down your problems with the rv670 to somewhere in the instruction set compiler, so I don't think that these two bugs are related to each other. > > If you can get it to display I would interested what - > > > > http://www.andyqos.ukfsn.org/Pendulum.mpg > No, this renders a corrupted playback > http://dev.lemote.com/files/upload/software/temp/Pendulum-playback.png, > but doesn't cause my desktop corruption. I would bet that it has something todo with the resolution/ maximum texture size. Try the tex3d-maxsize and fbo-maxsize tests in piglit, and see what the outcome of this is. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Set ctx's drawbuffer according to drawables visual
2011/8/4 Brian Paul : > On 08/04/2011 06:31 AM, Benjamin Franzke wrote: >> >> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588 >> >> egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and >> WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to >> GL_BACK. >> If a pixmap surface is created egl_dri2 will use a single buffer config, >> so MakeCurrent has to adjust DrawBuffer[0] to the current drawable. >> --- >> src/mesa/drivers/dri/intel/intel_context.c | 6 ++ >> 1 files changed, 6 insertions(+), 0 deletions(-) >> >> diff --git a/src/mesa/drivers/dri/intel/intel_context.c >> b/src/mesa/drivers/dri/intel/intel_context.c >> index fe8be08..0eeffc0 100644 >> --- a/src/mesa/drivers/dri/intel/intel_context.c >> +++ b/src/mesa/drivers/dri/intel/intel_context.c >> @@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv, >> readFb = driReadPriv->driverPrivate; >> driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1; >> driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1; >> + >> + if (fb->Visual.doubleBufferMode) { >> + intel->ctx.Color.DrawBuffer[0] = GL_BACK; >> + } else { >> + intel->ctx.Color.DrawBuffer[0] = GL_FRONT; >> + } >> } >> >> intel_prepare_render(intel); > > This doesn't seem right to me. We shouldn't be changing context state like > that during a make-current() call. > > During context initialization we call _mesa_init_color() where we set > ctx->Color.DrawBuffer[0] to either GL_BACK or GL_FRONT depending on the > visual's double-buffer flag. You might investigate why that's not doing the > job. Yea, I saw that, but the problem is it sets GL_BACK/GL_FRONT depending on the contexts config, which may be different from the config used for the drawable (as described in the commit message). So mixing configs could be defined as invalid, but its also allowed in src/mesa/main/context.c:1324 Furthermore st/mesa also modifes the state in make_current, see st_manager.c:781. Any ideas where to put it instead? > > -Brian > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Set ctx's drawbuffer according to drawables visual
On 08/04/2011 06:31 AM, Benjamin Franzke wrote: Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588 egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to GL_BACK. If a pixmap surface is created egl_dri2 will use a single buffer config, so MakeCurrent has to adjust DrawBuffer[0] to the current drawable. --- src/mesa/drivers/dri/intel/intel_context.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index fe8be08..0eeffc0 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv, readFb = driReadPriv->driverPrivate; driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1; driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1; + + if (fb->Visual.doubleBufferMode) { +intel->ctx.Color.DrawBuffer[0] = GL_BACK; + } else { +intel->ctx.Color.DrawBuffer[0] = GL_FRONT; + } } intel_prepare_render(intel); This doesn't seem right to me. We shouldn't be changing context state like that during a make-current() call. During context initialization we call _mesa_init_color() where we set ctx->Color.DrawBuffer[0] to either GL_BACK or GL_FRONT depending on the visual's double-buffer flag. You might investigate why that's not doing the job. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vbo: do not call _mesa_max_buffer_index in debug builds
On 08/03/2011 11:44 PM, Marek Olšák wrote: That code drops performance in Unigine Heaven and Tropics by a factor of 10. That's too crazy even for a debug build. NOTE: This is a candidate for the 7.11 branch. --- src/mesa/vbo/vbo_exec_array.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c index b908d5a..32ce0e4 100644 --- a/src/mesa/vbo/vbo_exec_array.c +++ b/src/mesa/vbo/vbo_exec_array.c @@ -909,11 +909,10 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode, if (0) _mesa_print_arrays(ctx); -#ifdef DEBUG /* 'end' was out of bounds, but now let's check the actual array * indexes to see if any of them are out of bounds. */ - { + if (0) { GLuint max = _mesa_max_buffer_index(ctx, count, type, indices, ctx->Array.ElementArrayBufferObj); if (max>= ctx->Array.ArrayObj->_MaxElement) { @@ -934,7 +933,6 @@ vbo_exec_DrawRangeElementsBaseVertex(GLenum mode, * upper bound wrong. */ } -#endif /* Set 'end' to the max possible legal value */ assert(ctx->Array.ArrayObj->_MaxElement>= 1); Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL->TGSI translator, part 2
On Tue, Aug 2, 2011 at 3:50 PM, Bryan Cain wrote: > On 08/02/2011 11:27 AM, Brian Paul wrote: >> On 08/01/2011 12:38 PM, Bryan Cain wrote: >>> Since Mesa 7.11 is released now, I figure it's time to discuss merging >>> the glsl-to-tgsi branch to master again. The translator is more mature >>> than last time. There are no regressions that I know of on any driver. >>> The code generation has improved so that it's the same as or better than >>> ir_to_mesa in almost every case. >>> >>> It also will still emit TGSI integer opcodes if you change >>> ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers >>> can use this to implement these opcodes in their drivers, since they >>> will be needed for GLSL 1.30 eventually. >>> >>> Are there any objections to merging it to master now? If there aren't, >>> I'll revise some of the commit messages for correctness and wrap long >>> lines since cgit doesn't do that automatically, then merge it after >>> getting approval. >> >> Sounds OK to me. >> >> I was just skimming over the new stuff - it looks like >> create_color_map_texture() is duplicated in two files and could be >> shared. >> >> -Brian > > Yes, where should the function go and what header should it be declared > in? It appears to me that none of the functions in st_atom_*.c are > declared directly in header files. How about st_texture.[ch]? That's where st_texture_create() lives. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39813] Account request for Mesa git push access
https://bugs.freedesktop.org/show_bug.cgi?id=39813 Brian Paul changed: What|Removed |Added Product|Mesa|freedesktop.org Version|git |unspecified Component|Other |New Accounts AssignedTo|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes |org |ktop.org --- Comment #2 from Brian Paul 2011-08-04 06:22:19 PDT --- Reassigning to admins. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: Set ctx's drawbuffer according to drawables visual
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39588 egl_dri2 creates contexts with a doubleBufferConfig when PIXMAP and WINDOW bit is request, so _mesa_init_color sets DrawBuffer[0] to GL_BACK. If a pixmap surface is created egl_dri2 will use a single buffer config, so MakeCurrent has to adjust DrawBuffer[0] to the current drawable. --- src/mesa/drivers/dri/intel/intel_context.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index fe8be08..0eeffc0 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -970,6 +970,12 @@ intelMakeCurrent(__DRIcontext * driContextPriv, readFb = driReadPriv->driverPrivate; driContextPriv->dri2.draw_stamp = driDrawPriv->dri2.stamp - 1; driContextPriv->dri2.read_stamp = driReadPriv->dri2.stamp - 1; + + if (fb->Visual.doubleBufferMode) { +intel->ctx.Color.DrawBuffer[0] = GL_BACK; + } else { +intel->ctx.Color.DrawBuffer[0] = GL_FRONT; + } } intel_prepare_render(intel); -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the "S3TC issue"
On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/03/2011 12:11 PM, Bryan Cain wrote: > > On 08/03/2011 01:58 PM, Ian Romanick wrote: > >> I think this solves the issue for the compressor and for the software > >> decompressor. I don't think this solves the problem for the > >> decompressor for hardware drivers, so that may still pose a problem for > >> Linux distros. > > > > Pardon my ignorance, but why do hardware drivers need a decompressor? > > To quote the EXT_texture_compression_s3tc spec: > > WARNING: Vendors able to support S3TC texture compression in Direct3D > drivers do not necessarily have the right to use the same > functionality in > OpenGL. > > This is the same issue that Linux distros have with ARB_texture_float > being enabled in hardware drivers. The hardware may implement the > functionality, and the hardware vendor may have some license for the > patent, but that license may not cover making the functionality > available in Mesa. That S3 has sued Apple is some indication that these > licenses may have very narrow scope. Why should exactly Mesa be the one to have IP rights then? Mesa doesn't feed S3TC data anywhere, when using S2TC or another alternative. Feeding self-compressed S2TC data is no issue, as it doesn't use any of the S3TC IP. How the GPU actually decodes it, is none of Mesa's business. Feeding precompressed data, however, is also none of Mesa's business - and also, Mesa ALREADY does this, so if it's illegal, that's a risk Mesa already is taking. However, Mesa doesn't know if it's feeding S3TC or S2TC data - it feeds a data block as is. So, if anyone needs IP rights then, it's the author of the game that comes with precompressed S3TC textures - and not the graphics driver! Or does this cause a ridculous interpretation where Mesa COULD legally use this interface ONLY if it verifies the bitstream of the texture to see that no S3TC IP is used by it, or "fixes" it by turning S3TC into S2TC by a proper mapping of pixel values? At least that's my opinion (IANAL too). Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 15/15] i965: Build libi965_dri on Android
The driver doesn't work yet, it just builds. Currently, it's not being linked to libdrm. Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/Android.mk |7 src/mesa/drivers/Android.mk |1 + src/mesa/drivers/dri/Android.mk | 10 + src/mesa/drivers/dri/i965/Android.mk | 61 ++ 4 files changed, 79 insertions(+), 0 deletions(-) create mode 100644 src/mesa/drivers/Android.mk create mode 100644 src/mesa/drivers/dri/Android.mk create mode 100644 src/mesa/drivers/dri/i965/Android.mk diff --git a/src/mesa/Android.mk b/src/mesa/Android.mk index 11259e3..76f7930 100644 --- a/src/mesa/Android.mk +++ b/src/mesa/Android.mk @@ -54,3 +54,10 @@ LOCAL_C_SRCS := \ include $(MESA_LOCAL_VARS) include $(BUILD_STATIC_LIBRARY) + + +# +# Build drivers +# + +include $(LOCAL_PATH)/drivers/Android.mk diff --git a/src/mesa/drivers/Android.mk b/src/mesa/drivers/Android.mk new file mode 100644 index 000..5053e7d --- /dev/null +++ b/src/mesa/drivers/Android.mk @@ -0,0 +1 @@ +include $(call all-subdir-makefiles) diff --git a/src/mesa/drivers/dri/Android.mk b/src/mesa/drivers/dri/Android.mk new file mode 100644 index 000..0d016f3 --- /dev/null +++ b/src/mesa/drivers/dri/Android.mk @@ -0,0 +1,10 @@ +# +# Include the driver that the board requires. +# +# TODO: i915 +# TODO: gallium drivers +# + +ifeq ($(BOARD_USES_I965), true) + include $(MESA_TOP)/src/mesa/drivers/dri/i965/Android.mk +endif diff --git a/src/mesa/drivers/dri/i965/Android.mk b/src/mesa/drivers/dri/i965/Android.mk new file mode 100644 index 000..eecf28e --- /dev/null +++ b/src/mesa/drivers/dri/i965/Android.mk @@ -0,0 +1,61 @@ +# +# Copyright © 2011 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. +# + +LOCAL_PATH := $(call my-dir) +include $(CLEAR_VARS) + +LOCAL_MODULE := libi965_dri +LOCAL_MODULE_CLASS := SHARED_LIBRARIES +LOCAL_MODULE_TAGS := optional +LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/dri + +# Import the following variables: +# COMMON_SOURCES +# SHARED_INCLUDES +include $(MESA_TOP)/src/mesa/drivers/dri/Makefile.defines + +# Import the following variables: +# I965_C_SOURCES +# I965_CXX_SOURCES +include $(LOCAL_PATH)/sources.mk +I965_C_SOURCES := $(addprefix $(LOCAL_PATH)/, $(I965_C_SOURCES)) +I965_CXX_SOURCES := $(addprefix $(LOCAL_PATH)/, $(I965_CXX_SOURCES)) + +LOCAL_C_SOURCES := \ + $(COMMON_SOURCES) \ + $(I965_C_SOURCES) \ + $(I965_CXX_SOURCES) + +LOCAL_C_INCLUDES := \ + $(MESA_TOP)/src/mesa/drivers/dri/intel \ + $(SHARED_INCLUDES) + +# TODO: Link to libdrm once it is building on Android. +#LOCAL_SHARED_LIBRARIES := \ +# libdrm + +LOCAL_REQUIRED_MODULES := \ + libmesa_main + +include $(MESA_LOCAL_VARS) +include $(BUILD_SHARED_LIBRARY) -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 14/15] i965: Include sources.mk in Makefile
CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/Makefile | 119 +--- 1 files changed, 3 insertions(+), 116 deletions(-) diff --git a/src/mesa/drivers/dri/i965/Makefile b/src/mesa/drivers/dri/i965/Makefile index 44f28cd..14caf35 100644 --- a/src/mesa/drivers/dri/i965/Makefile +++ b/src/mesa/drivers/dri/i965/Makefile @@ -5,126 +5,13 @@ include $(TOP)/configs/current LIBNAME = i965_dri.so include ../Makefile.defines - -DRIVER_SOURCES = \ - intel_batchbuffer.c \ - intel_blit.c \ - intel_buffer_objects.c \ - intel_buffers.c \ - intel_clear.c \ - intel_context.c \ - intel_decode.c \ - intel_extensions.c \ - intel_extensions_es2.c \ - intel_fbo.c \ - intel_mipmap_tree.c \ - intel_regions.c \ - intel_screen.c \ - intel_span.c \ - intel_pixel.c \ - intel_pixel_bitmap.c \ - intel_pixel_copy.c \ - intel_pixel_draw.c \ - intel_pixel_read.c \ - intel_state.c \ - intel_syncobj.c \ - intel_tex.c \ - intel_tex_copy.c \ - intel_tex_format.c \ - intel_tex_image.c \ - intel_tex_layout.c \ - intel_tex_subimage.c \ - intel_tex_validate.c \ - brw_cc.c \ - brw_clip.c \ - brw_clip_line.c \ - brw_clip_point.c \ - brw_clip_state.c \ - brw_clip_tri.c \ - brw_clip_unfilled.c \ - brw_clip_util.c \ - brw_context.c \ - brw_curbe.c \ - brw_disasm.c \ - brw_draw.c \ - brw_draw_upload.c \ - brw_eu.c \ - brw_eu_debug.c \ - brw_eu_emit.c \ - brw_eu_util.c \ - brw_fallback.c \ - brw_gs.c \ - brw_gs_emit.c \ - brw_gs_state.c \ - brw_misc_state.c \ - brw_optimize.c \ - brw_program.c \ - brw_queryobj.c \ - brw_sf.c \ - brw_sf_emit.c \ - brw_sf_state.c \ - brw_state_batch.c \ - brw_state_cache.c \ - brw_state_dump.c \ - brw_state_upload.c \ - brw_tex.c \ - brw_tex_layout.c \ - brw_urb.c \ - brw_util.c \ - brw_vs.c \ - brw_vs_constval.c \ - brw_vs_emit.c \ - brw_vs_state.c \ - brw_vs_surface_state.c \ - brw_vtbl.c \ - brw_wm.c \ - brw_wm_debug.c \ - brw_wm_emit.c \ - brw_wm_fp.c \ - brw_wm_iz.c \ - brw_wm_pass0.c \ - brw_wm_pass1.c \ - brw_wm_pass2.c \ - brw_wm_sampler_state.c \ - brw_wm_state.c \ - brw_wm_surface_state.c \ - gen6_cc.c \ - gen6_clip_state.c \ - gen6_depthstencil.c \ - gen6_gs_state.c \ - gen6_sampler_state.c \ - gen6_scissor_state.c \ - gen6_sf_state.c \ - gen6_urb.c \ - gen6_viewport_state.c \ - gen6_vs_state.c \ - gen6_wm_state.c \ - gen7_cc_state.c \ - gen7_clip_state.c \ - gen7_disable.c \ - gen7_misc_state.c \ - gen7_sampler_state.c \ - gen7_sf_state.c \ - gen7_urb.c \ - gen7_viewport_state.c \ - gen7_vs_state.c \ - gen7_wm_state.c \ - gen7_wm_surface_state.c \ +include sources.mk C_SOURCES = \ $(COMMON_SOURCES) \ - $(DRIVER_SOURCES) + $(I965_C_SOURCES) -CXX_SOURCES = \ - brw_cubemap_normalize.cpp \ - brw_fs.cpp \ - brw_fs_emit.cpp \ - brw_fs_visitor.cpp \ - brw_fs_channel_expressions.cpp \ - brw_fs_reg_allocate.cpp \ - brw_fs_schedule_instructions.cpp \ - brw_fs_vector_splitting.cpp \ - brw_shader.cpp +CXX_SOURCES = $(I965_CXX_SOURCES) ASM_SOURCES = -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 13/15] i965: New file sources.mk
Copy the lists of sources from the actual Makefile into sources.mk. This is so the Makefile and (future) Android.mk can share the same lists. In the next commit, the Makefile will include sources.mk. Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/sources.mk | 115 ++ 1 files changed, 115 insertions(+), 0 deletions(-) create mode 100644 src/mesa/drivers/dri/i965/sources.mk diff --git a/src/mesa/drivers/dri/i965/sources.mk b/src/mesa/drivers/dri/i965/sources.mk new file mode 100644 index 000..470b7f1 --- /dev/null +++ b/src/mesa/drivers/dri/i965/sources.mk @@ -0,0 +1,115 @@ +I965_C_SOURCES := \ + intel_batchbuffer.c \ + intel_blit.c \ + intel_buffer_objects.c \ + intel_buffers.c \ + intel_clear.c \ + intel_context.c \ + intel_decode.c \ + intel_extensions.c \ + intel_extensions_es2.c \ + intel_fbo.c \ + intel_mipmap_tree.c \ + intel_regions.c \ + intel_screen.c \ + intel_span.c \ + intel_pixel.c \ + intel_pixel_bitmap.c \ + intel_pixel_copy.c \ + intel_pixel_draw.c \ + intel_pixel_read.c \ + intel_state.c \ + intel_syncobj.c \ + intel_tex.c \ + intel_tex_copy.c \ + intel_tex_format.c \ + intel_tex_image.c \ + intel_tex_layout.c \ + intel_tex_subimage.c \ + intel_tex_validate.c \ + brw_cc.c \ + brw_clip.c \ + brw_clip_line.c \ + brw_clip_point.c \ + brw_clip_state.c \ + brw_clip_tri.c \ + brw_clip_unfilled.c \ + brw_clip_util.c \ + brw_context.c \ + brw_curbe.c \ + brw_disasm.c \ + brw_draw.c \ + brw_draw_upload.c \ + brw_eu.c \ + brw_eu_debug.c \ + brw_eu_emit.c \ + brw_eu_util.c \ + brw_fallback.c \ + brw_gs.c \ + brw_gs_emit.c \ + brw_gs_state.c \ + brw_misc_state.c \ + brw_optimize.c \ + brw_program.c \ + brw_queryobj.c \ + brw_sf.c \ + brw_sf_emit.c \ + brw_sf_state.c \ + brw_state_batch.c \ + brw_state_cache.c \ + brw_state_dump.c \ + brw_state_upload.c \ + brw_tex.c \ + brw_tex_layout.c \ + brw_urb.c \ + brw_util.c \ + brw_vs.c \ + brw_vs_constval.c \ + brw_vs_emit.c \ + brw_vs_state.c \ + brw_vs_surface_state.c \ + brw_vtbl.c \ + brw_wm.c \ + brw_wm_debug.c \ + brw_wm_emit.c \ + brw_wm_fp.c \ + brw_wm_iz.c \ + brw_wm_pass0.c \ + brw_wm_pass1.c \ + brw_wm_pass2.c \ + brw_wm_sampler_state.c \ + brw_wm_state.c \ + brw_wm_surface_state.c \ + gen6_cc.c \ + gen6_clip_state.c \ + gen6_depthstencil.c \ + gen6_gs_state.c \ + gen6_sampler_state.c \ + gen6_scissor_state.c \ + gen6_sf_state.c \ + gen6_urb.c \ + gen6_viewport_state.c \ + gen6_vs_state.c \ + gen6_wm_state.c \ + gen7_cc_state.c \ + gen7_clip_state.c \ + gen7_disable.c \ + gen7_misc_state.c \ + gen7_sampler_state.c \ + gen7_sf_state.c \ + gen7_urb.c \ + gen7_viewport_state.c \ + gen7_vs_state.c \ + gen7_wm_state.c \ + gen7_wm_surface_state.c \ + +I965_CXX_SOURCES := \ + brw_cubemap_normalize.cpp \ + brw_fs.cpp \ + brw_fs_emit.cpp \ + brw_fs_visitor.cpp \ + brw_fs_channel_expressions.cpp \ + brw_fs_reg_allocate.cpp \ + brw_fs_schedule_instructions.cpp \ + brw_fs_vector_splitting.cpp \ + brw_shader.cpp -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/15] dri/Makefile.defines: Cleanup filepaths for Android
Cleanup 1: Android builds out-of-source, so all paths must be absolute. Cleanup 2: Include paths for Android cannot be prefixed with -I. (Goodbye pkgconfig). So define SHARED_INCLUDES without the -I's, and conditionally add them if doing a non-Android build. Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/drivers/dri/Makefile.defines | 50 +--- 1 files changed, 33 insertions(+), 17 deletions(-) diff --git a/src/mesa/drivers/dri/Makefile.defines b/src/mesa/drivers/dri/Makefile.defines index 3235bdc..71b7c7e 100644 --- a/src/mesa/drivers/dri/Makefile.defines +++ b/src/mesa/drivers/dri/Makefile.defines @@ -1,30 +1,46 @@ # -*-makefile-*- +ifneq ($(MESA_PLATFORM), android) + MESA_TOP = ../../../../.. + LOCAL_PATH = . +endif + COMMON_GALLIUM_SOURCES := \ -../common/utils.c \ -../common/vblank.c \ -../common/dri_util.c \ -../common/xmlconfig.c +$(MESA_TOP)/src/mesa/drivers/dri/common/utils.c \ +$(MESA_TOP)/src/mesa/drivers/dri/common/vblank.c \ +$(MESA_TOP)/src/mesa/drivers/dri/common/dri_util.c \ +$(MESA_TOP)/src/mesa/drivers/dri/common/xmlconfig.c COMMON_SOURCES := $(COMMON_GALLIUM_SOURCES) \ -../../common/driverfuncs.c \ -../common/texmem.c \ -../common/drirenderbuffer.c +$(MESA_TOP)/src/mesa/drivers/common/driverfuncs.c \ +$(MESA_TOP)/src/mesa/drivers/dri/common/texmem.c \ +$(MESA_TOP)/src/mesa/drivers/dri/common/drirenderbuffer.c ### Include directories SHARED_INCLUDES := \ - -I. \ - -I$(TOP)/src/mesa/drivers/dri/common \ - -I$(TOP)/include \ - -I$(TOP)/src/mapi \ - -I$(TOP)/src/mesa \ - -I$(TOP)/src/egl/main \ - $(LIBDRM_CFLAGS) - -ifeq (0, $(shell test -d server; echo $?)) - SHARED_INCLUDES += -Iserver + $(LOCAL_PATH) \ + $(MESA_TOP)/src/mesa/drivers/dri/common \ + $(MESA_TOP)/include \ + $(MESA_TOP)/src/mapi \ + $(MESA_TOP)/src/mesa \ + $(MESA_TOP)/src/egl/main + +ifeq (0, $(shell test -d $(LOCAL_PATH)/server; echo $?)) + SHARED_INCLUDES += $(LOCAL_PATH)/server endif +ifeq ($(MESA_PLATFORM), android) + SHARED_INCLUDES += \ + $(call include-path-for drm) \ + $(call include-path-for expat) +else + SHARED_INCLUDES := $(addprefix -I,$(SHARED_INCLUDES)) + SHARED_INCLUDES += \ + $(LIBDRM_CFLAGS) \ + $(EXPAT_INCLUDES) +endif # android + + INCLUDES := $(SHARED_INCLUDES) $(EXPAT_INCLUDES) INCLUDES += $(API_DEFINES) -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/15] dri/Makefile.defines: Only add -Iserver to includes if the dir exists
Without this change, the next commit breaks the i915 and i965 builds. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/drivers/dri/Makefile.defines |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/Makefile.defines b/src/mesa/drivers/dri/Makefile.defines index 1ee6ce2..3235bdc 100644 --- a/src/mesa/drivers/dri/Makefile.defines +++ b/src/mesa/drivers/dri/Makefile.defines @@ -15,13 +15,16 @@ COMMON_SOURCES := $(COMMON_GALLIUM_SOURCES) \ SHARED_INCLUDES := \ -I. \ -I$(TOP)/src/mesa/drivers/dri/common \ - -Iserver \ -I$(TOP)/include \ -I$(TOP)/src/mapi \ -I$(TOP)/src/mesa \ -I$(TOP)/src/egl/main \ $(LIBDRM_CFLAGS) +ifeq (0, $(shell test -d server; echo $?)) + SHARED_INCLUDES += -Iserver +endif + INCLUDES := $(SHARED_INCLUDES) $(EXPAT_INCLUDES) INCLUDES += $(API_DEFINES) -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/15] dri/Makefile.defines: Convert all variables to be simply-expanded
Convert all variables in Makefile.defines to be of the simply-expanded flavor. As a side-effect, OBJECTS must be moved from Makefile.defines to Makefile.targets. This commit is a cleanup for Android. Rationale - >From the GNU Make manual, Section 6.2 The Two Flavors of Variables: There are two ways that a variable in GNU make can have a value; we call them the two flavors of variables. The two flavors are distinguished in how they are defined and in what they do when expanded. [...] The first flavor of variable is a recursively expanded variable. [...] To avoid all the problems and inconveniences of recursively expanded variables, there is another flavor: simply expanded variables. There are two prominent properties of the Android build system that render the "problems and inconveniences of recursively expanded variables" fatally poisonous. 1. All components of the Android platform reside in a single source tree. 2. Android is built with a single, non-recursive invocation of `make`. Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/drivers/dri/Makefile.defines | 15 +-- src/mesa/drivers/dri/Makefile.targets |5 + 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/mesa/drivers/dri/Makefile.defines b/src/mesa/drivers/dri/Makefile.defines index 47a3c1b..1ee6ce2 100644 --- a/src/mesa/drivers/dri/Makefile.defines +++ b/src/mesa/drivers/dri/Makefile.defines @@ -1,25 +1,18 @@ # -*-makefile-*- -COMMON_GALLIUM_SOURCES = \ +COMMON_GALLIUM_SOURCES := \ ../common/utils.c \ ../common/vblank.c \ ../common/dri_util.c \ ../common/xmlconfig.c -COMMON_SOURCES = $(COMMON_GALLIUM_SOURCES) \ +COMMON_SOURCES := $(COMMON_GALLIUM_SOURCES) \ ../../common/driverfuncs.c \ ../common/texmem.c \ ../common/drirenderbuffer.c -INCLUDES = $(SHARED_INCLUDES) $(EXPAT_INCLUDES) - -OBJECTS = $(C_SOURCES:.c=.o) \ - $(CXX_SOURCES:.cpp=.o) \ - $(ASM_SOURCES:.S=.o) - - ### Include directories -SHARED_INCLUDES = \ +SHARED_INCLUDES := \ -I. \ -I$(TOP)/src/mesa/drivers/dri/common \ -Iserver \ @@ -29,5 +22,7 @@ SHARED_INCLUDES = \ -I$(TOP)/src/egl/main \ $(LIBDRM_CFLAGS) +INCLUDES := $(SHARED_INCLUDES) $(EXPAT_INCLUDES) INCLUDES += $(API_DEFINES) + CXXFLAGS += $(API_DEFINES) diff --git a/src/mesa/drivers/dri/Makefile.targets b/src/mesa/drivers/dri/Makefile.targets index 436b2a3..c269bfc 100644 --- a/src/mesa/drivers/dri/Makefile.targets +++ b/src/mesa/drivers/dri/Makefile.targets @@ -1,5 +1,10 @@ # -*-makefile-*- +OBJECTS := $(C_SOURCES:.c=.o) \ + $(CXX_SOURCES:.cpp=.o) \ + $(ASM_SOURCES:.S=.o) + + # RULES # .c.o: -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/15] dri/Makefile.defines: Remove non-existent dir from include paths
Remove src/egl/drivers/dri from SHARED_INCLUDES. That directory no longer exists. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/Makefile.defines |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/Makefile.defines b/src/mesa/drivers/dri/Makefile.defines index 19b6de8..47a3c1b 100644 --- a/src/mesa/drivers/dri/Makefile.defines +++ b/src/mesa/drivers/dri/Makefile.defines @@ -27,7 +27,6 @@ SHARED_INCLUDES = \ -I$(TOP)/src/mapi \ -I$(TOP)/src/mesa \ -I$(TOP)/src/egl/main \ - -I$(TOP)/src/egl/drivers/dri \ $(LIBDRM_CFLAGS) INCLUDES += $(API_DEFINES) -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/15] mesa: Build libmesa_main for Android
The libmesa_main.a built on Android is analagous to the libmesa.a built on Linux. The libname is libmesa_main, rather than libmesa, due to conventions of the Android build system. Names of intermediate libraries should be prefixes by the project name so to prevent naming collisions in the build tree. (For an example, grep for `libc_` in bionic's Makefiles). Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/Android.mk | 56 +++ 1 files changed, 56 insertions(+), 0 deletions(-) create mode 100644 src/mesa/Android.mk diff --git a/src/mesa/Android.mk b/src/mesa/Android.mk new file mode 100644 index 000..11259e3 --- /dev/null +++ b/src/mesa/Android.mk @@ -0,0 +1,56 @@ +# +# Copyright © 2011 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. +# +# Authors: +# Chad Versace +# + +# +# Build libmesa_main +# + +LOCAL_PATH := $(call my-dir) +include $(CLEAR_VARS) + +LOCAL_MODULE := libmesa_main +LOCAL_MODULE_CLASS := STATIC_LIBRARIES + +intermediates := $(call local-intermediates-dir) + +# Import the following variables: +# INCLUDE_DIRS +# MESA_SOURCES +# MESA_CXX_SOURCES +# MESA_ASM_SOURCES +include $(LOCAL_PATH)/sources.mak + +LOCAL_C_INCLUDES := \ + $(INCLUDE_DIRS) \ + $(intermediates) # For lex and yacc headers + +LOCAL_C_SRCS := \ + $(addprefix $(LOCAL_PATH)/, $(MESA_SOURCES)) \ + $(addprefix $(LOCAL_PATH)/, $(MESA_CXX_SOURCES)) \ + $(addprefix $(LOCAL_PATH)/, $(MESA_ASM_SOURCES)) + +include $(MESA_LOCAL_VARS) +include $(BUILD_STATIC_LIBRARY) -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/15] main: Add -o option to es_generator.py
The -o option specifies the output file. This is to pacify the Android build system, whose built-in rules for generated files become grumpy when shell redirection is used. Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/main/es_generator.py | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/es_generator.py b/src/mesa/main/es_generator.py index c0b0a44..21f59b4 100644 --- a/src/mesa/main/es_generator.py +++ b/src/mesa/main/es_generator.py @@ -125,10 +125,11 @@ program = os.path.basename(sys.argv[0]) verbose = 0 functionList = "APIspec.xml" version = "GLES1.1" +outputFile = None # Allow for command-line switches import getopt, time -options = "hvV:S:" +options = "hvV:S:o:" try: optlist, args = getopt.getopt(sys.argv[1:], options) except getopt.GetoptError, message: @@ -145,6 +146,7 @@ for option, optarg in optlist: for key in VersionSpecificValues.keys(): sys.stderr.write("%s - %s\n" % (key, VersionSpecificValues[key]['description'])) sys.stderr.write("-S specifies API specification file to use [%s]\n" % functionList) +sys.stderr.write("-o specifies output file [%s]\n") sys.exit(1) elif option == "-v": verbose += 1 @@ -152,6 +154,8 @@ for option, optarg in optlist: version = optarg elif option == "-S": functionList = optarg +elif option == "-o": +outputFile = optarg # Beyond switches, we support no further command-line arguments if len(args) > 0: @@ -168,6 +172,10 @@ versionHeader = VersionSpecificValues[version]['header'] versionExtHeader = VersionSpecificValues[version]['extheader'] shortname = VersionSpecificValues[version]['shortname'] +# Redirect output if option -o was given. +if outputFile is not None: +sys.stdout = open(outputFile, 'w') + # If we get to here, we're good to go. The "version" parameter # directs GetDispatchedFunctions to only allow functions from # that "category" (version in our parlance). This allows -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/15] main: Remove problematic #include on Android
Remove ``#include `` from compiler.h. Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/main/compiler.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h index d736fdf..3981644 100644 --- a/src/mesa/main/compiler.h +++ b/src/mesa/main/compiler.h @@ -45,7 +45,7 @@ #include #include #include -#if defined(__linux__) && defined(__i386__) +#if defined(__linux__) && defined(__i386__) && !defined(ANDROID) #include #endif #include -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/15] mesa/sources.mak: Change handling of lex and yacc files for Android
The proper way to handle lex and yacc files in Android is to include them in the list of C and CPP files and let the build system automagically do the right thing. Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/sources.mak | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak index 6800c47..9923133 100644 --- a/src/mesa/sources.mak +++ b/src/mesa/sources.mak @@ -244,11 +244,9 @@ STATETRACKER_SOURCES := \ PROGRAM_SOURCES := \ program/arbprogparse.c \ program/hash_table.c \ - program/lex.yy.c \ program/nvfragparse.c \ program/nvvertparse.c \ program/program.c \ - program/program_parse.tab.c \ program/program_parse_extra.c \ program/prog_cache.c \ program/prog_execute.c \ @@ -264,6 +262,15 @@ PROGRAM_SOURCES := \ program/register_allocate.c \ program/symbol_table.c +ifeq ($(ANDROID),) + PROGRAM_SOURCES += \ + program/program_parse.tab.c \ + program/lex.yy.c +else + PROGRAM_SOURCES += \ + program/program_parse.y \ + program/program_lexer.l +endif # ANDROID SHADER_CXX_SOURCES := \ program/ir_to_mesa.cpp \ -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/15] mesa/sources.mak: Cleanup include paths for Android
Include paths for Android cannot be prefixed with -I. So define INCLUDE_DIRS without the -I's, and add them only if doing a non-Android build. Also, define TOP for Android builds. Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/sources.mak | 20 ++-- 1 files changed, 14 insertions(+), 6 deletions(-) diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak index e45c99f..6800c47 100644 --- a/src/mesa/sources.mak +++ b/src/mesa/sources.mak @@ -1,5 +1,9 @@ ### Lists of source files, included by Makefiles +ifeq ($(MESA_PLATFORM), android) + TOP := $(MESA_TOP) +endif + # this is part of MAIN_SOURCES MAIN_ES_SOURCES := \ main/api_exec_es1.c \ @@ -371,9 +375,13 @@ GLSL_LIBS := \ ### Include directories INCLUDE_DIRS := \ - -I$(TOP)/include \ - -I$(TOP)/src/glsl \ - -I$(TOP)/src/mesa \ - -I$(TOP)/src/mapi \ - -I$(TOP)/src/gallium/include \ - -I$(TOP)/src/gallium/auxiliary + $(TOP)/include \ + $(TOP)/src/glsl \ + $(TOP)/src/mesa \ + $(TOP)/src/mapi \ + $(TOP)/src/gallium/include \ + $(TOP)/src/gallium/auxiliary + +ifneq ($(MESA_PLATFORM), android) + INCLUDE_DIRS := $(addprefix -I, $(INCLUDE_DIRS)) +endif -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/15] mesa/sources.mak: Convert all variables to be simply-expanded
This commit converts all variables in Makefile.defines to be of the simply-expanded flavor. This commit is a cleanup for Android. Rationale - >From the GNU Make manual, Section 6.2 The Two Flavors of Variables: There are two ways that a variable in GNU make can have a value; we call them the two flavors of variables. The two flavors are distinguished in how they are defined and in what they do when expanded. [...] The first flavor of variable is a recursively expanded variable. [...] To avoid all the problems and inconveniences of recursively expanded variables, there is another flavor: simply expanded variables. There are two prominent properties of the Android build system that render the "problems and inconveniences of recursively expanded variables" fatally poisonous. 1. All components of the Android platform reside in a single source tree. 2. Android is built with a single, non-recursive invocation of `make`. Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- src/mesa/sources.mak | 54 +- 1 files changed, 27 insertions(+), 27 deletions(-) diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak index 4b2ec08..e45c99f 100644 --- a/src/mesa/sources.mak +++ b/src/mesa/sources.mak @@ -1,11 +1,11 @@ ### Lists of source files, included by Makefiles # this is part of MAIN_SOURCES -MAIN_ES_SOURCES = \ +MAIN_ES_SOURCES := \ main/api_exec_es1.c \ main/api_exec_es2.c -MAIN_SOURCES = \ +MAIN_SOURCES := \ main/api_arrayelt.c \ main/api_exec.c \ main/api_loopback.c \ @@ -103,10 +103,10 @@ MAIN_SOURCES = \ main/vtxfmt.c \ $(MAIN_ES_SOURCES) -MAIN_CXX_SOURCES = \ +MAIN_CXX_SOURCES := \ main/ff_fragment_shader.cpp -MATH_SOURCES = \ +MATH_SOURCES := \ math/m_debug_clip.c \ math/m_debug_norm.c \ math/m_debug_xform.c \ @@ -115,10 +115,10 @@ MATH_SOURCES = \ math/m_translate.c \ math/m_vector.c -MATH_XFORM_SOURCES = \ +MATH_XFORM_SOURCES := \ math/m_xform.c -SWRAST_SOURCES = \ +SWRAST_SOURCES := \ swrast/s_aaline.c \ swrast/s_aatriangle.c \ swrast/s_accum.c \ @@ -148,11 +148,11 @@ SWRAST_SOURCES = \ swrast/s_triangle.c \ swrast/s_zoom.c -SWRAST_SETUP_SOURCES = \ +SWRAST_SETUP_SOURCES := \ swrast_setup/ss_context.c \ swrast_setup/ss_triangle.c -TNL_SOURCES = \ +TNL_SOURCES := \ tnl/t_context.c \ tnl/t_pipeline.c \ tnl/t_draw.c \ @@ -171,7 +171,7 @@ TNL_SOURCES = \ tnl/t_vertex_sse.c \ tnl/t_vertex_generic.c -VBO_SOURCES = \ +VBO_SOURCES := \ vbo/vbo_context.c \ vbo/vbo_exec.c \ vbo/vbo_exec_api.c \ @@ -187,7 +187,7 @@ VBO_SOURCES = \ vbo/vbo_save_draw.c \ vbo/vbo_save_loopback.c -STATETRACKER_SOURCES = \ +STATETRACKER_SOURCES := \ state_tracker/st_atom.c \ state_tracker/st_atom_blend.c \ state_tracker/st_atom_clip.c \ @@ -237,7 +237,7 @@ STATETRACKER_SOURCES = \ state_tracker/st_program.c \ state_tracker/st_texture.c -PROGRAM_SOURCES = \ +PROGRAM_SOURCES := \ program/arbprogparse.c \ program/hash_table.c \ program/lex.yy.c \ @@ -261,11 +261,11 @@ PROGRAM_SOURCES = \ program/symbol_table.c -SHADER_CXX_SOURCES = \ +SHADER_CXX_SOURCES := \ program/ir_to_mesa.cpp \ program/sampler.cpp -ASM_C_SOURCES =\ +ASM_C_SOURCES := \ x86/common_x86.c \ x86/x86_xform.c \ x86/3dnow.c \ @@ -275,7 +275,7 @@ ASM_C_SOURCES = \ ppc/common_ppc.c \ x86-64/x86-64.c -X86_SOURCES = \ +X86_SOURCES := \ x86/common_x86_asm.S\ x86/x86_xform2.S\ x86/x86_xform3.S\ @@ -294,21 +294,21 @@ X86_SOURCES = \ x86/sse_normal.S\ x86/read_rgba_span_x86.S -X86-64_SOURCES = \ +X86-64_SOURCES := \ x86-64/xform4.S -SPARC_SOURCES =\ +SPARC_SOURCES := \ sparc/clip.S\ sparc/norm.S\ sparc/xform.S -COMMON_DRIVER_SOURCES =\ +COMMON_DRIVER_SOURCES := \ drivers/common/driverfuncs.c\ drivers/common/meta.c # Sources for building non-Gallium drivers -MESA_SOURCES = \ +MESA_SOURCES := \ $(MAIN_SOURCES) \ $(MATH_SOURCES) \ $(MATH_XFORM_SOURCES) \ @@ -320,12 +320,12 @@ MESA_SOURCES = \ $(COMMON_DRIVER_SOURCES)\ $(ASM_C_SOURCES) -MESA_CXX_SOURCES = \ +MESA_CXX_SOURCES := \ $(MAIN_CXX_SOURCES) \ $(SHADER_CXX_SOURCES) # Sources for building Gallium drivers -MESA_GALLIUM_SOURCES = \ +MESA_G
[Mesa-dev] [PATCH 02/15] glapi: Build libmesa_glapi on Android
The libmesa_glapi.so on Android is analogous to the libglapi.so on Linux. libmesa_glapi uses the shared glapi. The libname is libmesa_glapi, rather than libglapi, due to conventions of the Android build system. Names of intermediate libraries should be prefixes by the project name so to prevent naming collisions in the build tree. (For an example, grep for `libc_` in bionic's Makefiles). Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- Android.mk |2 + src/Android.mk |1 + src/mapi/Android.mk |1 + src/mapi/shared-glapi/Android.mk | 95 ++ 4 files changed, 99 insertions(+), 0 deletions(-) create mode 100644 src/Android.mk create mode 100644 src/mapi/Android.mk create mode 100644 src/mapi/shared-glapi/Android.mk diff --git a/Android.mk b/Android.mk index 4158194..139491f 100644 --- a/Android.mk +++ b/Android.mk @@ -63,4 +63,6 @@ MESA_COMMON_CPPFLAGS := \ MESA_PYTHON2 := python2 MESA_PYTHON_FLAGS := -OO -tt +include $(call all-subdir-makefiles) + endif # !TARGET_SIMULATOR diff --git a/src/Android.mk b/src/Android.mk new file mode 100644 index 000..5053e7d --- /dev/null +++ b/src/Android.mk @@ -0,0 +1 @@ +include $(call all-subdir-makefiles) diff --git a/src/mapi/Android.mk b/src/mapi/Android.mk new file mode 100644 index 000..5053e7d --- /dev/null +++ b/src/mapi/Android.mk @@ -0,0 +1 @@ +include $(call all-subdir-makefiles) diff --git a/src/mapi/shared-glapi/Android.mk b/src/mapi/shared-glapi/Android.mk new file mode 100644 index 000..e77f346 --- /dev/null +++ b/src/mapi/shared-glapi/Android.mk @@ -0,0 +1,95 @@ +# +# Copyright © 2011 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. +# +# Authors: +# Chad Versace +# + +LOCAL_PATH := $(call my-dir) + +# +# Build libmesa_glapi +# + +include $(CLEAR_VARS) + +LOCAL_MODULE := libmesa_glapi +LOCAL_MODULE_CLASS := SHARED_LIBRARIES +LOCAL_MODULE_TAGS := optional + +intermediates := $(call local-intermediates-dir) + +# -- +# Define MAPI_GLAPI_SOURCES +# -- + +include $(MESA_TOP)/src/mapi/mapi/sources.mak +MAPI_GLAPI_SOURCES := $(addprefix $(MESA_TOP)/src/mapi/mapi/, $(MAPI_GLAPI_SOURCES)) + + +# -- +# Generate MESA_SHARED_GLAPI_H +# -- + +MESA_SHARED_GLAPI_H := $(intermediates)/glapi_mapi_tmp.h + +MESA_SHARED_GLAPI_H: PRIVATE_APIXML := $(MESA_TOP)/src/mapi/glapi/gen/gl_and_es_API.xml +MESA_SHARED_GLAPI_H: PRIVATE_XML_SOURCES := $(find $(MESA_TOP)/src/mapi/glapi/gen -name \"*.xml\") +MESA_SHARED_GLAPI_H: PRIVATE_GEN_SCRIPT := $(MESA_TOP)/src/mapi/mapi/mapi_abi.py +MESA_SHARED_GLAPI_H: PRIVATE_PY_SCRIPTS := $(find $(MESA_TOP)/src/mapi/glapi/gen -name \"*.py\") + +MESA_SHARED_GLAPI_H: PRIVATE_DEPS := \ + $(PRIVATE_XML_SOURCES) \ + $(PRIVATE_PY_SCRIPTS) + +MESA_SHARED_GLAPI_H: PRIVATE_TOOL := \ + $(MESA_PYTHON2) $(MESA_PYTHON2_FLAGS) $(PRIVATE_GEN_SCRIPT) \ + --printer shared-glapi \ + --mode lib \ + -o $(MESA_SHARED_GLAPI_H) \ + $(PRIVATE_APIXML) + +MESA_SHARED_GLAPI_H: $(PRIVATE_DEPS) + @echo XXX01 + $(call transform-generated-sources) + + +# -- + +LOCAL_C_FLAGS := + +LOCAL_CPPFLAGS := \ + -DMAPI_MODE_GLAPI \ + -DMAPI_ABI_HEADER=\"shared-glapi/glapi_mapi_tmp.h\" + +LOCAL_C_INCLUDES := \ + $(intermediates) \ + $(MESA_TOP)/src/mapi + +LOCAL_C_SOURCES := \ + $(MAPI_GLAPI_SOURCES) + +LOCAL_GENERATED_SOURCES := \ + $(MESA_SHARED_GLAPI_H) + +include
[Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
This is the first step in porting libGLES* and libEGL to Android. The makefile doesn't build anything yet; it just defines common variables. The values for MESA_COMMON_C_FLAGS and MESA_COMMON_CPP_FLAGS, I obtained by invoking autogen.sh with the options below and then inspecting MESA_TOP/configs/autoconf. My immediate goal is to port i965 to Android, so I used the typical flags for building i965. --disable-gallium --disable-glu --disable-glw --disable-glut --enable-32-bit --enable-egl --enable-gles2 --enable-gles1 --enable-texture-float --with-dri-drivers=i965 --with-gallium-drivers= Note: This is in preparation for porting i965 to Android. CC: Chia-I Wu , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- Android.mk | 66 android/mesa_local_vars.mk | 32 + 2 files changed, 98 insertions(+), 0 deletions(-) create mode 100644 Android.mk create mode 100644 android/mesa_local_vars.mk diff --git a/Android.mk b/Android.mk new file mode 100644 index 000..4158194 --- /dev/null +++ b/Android.mk @@ -0,0 +1,66 @@ +# +# Copyright © 2011 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. +# + +ifneq ($(TARGET_SIMULATOR),true) + +LOCAL_PATH := $(call my-dir) + +# Top directory of Mesa project. +MESA_TOP := $(LOCAL_PATH) + +MESA_PLATFORM := android + +# Each Android.mk must include MESA_LOCAL_VARS before "building" any targets. +MESA_LOCAL_VARS := $(LOCAL_PATH)/android/mesa_local_vars.mk + +MESA_COMMON_C_INCLUDES := \ + $(MESA_TOP)/include \ + $(MESA_TOP)/src + +MESA_COMMON_CFLAGS := \ + -std=c99 \ + \ + -Wall \ + -Wmissing-prototypes \ + -Wno-sign-compare \ + -Wno-sign-compare \ + \ + -ffast-math\ + -fvisibility=hidden\ + \ + -DFEATURE_ES1 \ + -DFEATURE_ES2 \ + -D_GNU_SOURCE \ + -DHAVE_POSIX_MEMALIGN \ + -DPTHREADS \ + -DTEXTURE_FLOAT_ENABLED\ + -DUSE_X86_ASM + +MESA_COMMON_CPPFLAGS := \ + -Wno-error=non-virtual-dtor \ + -Wno-non-virtual-dtor + +MESA_PYTHON2 := python2 +MESA_PYTHON_FLAGS := -OO -tt + +endif # !TARGET_SIMULATOR diff --git a/android/mesa_local_vars.mk b/android/mesa_local_vars.mk new file mode 100644 index 000..2f8abde --- /dev/null +++ b/android/mesa_local_vars.mk @@ -0,0 +1,32 @@ +# +# Copyright © 2011 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECT
[Mesa-dev] [PATCH 00/15] i965, mesa, glapi: Build libi965_dri on Android
This is the first step in porting i965 to Android, initially to Gingerbread. Android is ubiquituous now, and the platform's importance can't be denied. The Intel drivers really should support it. The series first builds libglapi, then libmesa, and then libi965_dri. lib965_dri doens't work yet; it doesn't even link to libdrm. This is just the initial work to get it to build. I'm aware that this may be controversial, so I've attempted to integrate the Android makefiles as non-disruptively as possible. - The Android makefiles attempt to duplicate as little as possible from the existing makefiles. In one case, this dictated that some Makefile code be extracted into a shared makefile. - I've avoided modifying the existsing makefiles except when absolutely necessary. When a modification or cleanup was necessary, I have attempted to keep the changes minimal and do them incrementally. - The locations of the Android makefiles mirror those of the existing makefiles. The series does not break the Linux i965 build. I doubt it breaks other drivers' builds, but I haven't tested it. If you want me to check that it doesn't break your build, just let me know the autoconf options. The series lives on my android-gingerbread-i965 branch. If you'd like to try the Android build yourself, you should pull from my personal Android manifest [1], which closely mirrors android-x86, and set `BOARD_USES_I965 := true` in buildspeck.mk. [1] repo init -u git://anongit.freedesktop.git/~chadversary/android.manifeset.git -b gingerbread-i965 Chad Versace (15): mesa: Add toplevel Android.mk glapi: Build libmesa_glapi on Android mesa/sources.mak: Convert all variables to be simply-expanded mesa/sources.mak: Cleanup include paths for Android mesa/sources.mak: Change handling of lex and yacc files for Android main: Remove problematic #include on Android main: Add -o option to es_generator.py mesa: Build libmesa_main for Android dri/Makefile.defines: Remove non-existent dir from include paths dri/Makefile.defines: Convert all variables to be simply-expanded dri/Makefile.defines: Only add -Iserver to includes if the dir exists dri/Makefile.defines: Cleanup filepaths for Android i965: New file sources.mk i965: Include sources.mk in Makefile i965: Build libi965_dri on Android Android.mk| 68 +++ android/mesa_local_vars.mk| 32 + src/Android.mk|1 + src/mapi/Android.mk |1 + src/mapi/shared-glapi/Android.mk | 95 ++ src/mesa/Android.mk | 63 + src/mesa/drivers/Android.mk |1 + src/mesa/drivers/dri/Android.mk | 33 + src/mesa/drivers/dri/Makefile.defines | 61 ++--- src/mesa/drivers/dri/Makefile.targets |5 ++ src/mesa/drivers/dri/i965/Android.mk | 61 + src/mesa/drivers/dri/i965/Makefile| 119 + src/mesa/drivers/dri/i965/sources.mk | 115 +++ src/mesa/main/compiler.h |2 +- src/mesa/main/es_generator.py | 10 +++- src/mesa/sources.mak | 87 ++-- 16 files changed, 576 insertions(+), 178 deletions(-) create mode 100644 Android.mk create mode 100644 android/mesa_local_vars.mk create mode 100644 src/Android.mk create mode 100644 src/mapi/Android.mk create mode 100644 src/mapi/shared-glapi/Android.mk create mode 100644 src/mesa/Android.mk create mode 100644 src/mesa/drivers/Android.mk create mode 100644 src/mesa/drivers/dri/Android.mk create mode 100644 src/mesa/drivers/dri/i965/Android.mk create mode 100644 src/mesa/drivers/dri/i965/sources.mk -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39588] [bisected] mesa demo xeglgears draw nothing if surface type is a pixmap
https://bugs.freedesktop.org/show_bug.cgi?id=39588 --- Comment #6 from Benjamin Franzke 2011-08-04 02:43:33 PDT --- Created an attachment (id=49902) View: https://bugs.freedesktop.org/attachment.cgi?id=49902 Review: https://bugs.freedesktop.org/review?bug=39588&attachment=49902 intel: Set ctx's drawbuffer according to drawables visual -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39588] [bisected] mesa demo xeglgears draw nothing if surface type is a pixmap
https://bugs.freedesktop.org/show_bug.cgi?id=39588 --- Comment #5 from Benjamin Franzke 2011-08-04 02:42:36 PDT --- (In reply to comment #4) > I've bisected this to: > > commit 87dde5b1cd596c4008695ff2db9469f88c09f925 > Author: Benjamin Franzke > Date: Wed Feb 9 15:30:20 2011 +0100 > > egl_dri2: Use double buffering for window surfaces > > We really should have piglit tests for drawing to pixmaps and pbuffers. > Simple > tests that just draw a single triangle should be sufficient. Ok, Thanks for bisecting. At the time of writing this patch I owned only radeon hardware, where it works (r600g). So a piglit test wouldnt have helped directly (sure, you'd have found it earlier). The commit was about using dri double buffer configs for window surfaces (made the wayland backend code nicer). This results in contexts being created with double buffer configs, which are somewhat mixed with single buffer configs, when using pixmap surfaces. Why does this work with r600g? st/mesa sets the context's DrawBuffer[0] depending on its visual render_buffer, which is set by st/dri depending on the drawables gl_config's doubleBufferMode. I'll attach a patch that does this for intel in make_current. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Patches to make Gallium drivers respect the force_s3tc_enable environment variable
On Mit, 2011-07-20 at 17:53 -0500, Bryan Cain wrote: > The purpose of the following two patches is to make st/mesa expose the S3TC > extensions when the force_s3tc_enable environment variable is used. This is > to match the behavior of the DRI drivers, in which force_s3tc_enable is an > option in driconf. Although st/mesa can't use the driconf functions, it can > at least respect the environment variable for this option. This may be adeuqate for now, but in the long term it would be better to properly hook up driconf, so e.g. this could be set on a per-app basis in ~/.drirc or /etc/drirc. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev