Re: [Mesa-dev] [PATCH-RFC] autoconf: add --enable-{dri,glx,osmesa}
On Sat, Jul 2, 2011 at 4:10 AM, Jon TURNEY wrote:
> This seems like a useful rationalization of the configuration arguments, but
> one of your follow up patches to this ("autoconf: fix --disable-glx") has
> changed the condition for checking for libdrm from mesadriver=dri &&
> driglx_direct=yes to just enable_dri=yes.
>
> This change causes ./configure --with-driver=dri --disable-driglx-direct to
> fail when libdrm isn't present, see [1].
It should be fixed now. Please try again.
You should be able to replace "--with-driver=dri" by "--disable-dri"
now if all you need is libGL with indirect rendering.
> (I'll just note that I'd also like to be able to ./configure --with-driver=dri
> --with-dri-drivers=swrast without requiring libdrm, as there is no functional
> dependency, but it's not possible to build that at the moment without some
> patching to untangle a build dependency)
That probably could be done by defining HAVE_LIBDRM when libdrm is
available and let glx checks the macro.
> [1]
> http://tinderbox.freedesktop.org/builds/2011-07-01-0004/logs/libGL-indirect-only/#configure
>
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH-RFC] autoconf: add --enable-{dri,glx,osmesa}
On 30/06/2011 02:48, Chia-I Wu wrote:
> On Sun, Jun 26, 2011 at 10:39 PM, Chia-I Wu wrote:
>> From: Chia-I Wu
>>
>> The idea is that DRI driver, libGL and libOSMesa are libraries that can
>> be independently enabled, yet --with-driver does not allow us to easily
>> do that, if not impossible. This also matches what
>> --enable-{egl,xorg,d3d1x} do for the respective libraries.
>>
>> There are two libGL providers: Xlib-based and DRI-based. They cannot
>> coexist. To be able to choose between them, --enable-xlib-glx is also
>> added.
>>
>> With this commit, --with-driver=dri can be replaced by
>>
>> $ ./configure --enable-dri --enable-glx --disable-osmesa
>>
>> --with-driver=xlib can be replaced by
>>
>> $ ./configure --disable-dri --enable-glx --enable-osmesa \
>>--enable-xlib-glx
>>
>> and --with-driver=osmesa can be replaced by
>>
>> $ ./configure --disable-dri --disable-glx --enable-osmesa
>>
>> Some combinations that cannot be supported with --with-driver will
>> produce errors at the moment. But in the future, we would like to
>> support, for example,
>>
>> $ ./configure --enable-dri --disable-glx --enable-egl
>> (build libEGL and DRI drivers, but not libGL)
>>
>> Note that this commit still keeps --with-driver for transitional
>> purpose.
> If there is no objection, I'd like to make the change later this week.
This seems like a useful rationalization of the configuration arguments, but
one of your follow up patches to this ("autoconf: fix --disable-glx") has
changed the condition for checking for libdrm from mesadriver=dri &&
driglx_direct=yes to just enable_dri=yes.
This change causes ./configure --with-driver=dri --disable-driglx-direct to
fail when libdrm isn't present, see [1].
(I'll just note that I'd also like to be able to ./configure --with-driver=dri
--with-dri-drivers=swrast without requiring libdrm, as there is no functional
dependency, but it's not possible to build that at the moment without some
patching to untangle a build dependency)
[1]
http://tinderbox.freedesktop.org/builds/2011-07-01-0004/logs/libGL-indirect-only/#configure
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Gallium: fix buffer overflow
Looks fine. Commited. Thanks.
Jose
- Original Message -
> Indeed. This was copied from the indices version of the function,
> altough that version seems to do some more work to find out the
> true_index. The patch as it is fixes a crash when selecting objects
> in blender though.
> Please verify to make sure it's doing everything correctly since I'm
> still far from being comfortable with the codebase.
> On Fri, Jul 1, 2011 at 1:57 PM, Jose Fonseca < jfons...@vmware.com >
> wrote:
> > I recall seeing this issue before, and I though we had fixed it by
> > ensure the vertices are always padded to be multiple of four.. but
> > I
> > suspect it may have been for fetching indices, and not actual
> > vertices.
>
> > So it looks good, but let me investigate a bit more.
>
> > Jose
>
> > - Original Message -
>
> > > This looks good to me -- Jose?
>
> > >
>
> > > Keith
>
> > >
>
> > > On Thu, 2011-06-30 at 03:33 +0100, Micael Dias wrote:
>
> > > > ---
>
> > > > src/gallium/auxiliary/draw/draw_llvm.c | 12
>
> > > > 1 files changed, 12 insertions(+), 0 deletions(-)
>
> > > >
>
> > > > diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
>
> > > > b/src/gallium/auxiliary/draw/draw_llvm.c
>
> > > > index 56c26f5..19134f3 100644
>
> > > > --- a/src/gallium/auxiliary/draw/draw_llvm.c
>
> > > > +++ b/src/gallium/auxiliary/draw/draw_llvm.c
>
> > > > @@ -1163,6 +1163,7 @@ draw_llvm_generate(struct draw_llvm
> > > > *llvm,
>
> > > > struct draw_llvm_variant *variant)
>
> > > > struct lp_build_loop_state lp_loop;
>
> > > > const int max_vertices = 4;
>
> > > > LLVMValueRef outputs[PIPE_MAX_SHADER_OUTPUTS][NUM_CHANNELS];
>
> > > > + LLVMValueRef fetch_max;
>
> > > > void *code;
>
> > > > struct lp_build_sampler_soa *sampler = 0;
>
> > > > LLVMValueRef ret, ret_ptr;
>
> > > > @@ -1234,6 +1235,10 @@ draw_llvm_generate(struct draw_llvm
> > > > *llvm,
>
> > > > struct draw_llvm_variant *variant)
>
> > > > draw_llvm_variant_key_samplers(&variant->key),
>
> > > > context_ptr);
>
> > > >
>
> > > > + fetch_max = LLVMBuildSub(builder, count,
>
> > > > + lp_build_const_int32(gallivm, 1),
>
> > > > + "fetch_max");
>
> > > > +
>
> > > > #if DEBUG_STORE
>
> > > > lp_build_printf(builder, "start = %d, end = %d, step = %d\n",
>
> > > > start, end, step);
>
> > > > @@ -1257,6 +1262,13 @@ draw_llvm_generate(struct draw_llvm
> > > > *llvm,
>
> > > > struct draw_llvm_variant *variant)
>
> > > > builder,
>
> > > > lp_loop.counter,
>
> > > > lp_build_const_int32(gallivm, i), "");
>
> > > > + LLVMValueRef fetch_ptr;
>
> > > > +
>
> > > > + /* make sure we're not out of bounds which can happen
>
> > > > + * if fetch_count % 4 != 0, because on the last iteration
>
> > > > + * a few of the 4 vertex fetches will be out of bounds */
>
> > > > + true_index = lp_build_min(&bld, true_index, fetch_max);
>
> > > > +
>
> > > > for (j = 0; j < draw->pt.nr_vertex_elements; ++j) {
>
> > > > struct pipe_vertex_element *velem =
>
> > > > &draw->pt.vertex_element[j];
>
> > > > LLVMValueRef vb_index = lp_build_const_int32(gallivm,
>
> > > > velem->vertex_buffer_index);
>
> > >
>
> > >
>
> > >
>
> --
> Micael Dias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38789] [bisected] Hacks cubestorm, noof and pipes from XScreenSaver stopped displaying anything
https://bugs.freedesktop.org/show_bug.cgi?id=38789 Michel Dänzer changed: What|Removed |Added CC||thellst...@vmware.com --- Comment #1 from Michel Dänzer 2011-07-01 09:34:15 PDT --- Thomas, any ideas? -- 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] Call for desktop/graphics/mobile tracks for Linux Plumbers' Conf 2011
We have both desktop (for general graphics/media stuff) and mobile tracks at this year's LPC. So if you're working on a topic related to one of the above areas, especially one that has open issues or spans multiple parts of the stack, please submit a topic for discussion at http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/proposals/new against the appropriate track. If you've already submitted a talk to one of these tracks, you will likely be hearing from us over the next week. We're passed earlybird registration, but you can still sign up and attend. Thanks, Jesse Barker, desktop track lead Daniel Stone, mobile track lead ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Gallium: fix buffer overflow
Indeed. This was copied from the indices version of the function, altough
that version seems to do some more work to find out the true_index. The
patch as it is fixes a crash when selecting objects in blender though.
Please verify to make sure it's doing everything correctly since I'm still
far from being comfortable with the codebase.
On Fri, Jul 1, 2011 at 1:57 PM, Jose Fonseca wrote:
> I recall seeing this issue before, and I though we had fixed it by ensure
> the vertices are always padded to be multiple of four.. but I suspect it may
> have been for fetching indices, and not actual vertices.
>
> So it looks good, but let me investigate a bit more.
>
> Jose
>
> - Original Message -
> > This looks good to me -- Jose?
> >
> > Keith
> >
> > On Thu, 2011-06-30 at 03:33 +0100, Micael Dias wrote:
> > > ---
> > > src/gallium/auxiliary/draw/draw_llvm.c | 12
> > > 1 files changed, 12 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
> > > b/src/gallium/auxiliary/draw/draw_llvm.c
> > > index 56c26f5..19134f3 100644
> > > --- a/src/gallium/auxiliary/draw/draw_llvm.c
> > > +++ b/src/gallium/auxiliary/draw/draw_llvm.c
> > > @@ -1163,6 +1163,7 @@ draw_llvm_generate(struct draw_llvm *llvm,
> > > struct draw_llvm_variant *variant)
> > > struct lp_build_loop_state lp_loop;
> > > const int max_vertices = 4;
> > > LLVMValueRef outputs[PIPE_MAX_SHADER_OUTPUTS][NUM_CHANNELS];
> > > + LLVMValueRef fetch_max;
> > > void *code;
> > > struct lp_build_sampler_soa *sampler = 0;
> > > LLVMValueRef ret, ret_ptr;
> > > @@ -1234,6 +1235,10 @@ draw_llvm_generate(struct draw_llvm *llvm,
> > > struct draw_llvm_variant *variant)
> > >draw_llvm_variant_key_samplers(&variant->key),
> > >context_ptr);
> > >
> > > + fetch_max = LLVMBuildSub(builder, count,
> > > +lp_build_const_int32(gallivm, 1),
> > > +"fetch_max");
> > > +
> > > #if DEBUG_STORE
> > > lp_build_printf(builder, "start = %d, end = %d, step = %d\n",
> > > start, end, step);
> > > @@ -1257,6 +1262,13 @@ draw_llvm_generate(struct draw_llvm *llvm,
> > > struct draw_llvm_variant *variant)
> > > builder,
> > > lp_loop.counter,
> > > lp_build_const_int32(gallivm, i), "");
> > > + LLVMValueRef fetch_ptr;
> > > +
> > > + /* make sure we're not out of bounds which can happen
> > > + * if fetch_count % 4 != 0, because on the last iteration
> > > + * a few of the 4 vertex fetches will be out of bounds */
> > > + true_index = lp_build_min(&bld, true_index, fetch_max);
> > > +
> > > for (j = 0; j < draw->pt.nr_vertex_elements; ++j) {
> > > struct pipe_vertex_element *velem =
> > > &draw->pt.vertex_element[j];
> > > LLVMValueRef vb_index = lp_build_const_int32(gallivm,
> > > velem->vertex_buffer_index);
> >
> >
> >
>
--
Micael Dias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Merging the xa_branch
Hi! I'm planning to merge the xa_branch to master. Let me know if there are any objections. Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Gallium: fix buffer overflow
I recall seeing this issue before, and I though we had fixed it by ensure the
vertices are always padded to be multiple of four.. but I suspect it may have
been for fetching indices, and not actual vertices.
So it looks good, but let me investigate a bit more.
Jose
- Original Message -
> This looks good to me -- Jose?
>
> Keith
>
> On Thu, 2011-06-30 at 03:33 +0100, Micael Dias wrote:
> > ---
> > src/gallium/auxiliary/draw/draw_llvm.c | 12
> > 1 files changed, 12 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
> > b/src/gallium/auxiliary/draw/draw_llvm.c
> > index 56c26f5..19134f3 100644
> > --- a/src/gallium/auxiliary/draw/draw_llvm.c
> > +++ b/src/gallium/auxiliary/draw/draw_llvm.c
> > @@ -1163,6 +1163,7 @@ draw_llvm_generate(struct draw_llvm *llvm,
> > struct draw_llvm_variant *variant)
> > struct lp_build_loop_state lp_loop;
> > const int max_vertices = 4;
> > LLVMValueRef outputs[PIPE_MAX_SHADER_OUTPUTS][NUM_CHANNELS];
> > + LLVMValueRef fetch_max;
> > void *code;
> > struct lp_build_sampler_soa *sampler = 0;
> > LLVMValueRef ret, ret_ptr;
> > @@ -1234,6 +1235,10 @@ draw_llvm_generate(struct draw_llvm *llvm,
> > struct draw_llvm_variant *variant)
> >draw_llvm_variant_key_samplers(&variant->key),
> >context_ptr);
> >
> > + fetch_max = LLVMBuildSub(builder, count,
> > +lp_build_const_int32(gallivm, 1),
> > +"fetch_max");
> > +
> > #if DEBUG_STORE
> > lp_build_printf(builder, "start = %d, end = %d, step = %d\n",
> > start, end, step);
> > @@ -1257,6 +1262,13 @@ draw_llvm_generate(struct draw_llvm *llvm,
> > struct draw_llvm_variant *variant)
> > builder,
> > lp_loop.counter,
> > lp_build_const_int32(gallivm, i), "");
> > + LLVMValueRef fetch_ptr;
> > +
> > + /* make sure we're not out of bounds which can happen
> > + * if fetch_count % 4 != 0, because on the last iteration
> > + * a few of the 4 vertex fetches will be out of bounds */
> > + true_index = lp_build_min(&bld, true_index, fetch_max);
> > +
> > for (j = 0; j < draw->pt.nr_vertex_elements; ++j) {
> > struct pipe_vertex_element *velem =
> > &draw->pt.vertex_element[j];
> > LLVMValueRef vb_index = lp_build_const_int32(gallivm,
> > velem->vertex_buffer_index);
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/13] gallium/util: implement pack functions for Z32F and Z32F_S8X24
On Fri, 2011-07-01 at 14:42 +0200, Marek Olšák wrote:
> On Fri, Jul 1, 2011 at 10:49 AM, Keith Whitwell wrote:
> > On Fri, 2011-07-01 at 02:29 +0200, Marek Olšák wrote:
> >> The suffix of 64 means it returns uint64_t.
> >
> > It might be slightly clearer to call these functions util_pack64_{xxx}
> > -- currently it reads as if it is packing 64-bit source data.
>
> Yeah, that's nicer. Here's the diff I am going to squash with the
> patches 11 and 12.
Looks great!
Keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/13] gallium/util: implement pack functions for Z32F and Z32F_S8X24
On Fri, Jul 1, 2011 at 10:49 AM, Keith Whitwell wrote:
> On Fri, 2011-07-01 at 02:29 +0200, Marek Olšák wrote:
>> The suffix of 64 means it returns uint64_t.
>
> It might be slightly clearer to call these functions util_pack64_{xxx}
> -- currently it reads as if it is packing 64-bit source data.
Yeah, that's nicer. Here's the diff I am going to squash with the
patches 11 and 12.
Marek
diff --git a/src/gallium/auxiliary/util/u_pack_color.h
b/src/gallium/auxiliary/util/u_pack_color.h
index d2dfba5..9391f1b 100644
--- a/src/gallium/auxiliary/util/u_pack_color.h
+++ b/src/gallium/auxiliary/util/u_pack_color.h
@@ -460,7 +460,7 @@ util_pack_mask_z(enum pipe_format format, uint32_t z)
static INLINE uint64_t
-util_pack_mask_z64(enum pipe_format format, uint32_t z)
+util_pack64_mask_z(enum pipe_format format, uint32_t z)
{
switch (format) {
case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
@@ -495,13 +495,13 @@ util_pack_mask_z_stencil(enum pipe_format
format, uint32_t z, uint8_t s)
static INLINE uint64_t
-util_pack_mask_z_stencil64(enum pipe_format format, uint32_t z, uint8_t s)
+util_pack64_mask_z_stencil(enum pipe_format format, uint32_t z, uint8_t s)
{
uint64_t packed;
switch (format) {
case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
- packed = util_pack_mask_z64(format, z);
+ packed = util_pack64_mask_z(format, z);
packed |= (uint64_t)s << 32ull;
return packed;
default:
@@ -556,7 +556,7 @@ util_pack_z(enum pipe_format format, double z)
static INLINE uint64_t
-util_pack_z64(enum pipe_format format, double z)
+util_pack64_z(enum pipe_format format, double z)
{
union fi fui;
@@ -601,13 +601,13 @@ util_pack_z_stencil(enum pipe_format format,
double z, uint8_t s)
static INLINE uint64_t
-util_pack_z_stencil64(enum pipe_format format, double z, uint8_t s)
+util_pack64_z_stencil(enum pipe_format format, double z, uint8_t s)
{
uint64_t packed;
switch (format) {
case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
- packed = util_pack_z64(format, z);
+ packed = util_pack64_z(format, z);
packed |= (uint64_t)s << 32ull;
break;
default:
diff --git a/src/gallium/auxiliary/util/u_surface.c
b/src/gallium/auxiliary/util/u_surface.c
index 8fcf6b9..8e12386 100644
--- a/src/gallium/auxiliary/util/u_surface.c
+++ b/src/gallium/auxiliary/util/u_surface.c
@@ -361,7 +361,7 @@ util_clear_depth_stencil(struct pipe_context *pipe,
break;
case 8:
{
- uint64_t zstencil = util_pack_z_stencil64(dst->texture->format,
+ uint64_t zstencil = util_pack64_z_stencil(dst->texture->format,
depth, stencil);
assert(dst->format == PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/13] mesa: implement depth/stencil renderbuffer wrapper accessors for Z32F_X24S8
On Fri, Jul 1, 2011 at 5:43 AM, Kenneth Graunke wrote:
> On 06/30/2011 05:29 PM, Marek Olšák wrote:
>> ---
>> src/mesa/main/depthstencil.c | 322
>> +++---
>> src/mesa/main/depthstencil.h | 5 +
>> src/mesa/main/framebuffer.c | 10 +-
>> 3 files changed, 313 insertions(+), 24 deletions(-)
>>
>> diff --git a/src/mesa/main/depthstencil.c b/src/mesa/main/depthstencil.c
>> index ab62c97..f979045 100644
>> --- a/src/mesa/main/depthstencil.c
>> +++ b/src/mesa/main/depthstencil.c
> [snip]
>> +static void
>> +put_values_z32f(struct gl_context *ctx, struct gl_renderbuffer *z32frb,
>> GLuint count,
>> + const GLint x[], const GLint y[],
>> + const void *values, const GLubyte *mask)
>> +{
>> + struct gl_renderbuffer *dsrb = z32frb->Wrapped;
>> + const GLfloat *src = (const GLfloat *) values;
>> + ASSERT(z32frb->DataType == GL_FLOAT);
>> + ASSERT(dsrb->DataType == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
>> + ASSERT(dsrb->Format == MESA_FORMAT_Z32_FLOAT_X24S8);
>> + if (dsrb->GetPointer(ctx, dsrb, 0, 0)) {
>> + /* direct access */
>> + GLuint i;
>> + for (i = 0; i < count; i++) {
>> + if (!mask || mask[i]) {
>> + GLfloat *dst = (GLfloat *) dsrb->GetPointer(ctx, dsrb, x[i],
>> y[i]);
>> + dst[1] = src[i];
>
> Don't you mean dst[0] = src[i] here? With dst[1], you'll be assigning
> to the stencil value...
Yes, that's right. Thanks for reviewing. I'll change that to *dst.
Marek
>
>> + }
>> + }
>> + }
>> + else {
>> + /* get, modify, put */
>> + GLfloat temp[MAX_WIDTH*2];
>> + GLuint i;
>> + dsrb->GetValues(ctx, dsrb, count, x, y, temp);
>> + for (i = 0; i < count; i++) {
>> + if (!mask || mask[i]) {
>> + temp[i*2] = src[i];
>
> ...when clearly this is assigning to the depth value.
>
>> + }
>> + }
>> + dsrb->PutValues(ctx, dsrb, count, x, y, temp, mask);
>> + }
>> +}
> [snip]
>
> With that fixed, this patch is:
>
> Reviewed-by: Kenneth Graunke
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] xmlconfig: Make the error message more informative
>From 5e32454f2fb3390eea6a3af8ddbe8ad410823aec Mon Sep 17 00:00:00 2001
From: Lauri Kasanen
Date: Fri, 1 Jul 2011 13:49:18 +0300
Subject: [PATCH] xmlconfig: Make the error message more informative
Signed-off-by: Lauri Kasanen
---
src/mesa/drivers/dri/common/xmlconfig.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
b/src/mesa/drivers/dri/common/xmlconfig.c
index 0226b38..23a0ce4 100644
--- a/src/mesa/drivers/dri/common/xmlconfig.c
+++ b/src/mesa/drivers/dri/common/xmlconfig.c
@@ -567,7 +567,7 @@ static void parseOptInfoAttr (struct OptInfoData *data,
const XML_Char **attr) {
} else
defaultVal = attrVal[OA_DEFAULT];
if (!parseValue (&cache->values[opt], cache->info[opt].type, defaultVal))
- XML_FATAL ("illegal default value: %s.", defaultVal);
+ XML_FATAL ("illegal default value for %s: %s.", cache->info[opt].name,
defaultVal);
if (attrVal[OA_VALID]) {
if (cache->info[opt].type == DRI_BOOL)
--
1.7.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Gallium: fix buffer overflow
This looks good to me -- Jose?
Keith
On Thu, 2011-06-30 at 03:33 +0100, Micael Dias wrote:
> ---
> src/gallium/auxiliary/draw/draw_llvm.c | 12
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
> b/src/gallium/auxiliary/draw/draw_llvm.c
> index 56c26f5..19134f3 100644
> --- a/src/gallium/auxiliary/draw/draw_llvm.c
> +++ b/src/gallium/auxiliary/draw/draw_llvm.c
> @@ -1163,6 +1163,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
> draw_llvm_variant *variant)
> struct lp_build_loop_state lp_loop;
> const int max_vertices = 4;
> LLVMValueRef outputs[PIPE_MAX_SHADER_OUTPUTS][NUM_CHANNELS];
> + LLVMValueRef fetch_max;
> void *code;
> struct lp_build_sampler_soa *sampler = 0;
> LLVMValueRef ret, ret_ptr;
> @@ -1234,6 +1235,10 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
> draw_llvm_variant *variant)
>draw_llvm_variant_key_samplers(&variant->key),
>context_ptr);
>
> + fetch_max = LLVMBuildSub(builder, count,
> +lp_build_const_int32(gallivm, 1),
> +"fetch_max");
> +
> #if DEBUG_STORE
> lp_build_printf(builder, "start = %d, end = %d, step = %d\n",
> start, end, step);
> @@ -1257,6 +1262,13 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
> draw_llvm_variant *variant)
> builder,
> lp_loop.counter,
> lp_build_const_int32(gallivm, i), "");
> + LLVMValueRef fetch_ptr;
> +
> + /* make sure we're not out of bounds which can happen
> + * if fetch_count % 4 != 0, because on the last iteration
> + * a few of the 4 vertex fetches will be out of bounds */
> + true_index = lp_build_min(&bld, true_index, fetch_max);
> +
> for (j = 0; j < draw->pt.nr_vertex_elements; ++j) {
> struct pipe_vertex_element *velem = &draw->pt.vertex_element[j];
> LLVMValueRef vb_index = lp_build_const_int32(gallivm,
> velem->vertex_buffer_index);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] driconf cleanups
>From 3a841559d64d7a482fde9e6ee9f5225494db5ae7 Mon Sep 17 00:00:00 2001 From: Lauri Kasanen Date: Fri, 1 Jul 2011 13:01:00 +0300 Subject: [PATCH 2/2] xmlpool.h: fix a typo Signed-off-by: Lauri Kasanen --- src/mesa/drivers/dri/common/xmlpool.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/common/xmlpool.h b/src/mesa/drivers/dri/common/xmlpool.h index 587517e..ffea430 100644 --- a/src/mesa/drivers/dri/common/xmlpool.h +++ b/src/mesa/drivers/dri/common/xmlpool.h @@ -60,7 +60,7 @@ #define DRI_CONF_OPT_BEGIN(name,type,def) \ "\n" -/** \brief Begin an option definition with qouted default value */ +/** \brief Begin an option definition with quoted default value */ #define DRI_CONF_OPT_BEGIN_Q(name,type,def) \ "\n" -- 1.7.2.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] driconf cleanups
Hi Two small driconf cleanups I stumbled upon. The first is similar to what was posted earlier by Carl-Philip Haensch. >From 67219c7bbaa1b52c9d223dccabd0af8b9fecb982 Mon Sep 17 00:00:00 2001 From: Lauri Kasanen Date: Fri, 1 Jul 2011 12:57:06 +0300 Subject: [PATCH 1/2] st/dri: Indent driconf options Signed-off-by: Lauri Kasanen --- src/gallium/state_trackers/dri/common/dri_screen.c | 18 +++--- 1 files changed, 11 insertions(+), 7 deletions(-) diff --git a/src/gallium/state_trackers/dri/common/dri_screen.c b/src/gallium/state_trackers/dri/common/dri_screen.c index 5931df9..c964794 100644 --- a/src/gallium/state_trackers/dri/common/dri_screen.c +++ b/src/gallium/state_trackers/dri/common/dri_screen.c @@ -42,13 +42,17 @@ #include "util/u_debug.h" PUBLIC const char __driConfigOptions[] = - DRI_CONF_BEGIN DRI_CONF_SECTION_PERFORMANCE - DRI_CONF_FTHROTTLE_MODE(DRI_CONF_FTHROTTLE_IRQS) - DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_DEF_INTERVAL_0) - DRI_CONF_SECTION_END DRI_CONF_SECTION_QUALITY -/* DRI_CONF_FORCE_S3TC_ENABLE(false) */ - DRI_CONF_ALLOW_LARGE_TEXTURES(1) - DRI_CONF_SECTION_END DRI_CONF_END; + DRI_CONF_BEGIN + DRI_CONF_SECTION_PERFORMANCE + DRI_CONF_FTHROTTLE_MODE(DRI_CONF_FTHROTTLE_IRQS) + DRI_CONF_VBLANK_MODE(DRI_CONF_VBLANK_DEF_INTERVAL_0) + DRI_CONF_SECTION_END + + DRI_CONF_SECTION_QUALITY +/* DRI_CONF_FORCE_S3TC_ENABLE(false) */ + DRI_CONF_ALLOW_LARGE_TEXTURES(1) + DRI_CONF_SECTION_END + DRI_CONF_END; static const uint __driNConfigOptions = 3; -- 1.7.2.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Gallium: fix buffer overflow
---
src/gallium/auxiliary/draw/draw_llvm.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 56c26f5..19134f3 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -1163,6 +1163,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant)
struct lp_build_loop_state lp_loop;
const int max_vertices = 4;
LLVMValueRef outputs[PIPE_MAX_SHADER_OUTPUTS][NUM_CHANNELS];
+ LLVMValueRef fetch_max;
void *code;
struct lp_build_sampler_soa *sampler = 0;
LLVMValueRef ret, ret_ptr;
@@ -1234,6 +1235,10 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant)
draw_llvm_variant_key_samplers(&variant->key),
context_ptr);
+ fetch_max = LLVMBuildSub(builder, count,
+lp_build_const_int32(gallivm, 1),
+"fetch_max");
+
#if DEBUG_STORE
lp_build_printf(builder, "start = %d, end = %d, step = %d\n",
start, end, step);
@@ -1257,6 +1262,13 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant)
builder,
lp_loop.counter,
lp_build_const_int32(gallivm, i), "");
+ LLVMValueRef fetch_ptr;
+
+ /* make sure we're not out of bounds which can happen
+ * if fetch_count % 4 != 0, because on the last iteration
+ * a few of the 4 vertex fetches will be out of bounds */
+ true_index = lp_build_min(&bld, true_index, fetch_max);
+
for (j = 0; j < draw->pt.nr_vertex_elements; ++j) {
struct pipe_vertex_element *velem = &draw->pt.vertex_element[j];
LLVMValueRef vb_index = lp_build_const_int32(gallivm,
velem->vertex_buffer_index);
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/13] gallium/util: implement pack functions for Z32F and Z32F_S8X24
On Fri, 2011-07-01 at 02:29 +0200, Marek Olšák wrote:
> The suffix of 64 means it returns uint64_t.
It might be slightly clearer to call these functions util_pack64_{xxx}
-- currently it reads as if it is packing 64-bit source data.
Keith
> ---
> src/gallium/auxiliary/util/u_pack_color.h | 64
> +
> 1 files changed, 64 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_pack_color.h
> b/src/gallium/auxiliary/util/u_pack_color.h
> index 5378f2d..d2dfba5 100644
> --- a/src/gallium/auxiliary/util/u_pack_color.h
> +++ b/src/gallium/auxiliary/util/u_pack_color.h
> @@ -458,6 +458,19 @@ util_pack_mask_z(enum pipe_format format, uint32_t z)
> }
> }
>
> +
> +static INLINE uint64_t
> +util_pack_mask_z64(enum pipe_format format, uint32_t z)
> +{
> + switch (format) {
> + case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
> + return z;
> + default:
> + return util_pack_mask_z(format, z);
> + }
> +}
> +
> +
> static INLINE uint32_t
> util_pack_mask_z_stencil(enum pipe_format format, uint32_t z, uint8_t s)
> {
> @@ -481,6 +494,21 @@ util_pack_mask_z_stencil(enum pipe_format format,
> uint32_t z, uint8_t s)
> }
>
>
> +static INLINE uint64_t
> +util_pack_mask_z_stencil64(enum pipe_format format, uint32_t z, uint8_t s)
> +{
> + uint64_t packed;
> +
> + switch (format) {
> + case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
> + packed = util_pack_mask_z64(format, z);
> + packed |= (uint64_t)s << 32ull;
> + return packed;
> + default:
> + return util_pack_mask_z_stencil(format, z, s);
> + }
> +}
> +
>
> /**
> * Note: it's assumed that z is in [0,1]
> @@ -525,6 +553,24 @@ util_pack_z(enum pipe_format format, double z)
>return 0;
> }
> }
> +
> +
> +static INLINE uint64_t
> +util_pack_z64(enum pipe_format format, double z)
> +{
> + union fi fui;
> +
> + if (z == 0)
> + return 0;
> +
> + switch (format) {
> + case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
> + fui.f = (float)z;
> + return fui.ui;
> + default:
> + return util_pack_z(format, z);
> + }
> +}
>
>
> /**
> @@ -554,6 +600,24 @@ util_pack_z_stencil(enum pipe_format format, double z,
> uint8_t s)
> }
>
>
> +static INLINE uint64_t
> +util_pack_z_stencil64(enum pipe_format format, double z, uint8_t s)
> +{
> + uint64_t packed;
> +
> + switch (format) {
> + case PIPE_FORMAT_Z32_FLOAT_S8X24_USCALED:
> + packed = util_pack_z64(format, z);
> + packed |= (uint64_t)s << 32ull;
> + break;
> + default:
> + return util_pack_z_stencil(format, z, s);
> + }
> +
> + return packed;
> +}
> +
> +
> /**
> * Pack 4 ubytes into a 4-byte word
> */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38869] New: Cannot create a valid pBuffer with height and/or width of zero
https://bugs.freedesktop.org/show_bug.cgi?id=38869 Summary: Cannot create a valid pBuffer with height and/or width of zero Product: Mesa Version: 7.10 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/X11 AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: jonathan.kirk...@arm.com Both the EGL and GLX specifications allow pbuffers to be created with a height and/or width of zero (and these are the default values). The MESA implmentation simply returns a surface handle of zero in Fake_glXCreatePbuffer (within fakeglx.c) when these values are used, without throwing an error. Because an error has not been thrown it appears than the buffer is valid when it is not. Subsequent calls to query or destroy the buffer will cause errors. Other implementations throw a BAD_VALUE error in this case although this is not part of either specification. -- 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
