Re: [Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path
On Mon, Aug 22, 2016 at 14:18:51 -0700, Jason Ekstrand wrote: > On Mon, Aug 22, 2016 at 2:06 PM, Julien Cristau wrote: > > > On Fri, Aug 19, 2016 at 09:04:14 -0700, Jason Ekstrand wrote: > > > > > Not providing a path allows the ICD to work on multi-arch systems but > > > breaks it if you install anywhere other than /usr/lib. Given that users > > > may be installing locally in .local or similar, we probably do want to > > > provide a filename. Distros can carry a revert of this commit if they > > want > > > an intel_icd.json file without the path. > > > > > If a user is going to install stuff in .local, don't they have > > LD_LIBRARY_PATH pointing there too? > > > > Actually, no. The loader will look for ICD files in > .local/share/vulkan/icd.d and the ICD file will point to the right .so. It > should work out-of-the-box unless you either have a broken loader or we're > installing something wrong. So somehow they're only building the vulkan driver but not libGL or anything else? Still, I guess a bunch of people will need both a 32bit and a 64bit version of the driver. How is the 64-bit ~/.local/share/vulkan/icd.d/intel_icd.json not going to clash with the 32-bit ~/.local/share/vulkan/icd.d/intel_icd.json? I'm just not seeing how this solves the problem... Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path
On Fri, Aug 19, 2016 at 09:04:14 -0700, Jason Ekstrand wrote: > Not providing a path allows the ICD to work on multi-arch systems but > breaks it if you install anywhere other than /usr/lib. Given that users > may be installing locally in .local or similar, we probably do want to > provide a filename. Distros can carry a revert of this commit if they want > an intel_icd.json file without the path. > If a user is going to install stuff in .local, don't they have LD_LIBRARY_PATH pointing there too? Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path
On Fri, Aug 19, 2016 at 09:04:14 -0700, Jason Ekstrand wrote:
> diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
> index ad0148d..9fef960 100644
> --- a/src/intel/vulkan/Makefile.am
> +++ b/src/intel/vulkan/Makefile.am
> @@ -141,7 +141,7 @@ anv_timestamp.h:
> $(AM_V_GEN) echo "#define ANV_TIMESTAMP \"$(TIMESTAMP_CMD)\"" > $@
>
> BUILT_SOURCES = $(VULKAN_GENERATED_FILES)
> -CLEANFILES = $(BUILT_SOURCES) dev_icd.json
> +CLEANFILES = $(BUILT_SOURCES) dev_icd.json intel_icd.json
> EXTRA_DIST = \
> $(top_srcdir)/include/vulkan/vk_icd.h \
> anv_entrypoints_gen.py \
> @@ -170,6 +170,11 @@ dev_icd.json : dev_icd.json.in
> -e "s#@build_libdir@#${abs_top_builddir}/${LIB_DIR}#" \
> < $(srcdir)/dev_icd.json.in > $@
>
> +intel_icd.json : intel_icd.json.in
> + $(AM_V_GEN) $(SED) \
> + -e "s#@install_libdir@#${libdir}#" \
> + < $(srcdir)/intel_icd.json.in > $@
> +
> # Libvulkan with dummy gem. Used for unit tests.
> libvulkan_test_la_SOURCES = $(VULKAN_GEM_STUB_FILES)
> libvulkan_test_la_LIBADD = $(VULKAN_LIB_DEPS) -lX11-xcb
Incidentally, if intel_icd.json is generated then it should be removed
from EXTRA_DIST (but maybe intel_icd.json.in needs to be added?).
Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH demos 1/2] demos: Fix make distcheck
On Fri, Jul 4, 2014 at 11:10:22 +0200, Andreas Boll wrote: > Signed-off-by: Andreas Boll > --- > src/xdemos/Makefile.am | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > On Fri, Jul 4, 2014 at 11:10:23 +0200, Andreas Boll wrote: > Matches behavior with action-if-not-given > > Signed-off-by: Andreas Boll > --- > configure.ac | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > for the series: Reviewed-by: Julien Cristau Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i915: Fix up intelInitScreen2 for DRI3
On Thu, Jul 3, 2014 at 22:13:53 +0200, Adel Gadllah wrote: > Commit 442442026eb updated both i915 and i965 for DRI3 support, > but one check in intelInitScreen2 was missed for i915 causing crashes > when trying to use i915 with DRI3. > > So fix that up. > > Reported-by: Igor Gnatenko > Tested-by: František Zatloukal > Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1115323 > Cc: "10.2" > Signed-off-by: Adel Gadllah https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754297 Tested-by: Dirk Griesbach Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: link against -lLLVM to determine build type
On Wed, Aug 14, 2013 at 09:46:44 -0700, Tom Stellard wrote: > On Wed, Aug 14, 2013 at 09:08:55AM +0200, Maarten Lankhorst wrote: > > Op 14-08-13 04:37, Tom Stellard schreef: > > > On Tue, Aug 13, 2013 at 05:53:52PM +0200, Maarten Lankhorst wrote: > > >> Fixes a build failure of 9.2 on ubuntu, because libLLVM-3.3.so is not > > >> present in /usr/lib/llvm-3.2/lib. > > >> > > > I'm trying to understand the problem here, could you give a little more > > > information about how Ubuntu packages LLVM? Where are the LLVM > > > libraries installed and what does llvm-config --libdir --ldflags report? > > libLLVM-3.3.so gets installed in /usr/lib/x86_64-linux-gnu/libLLVM-3.3.so, > > there is no /usr/lib/llvm-3.2/lib/libLLVM-3.3.so > > All the other libs still get installed to /usr/lib/llvm-3.3/lib. > > > > ~$ llvm-config-3.3 --libdir --ldflags > > /usr/lib/llvm-3.3/lib > > -L/usr/lib/llvm-3.3/lib -lpthread -lffi -ldl -lm > > So, if /usr/lib/x86_64-linux-gnu/ is not in the ldflags, then how will > the linker find it? > It's in the default search path. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] automake: don't enable -Wl, --no-undefined on OpenBSD
On Thu, Apr 3, 2014 at 15:46:01 +1100, Jonathan Gray wrote: > OpenBSD does not have DT_NEEDED entries for libc by design, > over concerns how the symbols would be referenced after > changing the major version of the library. > > So avoid -no-undefined checks on OpenBSD as they will fail. > > v2: don't include the -no-undefined libtool option in the variable > and change -Wl,--no-undefined references in Automake.inc as well. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76856 > Signed-off-by: Jonathan Gray > --- > configure.ac| 13 + > src/egl/main/Makefile.am| 2 +- > src/egl/wayland/wayland-egl/Makefile.am | 2 +- > src/gallium/Automake.inc| 6 +++--- > src/gallium/targets/egl-static/Makefile.am | 2 +- > src/gallium/targets/gbm/Makefile.am | 2 +- > src/gallium/targets/libgl-xlib/Makefile.am | 2 +- > src/gallium/targets/opencl/Makefile.am | 2 +- > src/gallium/targets/osmesa/Makefile.am | 2 +- > src/gallium/targets/pipe-loader/Makefile.am | 2 +- > src/gallium/targets/xa/Makefile.am | 2 +- > src/gbm/Makefile.am | 2 +- > src/glx/Makefile.am | 2 +- > src/mapi/es1api/Makefile.am | 2 +- > src/mapi/es2api/Makefile.am | 2 +- > src/mapi/shared-glapi/Makefile.am | 2 +- > src/mapi/vgapi/Makefile.am | 2 +- > src/mesa/drivers/osmesa/Makefile.am | 2 +- > src/mesa/drivers/x11/Makefile.am| 2 +- > 19 files changed, 33 insertions(+), 20 deletions(-) > Hi, it looks like the committed version of this change doesn't include the configure.ac hunk. That makes it rather less useful. Did it get lost somehow? http://cgit.freedesktop.org/mesa/mesa/commit?id=11623be934f8573910484de2a5fb50c95f0a1d44 Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: correctly set LD_NO_UNDEFINED
On Tue, May 13, 2014 at 01:36:28 +0100, Emil Velikov wrote: > Commit 11623be934f85 was meant to have this hunk, which > I accidently dropped during git rebase. > > Cc: 10.2 > Signed-off-by: Emil Velikov Reviewed-by: Julien Cristau Thanks for the quick fix. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: fix build failure on powerpcspe
From: Roland Stigge In the case of powerpc, mesa activates some altivec instructions that are unknown on the powerpcspe architecture (see https://wiki.debian.org/PowerPCSPEPort), causing a build failure as the 'vand' opcode is not recognized by the assembler. This patch fixes this by preventing the PPC-specialcasing in case of powerpcspe (__NO_FPRS__ is only defined there). https://bugs.debian.org/695746 --- src/gallium/include/pipe/p_config.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/include/pipe/p_config.h b/src/gallium/include/pipe/p_config.h index d603681..8189a73 100644 --- a/src/gallium/include/pipe/p_config.h +++ b/src/gallium/include/pipe/p_config.h @@ -107,12 +107,14 @@ #endif #endif +#ifndef __NO_FPRS__ #if defined(__ppc__) || defined(__ppc64__) || defined(__PPC__) #define PIPE_ARCH_PPC #if defined(__ppc64__) || defined(__PPC64__) #define PIPE_ARCH_PPC_64 #endif #endif +#endif #if defined(__s390x__) #define PIPE_ARCH_S390 -- 1.9.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gbm: make 'devices' array static
It's only used in this one file as far as I can tell, and exporting a symbol named 'devices' from a shared library is a recipe for trouble. --- src/gbm/main/gbm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c index b057386..30785a6 100644 --- a/src/gbm/main/gbm.c +++ b/src/gbm/main/gbm.c @@ -43,7 +43,7 @@ #define ARRAY_SIZE(a) (sizeof(a)/sizeof((a)[0])) -struct gbm_device *devices[16]; +static struct gbm_device *devices[16]; static int device_num = 0; -- 1.9.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: make 'devices' array static
On Mon, Mar 3, 2014 at 17:21:15 +, Emil Velikov wrote: > On 03/03/14 16:41, Julien Cristau wrote: > > It's only used in this one file as far as I can tell, and exporting a > > symbol named 'devices' from a shared library is a recipe for trouble. > Hmm did you really get the 'devices' exported symbol, or did you notice > this while going through the code ? Either way this looks good afaict > The former: $ objdump -T /usr/lib/x86_64-linux-gnu/libgbm.so.1 | grep devices 00206360 gDO .bss 0080 Basedevices > Reviewed-by: Emil Velikov Thanks. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: make 'devices' array static
On Mon, Mar 3, 2014 at 17:29:56 +, Emil Velikov wrote: > On 03/03/14 17:23, Julien Cristau wrote: > > On Mon, Mar 3, 2014 at 17:21:15 +, Emil Velikov wrote: > > > >> On 03/03/14 16:41, Julien Cristau wrote: > >>> It's only used in this one file as far as I can tell, and exporting a > >>> symbol named 'devices' from a shared library is a recipe for trouble. > >> Hmm did you really get the 'devices' exported symbol, or did you notice > >> this while going through the code ? Either way this looks good afaict > >> > > The former: > > $ objdump -T /usr/lib/x86_64-linux-gnu/libgbm.so.1 | grep devices > > 00206360 gDO .bss 0080 Basedevices > > > I'm guessing that this is from 10.1-rcx or earlier. All of the libgbm > exported symbol mayhem is resolved in master. A few other libraries have > been updated as well :-) > Right, I noticed the issue with at least 9.2, 10.0 and 10.1-rc. Good to know it's improved in master. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Finishing make distcheck
On Thu, Dec 11, 2014 at 09:02:11 +, Emil Velikov wrote: > * Don't ship anything but a tar.xz tarball. > Linux, *BSD and WindowsXP+ have/ship programs that support the format > for more than 5 years. > FWIW I'd appreciate if you kept the tar.gz. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Finishing make distcheck
On Mon, Dec 15, 2014 at 10:46:25 +, Emil Velikov wrote: > On 12/12/14 22:41, Julien Cristau wrote: > > On Thu, Dec 11, 2014 at 09:02:11 +, Emil Velikov wrote: > > > >> * Don't ship anything but a tar.xz tarball. > >> Linux, *BSD and WindowsXP+ have/ship programs that support the format > >> for more than 5 years. > >> > > FWIW I'd appreciate if you kept the tar.gz. > > > Can you please share what's the reason behind your request ? > > Planning to send out "let's vote", and Cc a maintainer or two from the > major 4-5 distros. Having some ideas why X or Y is desired/needed is > always a plus. > The traditional debian source package format only does gz, and the newer format comes with other drawbacks that I'd rather avoid. I could always repack, but since I expect the cost of keeping gz to be close to 0, I thought I'd ask. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] mesa: Add a missing error check in _mesa_GetProgramBinary
On Sun, Dec 21, 2014 at 12:08:44 -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87516
> ---
> src/mesa/main/shaderapi.c | 26 --
> 1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index 108e3f5..c7e2633 100644
> --- a/src/mesa/main/shaderapi.c
> +++ b/src/mesa/main/shaderapi.c
> @@ -1681,16 +1681,35 @@ _mesa_GetProgramBinary(GLuint program, GLsizei
> bufSize, GLsizei *length,
> GLenum *binaryFormat, GLvoid *binary)
> {
> struct gl_shader_program *shProg;
> + GLsizei length_dummy;
> GET_CURRENT_CONTEXT(ctx);
>
> shProg = _mesa_lookup_shader_program_err(ctx, program,
> "glGetProgramBinary");
> if (!shProg)
>return;
>
> + /* The ARB_get_program_binary spec says:
> +*
> +* "If is NULL, then no length is returned."
> +*
> +* Ensure that length always points to valid storage to avoid multiple
> NULL
> +* pointer checks below.
> +*/
> + if (length != NULL)
> + *length = &length_dummy;
> +
Is that supposed to read
if (length == NULL)
length = &length_dummy;
?
Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert "configure: ask vdpau.pc for the default location of the vdpau drivers"
On Tue, Sep 30, 2014 at 01:33:08 +0100, Emil Velikov wrote:
> On 29/09/14 17:24, Matt Turner wrote:
> > On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov
> > wrote:
> >> So all in all we have the following:
> >>
> >> Some distributions/people choose odd location of the modules. Which
> >> can lead to the system (vdpau/omx) looking at the wrong place for the
> >> backends, i.e. not working. One can consider that there is no way to
> >> override the module location at runtime.
> >
> > Do we have more specifics? If they're doing something stupid and it
> > breaks, they typically get to keep the pieces.
> >
> > Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
> > ${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
> >
> Hmm I was under the impression that ${libdir} and
> /usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as a
> volunteer for the following, even if the chances of it happening are zero ?
>
${libdir} is /usr/lib/x86_64-linux-gnu.
Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.3.1
On Mon, Oct 13, 2014 at 00:38:25 +0100, Emil Velikov wrote: > Mesa 10.3.1 has been released. Mesa 10.3.1 is a bug fix release > fixing bugs since the 10.3 release, (see below for a list of > changes). > > The tag in the git repository for Mesa 10.3.1 is 'mesa-10.3.1'. > Hi Emil, I'm not seeing that tag on the 10.3 branch. Cheers, Julien signature.asc Description: Digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Statically linking libstdc++ and libgcc
On Thu, Mar 12, 2015 at 16:15:56 +0900, Michel Dänzer wrote: > On 11.03.2015 05:07, Vivek Dasmohapatra wrote: > > Hi - As you probably already know, there can only be one version of > > libstdc++.so in your runtime link chain - This is usually not a problem, > > but when things are linked against the Steam runtime (for example), they > > can end up with two - one from the steam runtime, and one pulled in via > > the mesa dri libs from the OS/distribution. > > How can that happen? The problems I've seen related to this were usually > because Steam overrides the system libstdc++ / libgcc with older > versions, which breaks other system libraries. > > Can somebody please tell Valve that doing that is not okay? And it's not > necessary either. Each library can be compared to the system version > individually and only overridden when necessary, e.g. by putting each > library into its own directory and only adding the necessary directories > to $LD_LIBRARY_PATH. E.g. VMware use this approach in their products. > Yes please. If libstdc++ or libgcc break ABI, that's something the distributions will have to fix anyway, steam or no steam, so I don't see how this helps anyone vs just making steam not override newer libs. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] i965: Convert the build to using automake.
On Thu, Jan 12, 2012 at 20:52:33 -0500, Matt Turner wrote: > On Thu, Jan 12, 2012 at 7:08 PM, Eric Anholt wrote: > > This does introduce a warning by the automake build system, that the > > missing-symbols test build is non-portable. That's true -- Mac OS X > > can't take something built as a loadable module and just link it as a > > library. Of course, we aren't building this on OS X at all, so it > > would be nice to be able to suppress it, but I haven't found a way. > > > > Still, the build is going to be much quieter than we have ever had > > before, so I think this is a fair tradeoff until we find a way to shut > > that warning up. > > --- > > If you want to still put i965_dri.so into the lib/ directory, here's > what I've done for libglsl.so: > > all-local: libglsl.la > if test ! -f "$(top_srcdir)/$(LIB_DIR)/libglsl.so"; then \ > $(MKDIR_P) $(top_srcdir)/$(LIB_DIR); \ > ln .libs/libglsl.so $(top_srcdir)/$(LIB_DIR)/libglsl.so; \ > fi > libglsl.so in srcdir? that sounds like it should be builddir instead. Not that mesa builds out of tree so far, but maybe automake will let us fix that. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly (#52059)
From: Julien Cristau
We were stomping on the caller's buffer by ignoring their alignment
requests. This patch makes the USE_XCB path match the older one more
closely.
Signed-off-by: Julien Cristau
---
src/mapi/glapi/gen/glX_proto_send.py | 36 -
1 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index 9068a61..40cb05d 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -673,16 +673,32 @@ generic_%u_byte( GLint rop, const void * ptr )
if f.needs_reply():
print '%s_reply_t *reply = %s_reply(c,
%s, NULL);' % (xcb_name, xcb_name, xcb_request)
- if output and f.reply_always_array:
- print '(void)memcpy(%s,
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name,
xcb_name, output.get_base_type_string())
-
- elif output and not f.reply_always_array:
- if not output.is_image():
- print 'if
(%s_data_length(reply) == 0)' % (xcb_name)
- print '
(void)memcpy(%s, &reply->datum, sizeof(reply->datum));' % (output.name)
- print 'else'
- print '(void)memcpy(%s,
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name,
xcb_name, output.get_base_type_string())
-
+ if output:
+ if output.is_image():
+ [dim, w, h, d, junk] =
output.get_dimensions()
+ if f.dimensions_in_reply:
+ w = "reply->width"
+ h = "reply->height"
+ d = "reply->depth"
+ if dim < 2:
+ h = "1"
+ else:
+ print '
if (%s == 0) { %s = 1; }' % (h, h)
+ if dim < 3:
+ d = "1"
+ else:
+ print '
if (%s == 0) { %s = 1; }' % (d, d)
+
+ print '
__glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d,
output.img_format, output.img_type, xcb_name, output.name)
+ else:
+ s = output.size() /
output.get_element_count()
+ if f.reply_always_array:
+ print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' %
(output.name, xcb_name, xcb_name, output.get_base_type_string())
+ else:
+ print 'if
(%s_data_length(reply) == 0)' % (xcb_name)
+ print '
(void)memcpy(%s, &reply->datum, sizeof(reply->datum));' % (output.name)
+ print 'else'
+ print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' %
(output.name, xcb_name, xcb_name, output.get_base_type_string())
if f.return_type != 'void':
print 'retval = reply->ret_val;'
--
1.7.2.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glapi/glx: Simplify __glXReadPixelReply
From: Julien Cristau
Doing
size = reply.length * 4;
[...]
extra = 4 - (size & 3);
is useless, size & 3 will always be 0.
Signed-off-by: Julien Cristau
---
src/mapi/glapi/gen/glX_proto_send.py |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index bec0222..9068a61 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -246,12 +246,7 @@ __glXReadPixelReply( Display *dpy, struct glx_context *
gc, unsigned max_dim,
__glXSetError(gc, GL_OUT_OF_MEMORY);
}
else {
-const GLint extra = 4 - (size & 3);
-
_XRead(dpy, buf, size);
-if ( extra < 4 ) {
-_XEatData(dpy, extra);
-}
__glEmptyImage(gc, 3, width, height, depth, format, type,
buf, dest);
--
1.7.2.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly (#52059)
On Thu, Jul 19, 2012 at 09:39:09 -0700, Ian Romanick wrote: > On 07/19/2012 07:46 AM, Julien Cristau wrote: > >From: Julien Cristau > > > >We were stomping on the caller's buffer by ignoring their alignment > >requests. This patch makes the USE_XCB path match the older one more > >closely. > > > >Signed-off-by: Julien Cristau > > Say > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059 > > here instead of mentioning the bug in the subject. > Will do. [...] > >+print ' > >__glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d, > >output.img_format, output.img_type, xcb_name, output.name) > > I was going to comment that 'dim' should be the second parameter to > __glEmptyImage instead of hardcoding 3, but it looks like the dim > parameter isn't used in __glEmptyImage. I think I can recommend a > follow-on patch. :) > Ack. > >+else: > >+s = output.size() / > >output.get_element_count() > > I don't see where this variable is used. > Right, I'll drop it. Thanks! Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/3] glx: Simplify __glXReadPixelReply
From: Julien Cristau
Doing
size = reply.length * 4;
[...]
extra = 4 - (size & 3);
is useless, size & 3 will always be 0.
Signed-off-by: Julien Cristau
---
v2: also change the copy in src/glx/apple
src/glx/apple/glxreply.c |5 -
src/mapi/glapi/gen/glX_proto_send.py |5 -
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/src/glx/apple/glxreply.c b/src/glx/apple/glxreply.c
index f17ebe6..6234e3c 100644
--- a/src/glx/apple/glxreply.c
+++ b/src/glx/apple/glxreply.c
@@ -86,12 +86,7 @@ __glXReadPixelReply(Display * dpy, struct glx_context * gc,
unsigned max_dim,
__glXSetError(gc, GL_OUT_OF_MEMORY);
}
else {
- const GLint extra = 4 - (size & 3);
-
_XRead(dpy, buf, size);
- if (extra < 4) {
-_XEatData(dpy, extra);
- }
__glEmptyImage(gc, 3, width, height, depth, format, type, buf, dest);
Xfree(buf);
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index bec0222..9068a61 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -246,12 +246,7 @@ __glXReadPixelReply( Display *dpy, struct glx_context *
gc, unsigned max_dim,
__glXSetError(gc, GL_OUT_OF_MEMORY);
}
else {
-const GLint extra = 4 - (size & 3);
-
_XRead(dpy, buf, size);
-if ( extra < 4 ) {
-_XEatData(dpy, extra);
-}
__glEmptyImage(gc, 3, width, height, depth, format, type,
buf, dest);
--
1.7.2.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/3] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly
From: Julien Cristau
We were stomping on the caller's buffer by ignoring their alignment
requests and other pixel store modes. This patch makes the USE_XCB path match
the older one more closely.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059
Signed-off-by: Julien Cristau
---
v2: add explicit bugzilla reference to commit message, drop unused
assignment
src/mapi/glapi/gen/glX_proto_send.py | 35 -
1 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index 9068a61..029f8d9 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -673,16 +673,31 @@ generic_%u_byte( GLint rop, const void * ptr )
if f.needs_reply():
print '%s_reply_t *reply = %s_reply(c,
%s, NULL);' % (xcb_name, xcb_name, xcb_request)
- if output and f.reply_always_array:
- print '(void)memcpy(%s,
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name,
xcb_name, output.get_base_type_string())
-
- elif output and not f.reply_always_array:
- if not output.is_image():
- print 'if
(%s_data_length(reply) == 0)' % (xcb_name)
- print '
(void)memcpy(%s, &reply->datum, sizeof(reply->datum));' % (output.name)
- print 'else'
- print '(void)memcpy(%s,
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name,
xcb_name, output.get_base_type_string())
-
+ if output:
+ if output.is_image():
+ [dim, w, h, d, junk] =
output.get_dimensions()
+ if f.dimensions_in_reply:
+ w = "reply->width"
+ h = "reply->height"
+ d = "reply->depth"
+ if dim < 2:
+ h = "1"
+ else:
+ print '
if (%s == 0) { %s = 1; }' % (h, h)
+ if dim < 3:
+ d = "1"
+ else:
+ print '
if (%s == 0) { %s = 1; }' % (d, d)
+
+ print '
__glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d,
output.img_format, output.img_type, xcb_name, output.name)
+ else:
+ if f.reply_always_array:
+ print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' %
(output.name, xcb_name, xcb_name, output.get_base_type_string())
+ else:
+ print 'if
(%s_data_length(reply) == 0)' % (xcb_name)
+ print '
(void)memcpy(%s, &reply->datum, sizeof(reply->datum));' % (output.name)
+ print 'else'
+ print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' %
(output.name, xcb_name, xcb_name, output.get_base_type_string())
if f.return_type != 'void':
print 'retval = reply->ret_val;'
--
1.7.2.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] glx: drop unused 'dim' argument from __glEmptyImage
From: Julien Cristau
Suggested-by: Ian Romanick
Signed-off-by: Julien Cristau
---
src/glx/apple/glxreply.c |2 +-
src/glx/glxclient.h |2 +-
src/glx/pixel.c |2 +-
src/glx/singlepix.c |8
src/mapi/glapi/gen/glX_proto_send.py |4 ++--
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/glx/apple/glxreply.c b/src/glx/apple/glxreply.c
index 6234e3c..db0817b 100644
--- a/src/glx/apple/glxreply.c
+++ b/src/glx/apple/glxreply.c
@@ -88,7 +88,7 @@ __glXReadPixelReply(Display * dpy, struct glx_context * gc,
unsigned max_dim,
else {
_XRead(dpy, buf, size);
- __glEmptyImage(gc, 3, width, height, depth, format, type, buf, dest);
+ __glEmptyImage(gc, width, height, depth, format, type, buf, dest);
Xfree(buf);
}
}
diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
index f8ae450..6d7fc8d 100644
--- a/src/glx/glxclient.h
+++ b/src/glx/glxclient.h
@@ -718,7 +718,7 @@ extern void __glFillMap2d(GLint, GLint, GLint, GLint, GLint,
** Empty an image out of the reply buffer into the clients memory applying
** the pack modes to pack back into the clients requested format.
*/
-extern void __glEmptyImage(struct glx_context *, GLint, GLint, GLint, GLint,
GLenum,
+extern void __glEmptyImage(struct glx_context *, GLint, GLint, GLint, GLenum,
GLenum, const GLubyte *, GLvoid *);
diff --git a/src/glx/pixel.c b/src/glx/pixel.c
index d508d62..15a5ed5 100644
--- a/src/glx/pixel.c
+++ b/src/glx/pixel.c
@@ -388,7 +388,7 @@ EmptyBitmap(struct glx_context * gc, GLint width, GLint
height,
*/
/* ARGSUSED */
void
-__glEmptyImage(struct glx_context * gc, GLint dim, GLint width, GLint height,
+__glEmptyImage(struct glx_context * gc, GLint width, GLint height,
GLint depth, GLenum format, GLenum type,
const GLubyte * sourceImage, GLvoid * userdata)
{
diff --git a/src/glx/singlepix.c b/src/glx/singlepix.c
index d8a7166..4c85cf0 100644
--- a/src/glx/singlepix.c
+++ b/src/glx/singlepix.c
@@ -80,7 +80,7 @@ __indirect_glGetSeparableFilter(GLenum target, GLenum format,
GLenum type,
}
else {
__GLX_SINGLE_GET_CHAR_ARRAY(((char *) rowBuf), widthsize);
- __glEmptyImage(gc, 1, width, 1, 1, format, type, rowBuf, row);
+ __glEmptyImage(gc, width, 1, 1, format, type, rowBuf, row);
Xfree((char *) rowBuf);
}
colBuf = (GLubyte *) Xmalloc(heightsize);
@@ -94,7 +94,7 @@ __indirect_glGetSeparableFilter(GLenum target, GLenum format,
GLenum type,
}
else {
__GLX_SINGLE_GET_CHAR_ARRAY(((char *) colBuf), heightsize);
- __glEmptyImage(gc, 1, height, 1, 1, format, type, colBuf, column);
+ __glEmptyImage(gc, height, 1, 1, format, type, colBuf, column);
Xfree((char *) colBuf);
}
}
@@ -174,7 +174,7 @@ void gl_dispatch_stub_GetSeparableFilterEXT (GLenum target,
GLenum format,
_XEatData(dpy, extra);
}
- __glEmptyImage(gc, 1, width, 1, 1, format, type, buf, row);
+ __glEmptyImage(gc, width, 1, 1, format, type, buf, row);
extra = 4 - (heightsize & 3);
_XRead(dpy, (char *) buf, heightsize);
@@ -182,7 +182,7 @@ void gl_dispatch_stub_GetSeparableFilterEXT (GLenum target,
GLenum format,
_XEatData(dpy, extra);
}
- __glEmptyImage(gc, 1, height, 1, 1, format, type, buf, column);
+ __glEmptyImage(gc, height, 1, 1, format, type, buf, column);
Xfree((char *) buf);
}
diff --git a/src/mapi/glapi/gen/glX_proto_send.py
b/src/mapi/glapi/gen/glX_proto_send.py
index 029f8d9..acf603a 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -248,7 +248,7 @@ __glXReadPixelReply( Display *dpy, struct glx_context * gc,
unsigned max_dim,
else {
_XRead(dpy, buf, size);
-__glEmptyImage(gc, 3, width, height, depth, format, type,
+__glEmptyImage(gc, width, height, depth, format, type,
buf, dest);
Xfree(buf);
}
@@ -689,7 +689,7 @@ generic_%u_byte( GLint rop, const void * ptr )
else:
print '
if (%s == 0) { %s = 1; }' % (d, d)
- print '
__glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d,
output.img_format, output.img_type, xcb_name, output.name)
+ print '
__glEmptyImage(gc, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d,
output.img_format, output.img_type, xcb_name, output.name)
Re: [Mesa-dev] [PATCH v2 2/3] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly
On Fri, Jul 20, 2012 at 11:09:19 +0200, Julien Cristau wrote: > From: Julien Cristau > > We were stomping on the caller's buffer by ignoring their alignment > requests and other pixel store modes. This patch makes the USE_XCB path match > the older one more closely. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059 > > Signed-off-by: Julien Cristau > --- > v2: add explicit bugzilla reference to commit message, drop unused > assignment > > src/mapi/glapi/gen/glX_proto_send.py | 35 - > 1 files changed, 25 insertions(+), 10 deletions(-) > Ping? Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/3] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly
On Sat, Jul 28, 2012 at 13:04:56 +0200, Julien Cristau wrote: > On Fri, Jul 20, 2012 at 11:09:19 +0200, Julien Cristau wrote: > > > From: Julien Cristau > > > > We were stomping on the caller's buffer by ignoring their alignment > > requests and other pixel store modes. This patch makes the USE_XCB path > > match > > the older one more closely. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059 > > > > Signed-off-by: Julien Cristau > > --- > > v2: add explicit bugzilla reference to commit message, drop unused > > assignment > > > > src/mapi/glapi/gen/glX_proto_send.py | 35 > > - > > 1 files changed, 25 insertions(+), 10 deletions(-) > > > Ping? > Ping? Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Shrining mesa binaries.
On Fri, Aug 24, 2012 at 14:45:44 -0400, nerdopolis wrote: > Hi. > > I hope this is the correct place for this. > > I make a Wayland live cd, and in order for Wayland to work, I need to build > mesa with Wayland support. > > I get Mesa to build just fine it's just that I notice that the binaries in > /egl /dri and /gbm are MUCH larger then the ones provided by the distro, and > it's taking up a good amount of space on the LiveCD. > > for instance: > The egl_gallium that gets built is 20mb while the one in the distro is 6MB > The dri folder that gets built is 87mb while the distro is 15MB > The gbm folder that gets built is 55mb while the distro is 5mb > > What do I need to do to shrink these binaries, and to get it to work on the > most possible machines? I notice --enable-shared-dricore that I read about > appears to be gone, and I tried using the strip command on the binaries. > Strip them? Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Upcoming Mesa releases
On Thu, Aug 9, 2012 at 19:01:55 -0700, Ian Romanick wrote: > 8/17: Release Mesa 8.0.5. I'll send out another pick-list on Friday > or Saturday, and pick things over on Monday or Tuesday. > Hi Ian, is there an updated plan for 8.0.5? Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] configure.ac: refuse to build r300g without LLVM
On Sat, Apr 23, 2011 at 10:48:49 +0200, Marek Olšák wrote: > On Fri, Apr 22, 2011 at 1:29 PM, Jose Fonseca wrote: > > > The Mesa state tracker uses SWTNL for GL selection/feedback regardless of > > the driver. Some SPECviewperf viewsets and CAD apps use it. So using LLVM > > speeds up selection/feedback for all gallium drivers. > > > > We have only tested LLVM with x86/x86_64. So indeed, using it/requiring it > > on other platforms is not advisable. > > > > I take the first patch back. Here's an updated r300g patch that requires > LLVM on x86 and x86_64 only: > > > configure.ac: require LLVM to build r300g on x86 and x86_64 > > diff --git a/configure.ac b/configure.ac > index d8c50ce..1012ca5 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1780,9 +1780,16 @@ dnl Gallium Radeon r300g configuration > dnl > AC_ARG_ENABLE([gallium-r300], > [AS_HELP_STRING([--enable-gallium-r300], > -[build gallium r300 @<:@default=DRI-only@:>@])], > +[build gallium r300 @<:@default=build DRI driver only@:>@])], > [enable_gallium_r300="$enableval"], > [enable_gallium_r300=auto]) > +if test "x$enable_gallium_r300" != xno; then > +if test "x$MESA_LLVM" = x0; then > +case "$host_cpu" in > +i*86|x86_64) AC_MSG_ERROR([LLVM is required to build Gallium R300 > on x86 and x86_64]);; > +esac > +fi > +fi > if test "x$enable_gallium_r300" = xauto; then > GALLIUM_DRIVERS_DIRS="$GALLIUM_DRIVERS_DIRS r300" > gallium_check_st "radeon/drm" "dri-r300" > > AIUI it's not really required, it'll just be slow if built without llvm? How much of that is specific to r300 as opposed to other gallium drivers? Shouldn't this be a warning instead of an error? Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] Add Alpha to the little-endian machines.
On Fri, May 6, 2011 at 13:01:14 -0400, Matt Turner wrote: > From: Jay Estabrook > > Reviewed-by: Matt Turner > Signed-off-by: Jay Estabrook > --- > src/gallium/include/pipe/p_config.h |6 +- > 1 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/src/gallium/include/pipe/p_config.h > b/src/gallium/include/pipe/p_config.h > index 74a1fa2..9e8ff6a 100644 > --- a/src/gallium/include/pipe/p_config.h > +++ b/src/gallium/include/pipe/p_config.h > @@ -99,6 +99,10 @@ > #endif > #endif > > +#if defined(__alpha__) > +#define PIPE_ARCH_ALPHA > +#endif > + > #if defined(__PPC__) > #define PIPE_ARCH_PPC > #if defined(__PPC64__) > @@ -111,7 +115,7 @@ > * Endian detection. > */ > > -#if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) > +#if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) || > defined(PIPE_ARCH_ALPHA) > #define PIPE_ARCH_LITTLE_ENDIAN > #elif defined(PIPE_ARCH_PPC) || defined(PIPE_ARCH_PPC_64) > #define PIPE_ARCH_BIG_ENDIAN Is there any particular reason this can't do the following, at least on glibc platforms? #include #if __BYTE_ORDER == __LITTLE_ENDIAN # define PIPE_ARCH_LITTLE_ENDIAN #elif __BYTE_ORDER == __BIG_ENDIAN # define PIPE_ARCH_BIG_ENDIAN #endif Instead of having an always incomplete hardcoded list as "detection"... Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] Don't allow compilation if endianness isn't known
On Fri, May 6, 2011 at 13:01:15 -0400, Matt Turner wrote: > Signed-off-by: Matt Turner > --- > > PIPE_ARCH_UNKNOWN_ENDIAN is used no where else. All #else branches of > #ifdef PIPE_ARCH_LITTLE assume big-endian. Not #error'ing out here > only serves to allow bad things to happen. > I think this text should be part of the commit message. Patch looks like a good idea to me, fwiw. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/10] intel: Request DRI2 buffers for separate stencil and hiz
On Mon, Jun 6, 2011 at 18:56:20 -0700, Kenneth Graunke wrote: > I'd make this an assertion. must_use_separate_stencil is only set for > gen >= 7, and I assert that try_separate_stencil ought to be true in > that case (old DDX doesn't support IVB, new DDX requires new dri2proto > to compile). > > Only unreleased git-snapshots of the DDX should hit this (and only on > unreleased hardware), so hitting an assertion seems like a friendly way > to say "hey, update your DDX". > There's nothing friendly about hitting an assertion, so if there's another option then please avoid assert... Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx/dri2: Paper over errors in DRI2Connect when indirect
On Thu, Jun 9, 2011 at 18:57:54 +1000, Christopher James Halse Rogers wrote:
> DRI2 will throw BadRequest for this when the client is not local, but
> DRI2 is an implementation detail and not something callers should have
> to know about. Silently swallow errors in this case, and just propagate
> the failure through DRI2Connect's return code.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28125
> Signed-off-by: Christopher James Halse Rogers
>
> ---
>
> This seems to have died a quiet death without actually getting applied.
> Kristian, was this what you had in mind?
>
> src/glx/dri2.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/src/glx/dri2.c b/src/glx/dri2.c
> index adfd3d1..00adff2 100644
> --- a/src/glx/dri2.c
> +++ b/src/glx/dri2.c
> @@ -180,6 +180,15 @@ DRI2Error(Display *display, xError *err, XExtCodes
> *codes, int *ret_code)
> err->minorCode == X_DRI2DestroyDrawable)
> return True;
>
> +/* If the server is non-local DRI2Connect will raise BadRequest.
> + * Swallow this so that DRI2Connect can signal this in its return code */
> +if (err->majorCode == codes->major_opcode &&
> +err->minorCode == X_DRI2Connect &&
> +err->errorCode == BadRequest) {
> + *ret_code = False;
> + return True;
> +}
> +
> return False;
> }
>
I tested something like this (without setting *ret_code though, so my
patch was probably wrong), seemed to work just fine.
Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Xlib GL needs -ltalloc
On Fri, Aug 27, 2010 at 15:24:45 +0100, Jon TURNEY wrote: > diff --git a/src/mesa/drivers/osmesa/Makefile > b/src/mesa/drivers/osmesa/Makefile > index 091e6f6..fb70790 100644 > --- a/src/mesa/drivers/osmesa/Makefile > +++ b/src/mesa/drivers/osmesa/Makefile > @@ -38,7 +38,7 @@ default: $(TOP)/$(LIB_DIR)/$(OSMESA_LIB_NAME) > $(TOP)/$(LIB_DIR)/$(OSMESA_LIB_NAME): $(OBJECTS) $(CORE_MESA) > $(MKLIB) -o $(OSMESA_LIB) -linker '$(CC)' -ldflags '$(LDFLAGS)' \ -linker '$(CXX)'? > -major $(MESA_MAJOR) -minor $(MESA_MINOR) -patch $(MESA_TINY) \ > - -install $(TOP)/$(LIB_DIR) $(MKLIB_OPTIONS) \ > + -install $(TOP)/$(LIB_DIR) -cplusplus $(MKLIB_OPTIONS) \ > -id $(INSTALL_LIB_DIR)/lib$(OSMESA_LIB).$(MESA_MAJOR).dylib \ > $(OSMESA_LIB_DEPS) $(OBJECTS) $(CORE_MESA) > Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cflags mess with llvm builds
On Fri, Sep 24, 2010 at 14:06:51 +0200, Xavier Chantry wrote: > When gallium llvm is enabled, configure.ac does the following : > LLVM_CFLAGS=`$LLVM_CONFIG --cflags` > > This is the result on my system : > -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC > I'd argue that that's a bug in llvm-config, it has no business telling you what optimisation level to use, or defining random macros. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Disappearing patches
On Tue, Oct 19, 2010 at 13:31:35 +0200, Thomas Hellstrom wrote: > Hi! > > I've been trying to send a patch to mesa-dev a couple of times using > git send-email, but the message never makes it to the list. Am I the > only one having trouble with this? > It did make it to the list, both times, as far as I can tell. http://lists.freedesktop.org/pipermail/mesa-dev/2010-October/003575.html http://lists.freedesktop.org/pipermail/mesa-dev/2010-October/003619.html Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Disappearing patches
On Tue, Oct 19, 2010 at 14:15:44 +0200, Thomas Hellstrom wrote: > On 10/19/2010 01:55 PM, Julien Cristau wrote: > >On Tue, Oct 19, 2010 at 13:31:35 +0200, Thomas Hellstrom wrote: > > > >>Hi! > >> > >>I've been trying to send a patch to mesa-dev a couple of times using > >>git send-email, but the message never makes it to the list. Am I the > >>only one having trouble with this? > >> > >It did make it to the list, both times, as far as I can tell. > >http://lists.freedesktop.org/pipermail/mesa-dev/2010-October/003575.html > >http://lists.freedesktop.org/pipermail/mesa-dev/2010-October/003619.html > > > >Cheers, > >Julien > Hmm, Thanks, > > You're obviously right. I wonder whether it might be the VMware spam > filter automatically > classifying my patches as crap when the list sends them back... > It could be mailman deciding that since you're the sender you don't want them through the list? IIRC there's an option for that in the subscription preferences. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Makefile: don't include the same files twice in the tarball
src/mesa/drivers/dri/*/*/*.[chS] is a superset of src/mesa/drivers/dri/*/server/*.[ch] and src/mesa/drivers/dri/common/xmlpool/*.[ch]. include/GL/internal/glcore.h is already in MAIN_FILES, no need for it in DRI_FILES too. src/glx/Makefile was listed twice. Signed-off-by: Julien Cristau --- This patch is against 7.9, I haven't checked if master needs it too. See http://lists.debian.org/debian-x/2010/11/msg00556.html and http://lists.debian.org/debian-x/2010/11/msg00562.html for the rationale. Makefile |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index b8069f9..b13ed33 100644 --- a/Makefile +++ b/Makefile @@ -347,23 +347,19 @@ GALLIUM_FILES = \ DRI_FILES = \ $(DIRECTORY)/include/GL/internal/dri_interface.h\ - $(DIRECTORY)/include/GL/internal/glcore.h \ $(DIRECTORY)/include/GL/internal/sarea.h\ $(DIRECTORY)/src/glx/Makefile \ - $(DIRECTORY)/src/glx/Makefile \ $(DIRECTORY)/src/glx/*.[ch] \ $(DIRECTORY)/src/mesa/drivers/dri/Makefile \ $(DIRECTORY)/src/mesa/drivers/dri/Makefile.template \ $(DIRECTORY)/src/mesa/drivers/dri/dri.pc.in \ - $(DIRECTORY)/src/mesa/drivers/dri/common/xmlpool/*.[ch] \ $(DIRECTORY)/src/mesa/drivers/dri/common/xmlpool/*.po \ $(DIRECTORY)/src/mesa/drivers/dri/*/*.[chS] \ $(DIRECTORY)/src/mesa/drivers/dri/*/*.cpp \ $(DIRECTORY)/src/mesa/drivers/dri/*/*/*.[chS] \ $(DIRECTORY)/src/mesa/drivers/dri/*/Makefile\ $(DIRECTORY)/src/mesa/drivers/dri/*/*/Makefile \ - $(DIRECTORY)/src/mesa/drivers/dri/*/Doxyfile\ - $(DIRECTORY)/src/mesa/drivers/dri/*/server/*.[ch] + $(DIRECTORY)/src/mesa/drivers/dri/*/Doxyfile SGI_GLU_FILES = \ $(DIRECTORY)/src/glu/Makefile \ -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Export TLS support in gl.pc
On Sun, Dec 5, 2010 at 20:47:01 -0800, Eric Anholt wrote: > What is this patch for? According to the second mail quoted, a TLS > loader works for both TLS and non-TLS drivers -- that is to say, the X > Server's loader should always default to having TLS support, regardless > of whether the (probably not yet built) drivers are built for it. I've been meaning to do that... Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH:mesa-demos] Allow builders to specify GLEW_CFLAGS & GLEW_LIBS
On Thu, Dec 30, 2010 at 10:27:14 -0700, tom fogal wrote:
> Isn't this going to mean that GLEW's w/o the .pc file cannot be used?
I don't think so. If the .pc isn't found and you didn't pass
GLEW_{CFLAGS,LIBS}, it'll look for GL/glew.h and -lGLEW directly.
Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] osmesa: static linking of talloc
On Sun, Oct 24, 2010 at 13:23:28 +0200, Tormod Volden wrote: > Commit 5a3ac74 added $(TALLOC_LIBS) to the mklib call in > src/mesa/drivers/osmesa/Makefile and this breaks static builds on > Linux since ar barfs on "-ltalloc". I have been looking at different > ways of dealing with this without finding any elegant solution. We can > change configure.ac to set TALLOC_LIBS to libtalloc.a for static > builds, but ar needs the full path and something like this does not > look pretty in there: > TALLOC_LIBS="`$PKG_CONFIG --variable=libdir talloc`/libtalloc.a" > > Alternatively, I have a mklib hack to translate -lfoo into libfoo.a > (searched for in different paths, also ugly) for static builds. I > wonder if libtool can do this in a clever way instead, but I don't > know libtool well enough. > > Finally, maybe reverting 5a3ac74 is better. For shared libs, > TALLOC_LIBS is already added to OSLIB_MESA_DEPS in configure.ac. For > static builds, configure.ac explicitly says to not link libraries > "only link libraries with osmesa if shared". So this is in > contradiction to 5a3ac74 AFAICS. But I am probably missing something, > especially outside my own use case. > Revert sounds correct to me if we already get -ltalloc from OSLIB_MESA_DEPS for the shared build. The static build doesn't need it. Cc:ing ajax and Orion. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.10 release
On Sat, Jan 8, 2011 at 17:00:54 +0100, Sebastian H. wrote: > make then stopped like this > > 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/include/libdrm-g -O2 > -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden > -fno-strict-aliasing -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS > -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS > -DFEATURE_GL=1 -I../intel -DI915 -DDRM_VBLANK_FLIP=DRM_VBLANK_FLIP > intel_batchbuffer.c -o intel_batchbuffer.o > intel_batchbuffer.c: In function ‘do_flush_locked’: > intel_batchbuffer.c:101: error: ‘I915_EXEC_BLT’ undeclared (first use in > this function) > intel_batchbuffer.c:101: error: (Each undeclared identifier is reported > only once > intel_batchbuffer.c:101: error: for each function it appears in.) You need a newer libdrm. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: fix request lengths
We were sending too long requests for GLXChangeDrawableAttributes,
GLXGetDrawableAttributes, GLXDestroyPixmap and GLXDestroyWindow.
Signed-off-by: Julien Cristau
---
src/glx/glx_pbuffer.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 34892e8..1de3e74 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -106,7 +106,7 @@ ChangeDrawableAttribute(Display * dpy, GLXDrawable drawable,
if ((priv->majorVersion > 1) || (priv->minorVersion >= 3)) {
xGLXChangeDrawableAttributesReq *req;
- GetReqExtra(GLXChangeDrawableAttributes, 8 + (8 * num_attribs), req);
+ GetReqExtra(GLXChangeDrawableAttributes, 8 * num_attribs, req);
output = (CARD32 *) (req + 1);
req->reqType = opcode;
@@ -297,7 +297,7 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
if (use_glx_1_3) {
xGLXGetDrawableAttributesReq *req;
- GetReqExtra(GLXGetDrawableAttributes, 4, req);
+ GetReq(GLXGetDrawableAttributes, req);
req->reqType = opcode;
req->glxCode = X_GLXGetDrawableAttributes;
req->drawable = drawable;
@@ -435,7 +435,7 @@ DestroyDrawable(Display * dpy, GLXDrawable drawable, CARD32
glxCode)
LockDisplay(dpy);
- GetReqExtra(GLXDestroyPbuffer, 4, req);
+ GetReq(GLXDestroyPbuffer, req);
req->reqType = opcode;
req->glxCode = glxCode;
req->pbuffer = (GLXPbuffer) drawable;
--
1.7.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glx: fix GLXChangeDrawableAttributesSGIX request
xGLXChangeDrawableAttributesSGIXReq follows the GLXVendorPrivate header
with a drawable, number of attributes, and list of (type, value)
attribute pairs. Don't forget to put the number of attributes in there.
I don't think this can ever have worked.
Signed-off-by: Julien Cristau
---
src/glx/glx_pbuffer.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 34892e8..6fc8433 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -117,7 +117,7 @@ ChangeDrawableAttribute(Display * dpy, GLXDrawable drawable,
else {
xGLXVendorPrivateWithReplyReq *vpreq;
- GetReqExtra(GLXVendorPrivateWithReply, 4 + (8 * num_attribs), vpreq);
+ GetReqExtra(GLXVendorPrivateWithReply, 8 + (8 * num_attribs), vpreq);
output = (CARD32 *) (vpreq + 1);
vpreq->reqType = opcode;
@@ -125,7 +125,8 @@ ChangeDrawableAttribute(Display * dpy, GLXDrawable drawable,
vpreq->vendorCode = X_GLXvop_ChangeDrawableAttributesSGIX;
output[0] = (CARD32) drawable;
- output++;
+ output[1] = num_attribs;
+ output += 2;
}
(void) memcpy(output, attribs, sizeof(CARD32) * 2 * num_attribs);
--
1.7.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glx: fix length of GLXGetFBConfigsSGIX
The extra length is the size of the request *minus* the size of the
VendorPrivate header, not the addition.
Signed-off-by: Julien Cristau
---
src/glx/glxext.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glx/glxext.c b/src/glx/glxext.c
index c5e9d05..c75c9bf 100644
--- a/src/glx/glxext.c
+++ b/src/glx/glxext.c
@@ -688,7 +688,7 @@ static GLboolean
}
else if (strstr(psc->serverGLXexts, "GLX_SGIX_fbconfig") != NULL) {
GetReqExtra(GLXVendorPrivateWithReply,
- sz_xGLXGetFBConfigsSGIXReq +
+ sz_xGLXGetFBConfigsSGIXReq -
sz_xGLXVendorPrivateWithReplyReq, vpreq);
sgi_req = (xGLXGetFBConfigsSGIXReq *) vpreq;
sgi_req->reqType = priv->majorOpcode;
--
1.7.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.
On Sun, Jan 30, 2011 at 00:00:48 +0100, Henri Verbeet wrote: > @@ -918,12 +921,15 @@ dri2CreateScreen(int screen, struct glx_display * priv) > return &psc->base; > > handle_error: > + if (psc->fd) > + close(psc->fd); 0 is a valid fd. It might be better to initialize fd to -1 and check for >= 0 here. > + if (psc->driver) > + dlclose(psc->driver); > Xfree(driverName); > Xfree(deviceName); > + glx_screen_cleanup(&psc->base); > XFree(psc); > > - /* FIXME: clean up here */ > - > return NULL; > } > Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.
On Mon, Jan 31, 2011 at 18:18:22 +0100, Henri Verbeet wrote: > The attached patch should do. Looks good to me, thanks. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] Only require libdrm if direct rendering is actually enabled
On Wed, Feb 16, 2011 at 15:11:34 +, Jon TURNEY wrote: > At the moment, libGL cannot be built --with-driver=dri --disable-driglx-direct > on platforms which don't have libdrm. > > --with-driver=dri is the only way to build a libGL which supports indirect > rendering. > > This patch set makes libdrm only required if --enable-driglx-direct is used, > and makes --disable-driglx-direct the default on cygwin and hurd. > > (this patch set combines patches from fd.o bugs #27840 and #29460, updated for > the current git master) > > Jon TURNEY (1): > Disable direct rendering on Cygwin > > Samuel Thibault (1): > Only require libdrm if direct rendering is actually enabled. > > nobled (1): > Disable direct rendering on GNU/Hurd > For the series: Reviewed-by: Julien Cristau Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Bug 28280] Regression in mesa branches 7.7/7.8: glXChooseVisual fails to find visual
On Sat, May 29, 2010 at 06:13:11 -0700, bugzilla-dae...@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=28280 > > --- Comment #3 from Matthias Liertzer 2010-05-29 06:13:11 > PDT --- > Created an attachment (id=35934) > View: https://bugs.freedesktop.org/attachment.cgi?id=35934 > Review: https://bugs.freedesktop.org/review?bug=28280&attachment=35934 > > Patch backported from master branch > Can somebody please apply this regression fix to the 7.7 and 7.8 branches? 26a9b7e4c737c89b47844303bb7413ceab0280a5 can probably be cherry-picked as-is to 7.8, but 7.7 has different paths so needs the above backport. Thanks, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] dri loader ABI change between mesa 7.7 and 7.8
Hi, it seems that the dri loader ABI changed between mesa 7.7 and 7.8. Drivers from 7.7 reference a _glapi_set_warning_func symbol which doesn't seem to be exported by the 7.8 libGL, so the new libGL can't load the old drivers. Was this change intentional? What is the intended stability of that interface? Thanks, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] dri loader ABI change between mesa 7.7 and 7.8
On Mon, Jun 21, 2010 at 17:23:25 -0600, Brian Paul wrote: > Julien Cristau wrote: > >Hi, > > > >it seems that the dri loader ABI changed between mesa 7.7 and 7.8. > >Drivers from 7.7 reference a _glapi_set_warning_func symbol which > >doesn't seem to be exported by the 7.8 libGL, so the new libGL can't > >load the old drivers. Was this change intentional? What is the > >intended stability of that interface? > > This was fixed with commit f1381880a8e0e0cdd96c4c725ff35a28b250b09d > and should be in Mesa 7.8.2 > Ah, thanks, I should have checked. Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Bug#585618: [PATCH 2/6] pipe: Add PIPE_OS_HURD
On Thu, Jun 24, 2010 at 01:08:03 -0700, Corbin Simpson wrote: > On Wed, Jun 23, 2010 at 6:31 PM, nobled wrote: > > One tiny step toward porting Gallium to the GNU/Hurd kernel > > (and fixing Debian bug #585618). > > --- > > src/gallium/include/pipe/p_config.h | 5 + > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > diff --git a/src/gallium/include/pipe/p_config.h > > b/src/gallium/include/pipe/p_config.h > > index 68025fa..b077933 100644 > > --- a/src/gallium/include/pipe/p_config.h > > +++ b/src/gallium/include/pipe/p_config.h > > @@ -146,6 +146,11 @@ > > #define PIPE_OS_UNIX > > #endif > > > > +#if defined(__GNU__) > > +#define PIPE_OS_HURD > > +#define PIPE_OS_UNIX > > +#endif > > + > > #if defined(__sun) > > #define PIPE_OS_SOLARIS > > #define PIPE_OS_UNIX > > -- > > 1.5.4.3 > > This is only defined on HURD, right? It's not part of the GCC-specific > defines? > Correct. Cheers, Julien signature.asc Description: Digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix kFreeBSD build
On Sun, Jul 18, 2010 at 08:59:23 -0700, Corbin Simpson wrote: > I didn't ack the earlier version of the patch because it had no testers. Has > this been tested? > It's been used in debian's mesa packages since April 2009. So Acked-by: Julien Cristau Cheers, Julien ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Bug#585618: [PATCH 1/6] pipe: Detect FreeBSD better
On Thu, Jun 24, 2010 at 01:07:17 -0700, Corbin Simpson wrote:
> On Wed, Jun 23, 2010 at 6:31 PM, nobled wrote:
> > Taking advice from the Debian BSD porting guide:
> > http://glibc-bsd.alioth.debian.org/porting/PORTING
> >
> > This should help fix Debian bug #585618 (gallium build failure).
> > ---
> > src/gallium/include/pipe/p_config.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> > diff --git a/src/gallium/include/pipe/p_config.h
> > b/src/gallium/include/pipe/p_config.h
> > index b81702a..68025fa 100644
> > --- a/src/gallium/include/pipe/p_config.h
> > +++ b/src/gallium/include/pipe/p_config.h
> > @@ -128,7 +128,7 @@
> > #define PIPE_OS_UNIX
> > #endif
> >
> > -#if defined(__FreeBSD__)
> > +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
> > #define PIPE_OS_FREEBSD
> > #define PIPE_OS_BSD
> > #define PIPE_OS_UNIX
> > --
> > 1.5.4.3
>
> Looks reasonable; does this actually work for you? I'd like somebody
> to test first.
>
I verified that this builds on a kfreebsd system on top of 7.8.2, and
looking at the differences between PIPE_OS_LINUX and PIPE_OS_{,FREE}BSD
in the code this seems reasonable, so
Reviewed-by: Julien Cristau
Maybe also consider:
diff --git a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
index 65d5ce7..bd84532 100644
--- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
+++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
@@ -37,7 +37,7 @@
#include "rtasm_execmem.h"
-#if defined(PIPE_OS_BSD)
+#ifndef MAP_ANONYMOUS
#define MAP_ANONYMOUS MAP_ANON
#endif
(the kfreebsd glibc headers define MAP_ANONYMOUS to MAP_ANON already, so
this one shouldn't be strictly necessary)
Cheers,
Julien
signature.asc
Description: Digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
