[Mesa-dev] [PATCH 2/3] init ps-context with util_surfaces_get and do_get
Pass pipe_context rather than pipe_screen to util_surfaces_get and
util_surfaces_do_get so that they can check whether the saved pipe_surface
have the current context, and init properly a new pipe_surface with the
current context.
pipe_context is also passed to pipe_surface_reset and pipe_surface_init so
that context initialization is done in one central place.
---
src/gallium/auxiliary/util/u_inlines.h | 13 -
src/gallium/auxiliary/util/u_surfaces.c |6 +++---
src/gallium/auxiliary/util/u_surfaces.h |8
src/gallium/drivers/nvfx/nvfx_miptree.c |3 +--
4 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_inlines.h
b/src/gallium/auxiliary/util/u_inlines.h
index d5bc114..e55aafe 100644
--- a/src/gallium/auxiliary/util/u_inlines.h
+++ b/src/gallium/auxiliary/util/u_inlines.h
@@ -136,8 +136,9 @@ pipe_sampler_view_reference(struct pipe_sampler_view **ptr,
struct pipe_sampler_
}
static INLINE void
-pipe_surface_reset(struct pipe_surface* ps, struct pipe_resource *pt,
- unsigned level, unsigned layer, unsigned flags)
+pipe_surface_reset(struct pipe_context *ctx, struct pipe_surface* ps,
+ struct pipe_resource *pt, unsigned level, unsigned layer,
+ unsigned flags)
{
pipe_resource_reference(ps-texture, pt);
ps-format = pt-format;
@@ -146,15 +147,17 @@ pipe_surface_reset(struct pipe_surface* ps, struct
pipe_resource *pt,
ps-usage = flags;
ps-u.tex.level = level;
ps-u.tex.first_layer = ps-u.tex.last_layer = layer;
+ ps-context = ctx;
}
static INLINE void
-pipe_surface_init(struct pipe_surface* ps, struct pipe_resource *pt,
- unsigned level, unsigned layer, unsigned flags)
+pipe_surface_init(struct pipe_context *ctx, struct pipe_surface* ps,
+ struct pipe_resource *pt, unsigned level, unsigned layer,
+ unsigned flags)
{
ps-texture = 0;
pipe_reference_init(ps-reference, 1);
- pipe_surface_reset(ps, pt, level, layer, flags);
+ pipe_surface_reset(ctx, ps, pt, level, layer, flags);
}
/*
diff --git a/src/gallium/auxiliary/util/u_surfaces.c
b/src/gallium/auxiliary/util/u_surfaces.c
index fd55bd1..b0cfec2 100644
--- a/src/gallium/auxiliary/util/u_surfaces.c
+++ b/src/gallium/auxiliary/util/u_surfaces.c
@@ -31,7 +31,7 @@
boolean
util_surfaces_do_get(struct util_surfaces *us, unsigned surface_struct_size,
- struct pipe_screen *pscreen, struct pipe_resource *pt,
+ struct pipe_context *ctx, struct pipe_resource *pt,
unsigned level, unsigned layer, unsigned flags,
struct pipe_surface **res)
{
@@ -51,7 +51,7 @@ util_surfaces_do_get(struct util_surfaces *us, unsigned
surface_struct_size,
ps = us-u.array[level];
}
- if(ps)
+ if(ps ps-context == ctx)
{
p_atomic_inc(ps-reference.count);
*res = ps;
@@ -65,7 +65,7 @@ util_surfaces_do_get(struct util_surfaces *us, unsigned
surface_struct_size,
return FALSE;
}
- pipe_surface_init(ps, pt, level, layer, flags);
+ pipe_surface_init(ctx, ps, pt, level, layer, flags);
if(pt-target == PIPE_TEXTURE_3D || pt-target == PIPE_TEXTURE_CUBE)
cso_hash_insert(us-u.hash, (layer 8) | level, ps);
diff --git a/src/gallium/auxiliary/util/u_surfaces.h
b/src/gallium/auxiliary/util/u_surfaces.h
index da4fbbf..9581fed 100644
--- a/src/gallium/auxiliary/util/u_surfaces.h
+++ b/src/gallium/auxiliary/util/u_surfaces.h
@@ -45,21 +45,21 @@ struct util_surfaces
/* Return value indicates if the pipe surface result is new */
boolean
util_surfaces_do_get(struct util_surfaces *us, unsigned surface_struct_size,
- struct pipe_screen *pscreen, struct pipe_resource *pt,
+ struct pipe_context *ctx, struct pipe_resource *pt,
unsigned level, unsigned layer, unsigned flags,
struct pipe_surface **res);
/* fast inline path for the very common case */
static INLINE boolean
util_surfaces_get(struct util_surfaces *us, unsigned surface_struct_size,
- struct pipe_screen *pscreen, struct pipe_resource *pt,
+ struct pipe_context *ctx, struct pipe_resource *pt,
unsigned level, unsigned layer, unsigned flags,
struct pipe_surface **res)
{
if(likely((pt-target == PIPE_TEXTURE_2D || pt-target ==
PIPE_TEXTURE_RECT) us-u.array))
{
struct pipe_surface *ps = us-u.array[level];
- if(ps)
+ if(ps ps-context == ctx)
{
p_atomic_inc(ps-reference.count);
*res = ps;
@@ -67,7 +67,7 @@ util_surfaces_get(struct util_surfaces *us, unsigned
surface_struct_size,
}
}
- return util_surfaces_do_get(us, surface_struct_size, pscreen, pt, level,
layer, flags, res);
+ return util_surfaces_do_get(us, surface_struct_size, ctx, pt, level, layer,
[Mesa-dev] [PATCH 3/3] gallium/trace: check bind_vertex_sampler_states and set_vertex_sampler_views
cso_cache_delete checks if pipe has bind_vertex_sampler_states and
set_vertex_sampler_views so do the same in tr_context.
This avoids a segfault when tracing nvfx driver on piglit
glx-destroycontext-2
---
src/gallium/drivers/trace/tr_context.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/trace/tr_context.c
b/src/gallium/drivers/trace/tr_context.c
index 2fdb6c9..eaabae8 100644
--- a/src/gallium/drivers/trace/tr_context.c
+++ b/src/gallium/drivers/trace/tr_context.c
@@ -314,6 +314,9 @@ trace_context_bind_vertex_sampler_states(struct
pipe_context *_pipe,
struct trace_context *tr_ctx = trace_context(_pipe);
struct pipe_context *pipe = tr_ctx-pipe;
+ if (!pipe-bind_vertex_sampler_states)
+ return;
+
trace_dump_call_begin(pipe_context, bind_vertex_sampler_states);
trace_dump_arg(ptr, pipe);
@@ -980,6 +983,9 @@ trace_context_set_vertex_sampler_views(struct pipe_context
*_pipe,
struct pipe_sampler_view *unwrapped_views[PIPE_MAX_VERTEX_SAMPLERS];
unsigned i;
+ if (!pipe-set_vertex_sampler_views)
+ return;
+
for(i = 0; i num; ++i) {
tr_view = trace_sampler_view(views[i]);
unwrapped_views[i] = tr_view ? tr_view-sampler_view : NULL;
--
1.7.3.2
___
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 11:36 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Fri, Sep 24, 2010 at 3:15 PM, Luca Barbieri l...@luca-barbieri.com wrote: Yes, that used to happen for me too. Just edit llvm-config to remove the offending text and ideally file a bug on the LLVM bug tracker. looks like nobled did this for me : http://llvm.org/bugs/show_bug.cgi?id=8220 thanks :) The first answer is very negative and reports the bug as invalid. http://llvm.org/bugs/show_bug.cgi?id=8220#c1 The only suggestion is that custom flags could be appended. Another problem is indeed that mesa puts these llvm flags at the end, and the custom user CFLAGS first. irc discussion on oftc #llvm : 18:16 shining^ hopefully someone will look at http://llvm.org/bugs/show_bug.cgi?id=8220 , it should be easy to fix 18:16 gccbot tools bug #8220: llvm-config prints unnecessary cflags Product: tools, Component: llvm-config, Severity: normal, Assigned to: unassignedbugs, Status: NEW 18:20 @ aKor shining^: the PR looks invalid to me. 18:20 @ aKor shining^: all the printed tools are also required for projects 18:21 @ aKor e.g. sometimes O3 is lowered to O2 to workaround compiler miscompilation 18:21 @ aKor if you want to override the settings, you should just append the necessary stuff to the end of cflags / cxxflags 18:54 shining^ aKor: why are they required for projects ? 18:56 @ aKor shining^: because in the projects decent amount of LLVM code is compiled and used. This is mostly the code coming from the headers. 18:57 shining^ I dont think the purpose of that tool is to workaround compiler bugs. its just to provide the minimum set of flags required to build llvm code. maybe there isnt actually any ? 18:58 @ aKor well, if -O2 is *required* to workaround compiler bugs, then it's surely should be included into minimal set of options 18:58 @ aKor (as opposed to -O3) 18:59 shining^ otherwise we need both a minimum set of flags and an optimal set , working around bugs and all 18:59 shining^ why -O2 or -O3 ? maybe I dont want any 19:00 @ aKor ok, then just override it 19:00 @ aKor -O2 -O0 will yield -O0 19:00 shining^ well, its indeed very problematic in mesa, since these flags are appended last :P 19:01 @ aKor then the problem is in mesa's build system :) 19:01 shining^ so my CFLAGS=-O0 settings didnt work at all. I suppose I will go back to mesa people then .. 19:01 shining^ which is where I reported the problem in the first place, of course 19:01 @ aKor in the list in PR only -fomit-frame-pointer -fPIC are redundant 19:02 ddunbar_ shining^: fwiw, I agree with you the -O doesn't belong there 19:02 ddunbar_ or we should have two sets 19:02 @ aKor ddunbar_: it depends on the platform and compiler used 19:02 shining^ well -fomit-frame-pointer annoyed me too, I specifically build with no-omit-frame-pointer so I can get useful profiles 19:04 ddunbar_ aKor: I agree with the principle that it there should be a way to just get the required flags 19:05 @ aKor one should just define required, e.g. required to just build or required to build usable binaries. The latter seems should include more flags :) 19:05 ddunbar_ not that many 19:05 ddunbar_ I think the -D_GNU belong, and -frtti perhaps, but not much more 19:07 @ aKor ddunbar_: rtti settings should always be required, otherwise link will fail 19:07 ddunbar_ which is why I mentioned it :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] cflags mess with llvm builds
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 specifically set -O0 to easier gdb debugging and -fno-omit-frame-pointer to use some profiling tools, but they were both silently overridden by llvm cflags. Also scons/llvm.py only uses cppflags, not cflags, which at least gives a better result llvm-config --cppflags : -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS then src/gallium/Makefile.template has : ifeq ($(MESA_LLVM),1) LIBRARY_DEFINES += $(LLVM_CFLAGS) endif Do we want / need these definitions for all the code in src/gallium, or is it possible to add them only in the parts that do use llvm and need the definitions from llvm-config --cppflags ? I found it weird that enabling or disabling gallium llvm resulted in nv50 gallium built with different gcc flags. From df82cdf0b9b6bd60ef47ddbf4b6d74d200382262 Mon Sep 17 00:00:00 2001 From: Xavier Chantry chantry.xav...@gmail.com Date: Fri, 24 Sep 2010 13:17:40 +0200 Subject: [PATCH] configure.ac : use llvm-config cppflags instead of cflags llvm cflags are too intrusive and override user-defined flags. cppflags are probably enough and this is what scons/llvm.py uses already. $ llvm-config --cflags -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC $ llvm-config --cppflags -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 2b8296d..c88ee5e 100644 --- a/configure.ac +++ b/configure.ac @@ -1439,7 +1439,7 @@ AC_ARG_ENABLE([gallium-llvm], if test x$enable_gallium_llvm = xyes; then if test x$LLVM_CONFIG != xno; then LLVM_VERSION=`$LLVM_CONFIG --version` - LLVM_CFLAGS=`$LLVM_CONFIG --cflags` + LLVM_CFLAGS=`$LLVM_CONFIG --cppflags` LLVM_LIBS=`$LLVM_CONFIG --libs jit interpreter nativecodegen bitwriter` -lstdc++ if test x$HAS_UDIS86 != xno; then -- 1.7.3 ___ 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 3:15 PM, Luca Barbieri l...@luca-barbieri.com wrote: Yes, that used to happen for me too. Just edit llvm-config to remove the offending text and ideally file a bug on the LLVM bug tracker. looks like nobled did this for me : http://llvm.org/bugs/show_bug.cgi?id=8220 thanks :) It's still strange to have scons use --cppflags and autotools --cflags. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nvfx-next in Mesa
On Tue, Jun 8, 2010 at 8:49 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Tue, Jun 8, 2010 at 8:36 PM, Corbin Simpson mostawesomed...@gmail.com wrote: Luca (and anybody else, especially nouveau people), Does anybody want to step up and look at the nvfx-next branches? In IRC, we're looking over some of the parts that got merged to master (util/u_surfaces and util/u_dirty_surfaces) but not seeing the usage. It would be pretty awesome if the rest of the branches could get merged so they don't bitrot. ~ C. Last news I had on April 21th : 4:58 PM Luca: the temporary code somehow breaks nv3x 4:59 PM me: so that blocks the rest, I thought the rest could be merged without that Luca: perhaps Which referred to this commit : commit fac5e2d54f7b6f6eac9b96ad14263ebc4ca93832 Author: Luca Barbieri l...@luca-barbieri.com Date: Sun Apr 18 15:22:43 2010 +0200 nvfx: rewrite render temporaries code, also affecting 2D and resource code This commit rewrites the render temporaries code to make it actually robust and try to make it perform decently. It also significantly affects how miptrees and the 2D code work. I could try to test again this week that merging origin/nvfx-next-6b without the above commit does not break anything on nv35. It sure fixed a lot of things, especially all the 2D work. So some testing I made today with piglit and games. mesa-7.8.1-1455-g5acee66 : 95/174 mesa-7.8.1-1466-g3c0120d : 115/174 mesa-7.8.1-1468-g81bdeee : 114/174 The breakage between 3c0120d and 81bdeee is texturing/lodbias and is caused by the above commit : nvfx: rewrite render temporaries code, also affecting 2D and resource code This same commit also broke the following games : etracer, glest, neverball, foobillard (when using hwtnl, which is the default). The testing work Luca and I made trying to resolve this issue can be seen there : http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/nvfx-next-6b-nv30 If anyone wants to rebase the whole nvfx-next-6b branch without temporaries on top of master, I will happily test that as well. Some interesting piglit changes between old master mesa-7.8.1-1455-g5acee66 and new master mesa-7.8.1-2941-g9ef6d34 : 1) polygonOffset fails polygonOffset: FAIL rgba8, db, z24, s8, win+pmap, id 33 Actual MRD is too large (may waste depth-buffer range) Ideal MRD at near plane is 5.82077e-11 (nominally 0 bits) Actual MRD at near plane is 5.96046e-08 (nominally 1 bit) Ideal MRD at infinity is 5.86733e-08 (nominally 1 bit) Actual MRD at infinity is 1.19209e-07 (nominally 2 bits) 2) fp-long-alu fails Testing: alu_depth = 3077 Probe at (16,16) Expected: 0.312500 0.00 0.75 0.00 Observed: 0.00 0.00 0.00 0.00 3-4) texEnv and levelclamp pass ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nvfx-next in Mesa
On Thu, Jun 10, 2010 at 3:38 PM, Xavier Chantry chantry.xav...@gmail.com wrote: If anyone wants to rebase the whole nvfx-next-6b branch without temporaries on top of master, I will happily test that as well. I just had a look and this rebase seems too complex for me to handle. A better understanding of gallium interface changes and Luca's patches is needed. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: gallium-msaa branch merge
On Tue, May 18, 2010 at 7:04 PM, Roland Scheidegger srol...@vmware.com wrote: Hi, I plan to merge the gallium-msaa branch to master soon. It's actually a bit of a misnomer since the conceptually more important changes in there are about blits... Here's a short summary what this is about: blits now operate on resources, not surfaces (surface_copy/fill - resource_copy/fill_region). Note that overlapping blits are no longer permitted (half the code always assumed this wasn't the case), and these functions are now mandatory (most of the code using these just checked for their presence and if not used util_surface_copy instead, hence it seems cleaner if drivers plug that in themselves, which some already did). Also, there's an assumption that resource_copy_region works regardless of bind flags (at least for texture targets, actually might also need to work for buffers for modern drivers in the future not sure yet), hence there are no longer any PIPE_BIND_BLIT flags (which were quite magic to begin with, since a lot of the code could end up with a quad blit which really wants RENDER_TARGET/SAMPLER_VIEW bind flags instead). It is possible some of the drivers implementation are a bit suboptimal now, as they still use surfaces internally for easier migration (svga, r300g, nouveau might particularly benefit from some cleanup). If a driver implements this just with util_resource_copy_region, it is possible there are performance regressions, since some (certainly not all) state trackers used a quad blitter instead if this wasn't available. The u_blit code still uses a pipe_surface as destination, which should probably be changed at some point too but the change was already big enough imho. Historically, blits had to operate on surfaces IIRC since there actually were surfaces in gallium not backed by a pipe_resource (then pipe_texture) but those are gone. So get_tex_surface() should actually be viewed as the analogous function to create_sampler_view() (and yes it will migrate to context too and probably renamed to something else), it creates a view of a resource (the pipe_surface) to be used as a render target (color or depth/stencil). The msaa changes are fairly minimal, there's a new context function to set the sample mask (all drivers have dummy implementations), plus some bits for sample to coverage etc. And a explicit resource_resolve function which is defined as the only way to resolve a multisampled resource, but so far no driver implements multisampling (and the mesa state tracker won't use it neither). Just including nouveau ML in CC in case someone missed that merge, as I think there is some work to be done in nouveau driver. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glx: Only call DRI2 invalidate when necessary breaks window resizing in nouveau
Patrice reported this a few days ago in nouveau channel and wiki, using xorg 1.7 and probably nvfx driver. I can reproduce with xorg 1.7 and nv50 with current git master. Window resizing (for example with glxgears or any mesa demos/*) is broken, as seen in the following picture : http://omploader.org/vNGM2bg If other gallium drivers work (at least llvmpipe seems to work), does it indicate something wrong in nouveau ? http://cgit.freedesktop.org/mesa/mesa/commit/?id=2d00d16da7f5d2255cb37b48edaf4cbb9ca7e930 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures
On Sun, May 2, 2010 at 3:16 PM, Marek Olšák mar...@gmail.com wrote: On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky maximlevit...@gmail.com wrote: This commit breaks compiz completely here on nvidia G50 (Geforce 8400M) Compiz shows dark screen. (Using nouveau drivers) Without this commit compiz works almost perfectly. The error messages from compiz: debug_get_bool_option: NV50_ALWAYS_PUSH = FALSE debug_get_bool_option: DRAW_FSE = FALSE debug_get_bool_option: DRAW_NO_FSE = FALSE debug_get_bool_option: GALLIUM_DUMP_VS = FALSE Mesa: Mesa 7.9-devel DEBUG build May 1 2010 19:02:06 Mesa warning: software DXTn compression/decompression available debug_get_bool_option: MESA_MVP_DP4 = FALSE debug_get_flags_option: ST_DEBUG = 0x0 Mesa: User error: GL_OUT_OF_MEMORY in glTexImage compiz (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png ^CMesa: User error: GL_OUT_OF_MEMORY in glTexImage The commit also causes surface_copy to be called with S3TC textures, breaking loading of such textures in r300g. I am working on a fix for r300g but I haven't expected to get such weird formats in surface_copy. FYI Maxim, please use mesa-dev@lists.freedesktop.org instead. -Marek This commit also causes piglit fbo-3d test to fail with both llvmpipe and nv50 gallium. http://img163.imageshack.us/img163/535/fbo3d.png ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures
On Mon, May 3, 2010 at 9:11 PM, Brian Paul bri...@vmware.com wrote: This commit also causes piglit fbo-3d test to fail with both llvmpipe and nv50 gallium. http://img163.imageshack.us/img163/535/fbo3d.png Can you retest now? Yup, fbo-3d is back on both nv50 and llvmpipe/swrastg. Thanks ! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] Fix __glXInitializeVisualConfigFromTags's handling of unrecognized fbconfig tags.
On Sun, May 2, 2010 at 10:17 PM, Dave Airlie airl...@gmail.com wrote: On Mon, May 3, 2010 at 3:43 AM, Aaron Plattner aplatt...@nvidia.com wrote: On Sun, May 02, 2010 at 02:39:07AM -0700, Dave Airlie wrote: On Fri, Apr 23, 2010 at 2:30 AM, Aaron Plattner aplatt...@nvidia.com wrote: __glXInitializeVisualConfigFromTags doesn't skip the payload of unrecognized tags. Instead, it treats the value as if it were the next tag, which can happen if the server's GLX extension is not Mesa's. For example, this falls down when NVIDIA sends a GLX_FLOAT_COMPONENTS_NV = 0 pair, causing __glXInitializeVisualConfigFromTags to bail out early. I've had a regression reported on irc from papillon81 with GLX_USE_GL and OpenSceneGraph bisected to this. The spec is pretty clear about the attribute format for protocol: (for visuals) The first 18 properties are ordered; the remaining properties consist of a property type and a property value. (for fbconfigs) The properties consist of a property type and a property value. You use __glXInitializeVisualConfigFromTags in glXChooseVisual, don't you? I think you need something like fbconfig_style_tags bp++; Or I guess you could just hope that the server never sends GLX_USE_GL as a visual or FBconfig property. Oh good point, same handling as GL_RGBA then, This look better? Dave. Ah there, that explains why flightgear just died with Error: Not able to create requested visual. Both patches seem to fix it, thanks ! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50: fixed other void pointer arithmetic errors
scons couldn't build nv50 as it uses -Werror=pointer-arith by default.
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/gallium/drivers/nv50/nv50_push.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_push.c
b/src/gallium/drivers/nv50/nv50_push.c
index 244242b..6ebea54 100644
--- a/src/gallium/drivers/nv50/nv50_push.c
+++ b/src/gallium/drivers/nv50/nv50_push.c
@@ -108,7 +108,7 @@ emit_vertex(struct push_context *ctx, unsigned n)
int i;
if (ctx-edgeflag_attr 16) {
- float *edgeflag = ctx-attr[ctx-edgeflag_attr].map +
+ float *edgeflag = (uint8_t *)ctx-attr[ctx-edgeflag_attr].map +
ctx-attr[ctx-edgeflag_attr].stride * n;
if (*edgeflag != ctx-edgeflag) {
@@ -120,7 +120,7 @@ emit_vertex(struct push_context *ctx, unsigned n)
BEGIN_RING_NI(chan, tesla, NV50TCL_VERTEX_DATA, ctx-vtx_size);
for (i = 0; i ctx-attr_nr; i++)
- ctx-attr[i].push(chan, ctx-attr[i].map + ctx-attr[i].stride * n);
+ ctx-attr[i].push(chan, (uint8_t *)ctx-attr[i].map +
ctx-attr[i].stride * n);
}
static void
@@ -243,14 +243,14 @@ nv50_push_elements_instanced(struct pipe_context *pipe,
assert(bo-map);
return;
}
- ctx.attr[n].map = bo-map + vb-buffer_offset + ve-src_offset;
+ ctx.attr[n].map = (uint8_t *)bo-map + vb-buffer_offset +
ve-src_offset;
nouveau_bo_unmap(bo);
ctx.attr[n].stride = vb-stride;
ctx.attr[n].divisor = ve-instance_divisor;
if (ctx.attr[n].divisor) {
ctx.attr[n].step = i_start % ve-instance_divisor;
- ctx.attr[n].map += i_start * vb-stride;
+ ctx.attr[n].map = (uint8_t *)ctx.attr[n].map + i_start * vb-stride;
}
size = util_format_get_component_bits(ve-src_format,
@@ -331,7 +331,7 @@ nv50_push_elements_instanced(struct pipe_context *pipe,
ctx.attr[i].divisor != ++ctx.attr[i].step)
continue;
ctx.attr[i].step = 0;
- ctx.attr[i].map += ctx.attr[i].stride;
+ ctx.attr[i].map = (uint8_t *)ctx.attr[i].map + ctx.attr[i].stride;
}
u_split_prim_init(s, mode, start, count);
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] texunits: Require OpenGL 1.3
glMultiTexCoord4fv is available only if the GL version is 1.3 or
greater.
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
tests/general/texunits.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tests/general/texunits.c b/tests/general/texunits.c
index 01a5e27..1a5f67e 100644
--- a/tests/general/texunits.c
+++ b/tests/general/texunits.c
@@ -438,6 +438,11 @@ main(int argc, char *argv[])
glewInit();
+ if (!GLEW_VERSION_1_3) {
+ printf(Requires OpenGL 1.3\n);
+ piglit_report_result(PIGLIT_SKIP);
+ }
+
glutReshapeFunc(reshape);
glutDisplayFunc(redisplay);
if (!Automatic) {
--
1.7.0.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
