[Mesa-dev] [Bug 54626] llvmpipe's Makefile doesn't take care of CXXFLAGS or CPPFLAGS
https://bugs.freedesktop.org/show_bug.cgi?id=54626 --- Comment #1 from Alexandre Demers --- A simple solution is to add $(CXXFLAGS) at the end of LDFLAGS += $(LLVM_LDFLAGS) in llvmpipe's Makefile. This gives: LDFLAGS += $(LLVM_LDFLAGS) $(CXXFLAGS) and it fixes the build. Is it the right place to add it? Any comments? Actually, I think the Makefile itself is wrong compared to others, like under r600. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] scons: Disable build of assembly sources on Cygwin.
The assembly sources currently do not build on Cygwin.
Signed-off-by: Vinson Lee
---
src/mapi/glapi/SConscript |2 +-
src/mesa/SConscript |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/SConscript b/src/mapi/glapi/SConscript
index ad007a6..c336c25 100644
--- a/src/mapi/glapi/SConscript
+++ b/src/mapi/glapi/SConscript
@@ -48,7 +48,7 @@ for s in mapi_sources:
#
# Assembly sources
#
-if env['gcc'] and env['platform'] not in ('darwin', 'windows'):
+if env['gcc'] and env['platform'] not in ('cygwin', 'darwin', 'windows'):
GLAPI = '#src/mapi/glapi/'
if env['machine'] == 'x86':
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index dba75a2..9819082 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -371,7 +371,7 @@ if env['gles']:
#
# Assembly sources
#
-if env['gcc'] and env['platform'] not in ('darwin', 'windows'):
+if env['gcc'] and env['platform'] not in ('cygwin', 'darwin', 'windows'):
if env['machine'] == 'x86':
env.Append(CPPDEFINES = [
'USE_X86_ASM',
--
1.7.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 07/10] i965: Replace brw_wm_* with dumping code into the fs_visitor.
On 09/27/2012 05:27 PM, Eric Anholt wrote:
> Kenneth Graunke writes:
>
>> On 09/22/2012 02:04 PM, Eric Anholt wrote:
>>> This makes a giant pile of code newly dead. It also fixes TXB on newer
>>> chipsets, which has been totally broken (I now have a piglit test for that).
>>> It passes the same set of Ian's ARB_fragment_program tests. It also
>>> improves
>>> high-settings ETQW performance by 3.2 +/- 1.9% (n=3), thanks to better
>>> optimization and having 8-wide along with 16-wide shaders.
>>> ---
>>> src/mesa/drivers/dri/i965/Makefile.sources |1 +
>>> src/mesa/drivers/dri/i965/brw_fs.cpp | 36 +-
>>> src/mesa/drivers/dri/i965/brw_fs.h | 30 +-
>>> src/mesa/drivers/dri/i965/brw_fs_emit.cpp| 22 +-
>>> src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 781
>>> ++
>>> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |3 +-
>>> src/mesa/drivers/dri/i965/brw_wm.c | 58 +-
>>> src/mesa/drivers/dri/i965/brw_wm_state.c | 19 +-
>>> src/mesa/drivers/dri/i965/gen6_wm_state.c|8 +-
>>> src/mesa/drivers/dri/i965/gen7_wm_state.c|8 +-
>>> 10 files changed, 857 insertions(+), 109 deletions(-)
>>> create mode 100644 src/mesa/drivers/dri/i965/brw_fs_fp.cpp
>>
>> I think the LIT code may be broken (comments inline), and one comment is
>> wrong. Assuming you fix (or refute) those, then patches 1-8 are:
>> Reviewed-by: Kenneth Graunke
>>
>> I haven't read through 9 and 10 yet, but I plan to soon.
>
>>> +void
>>> +fs_visitor::emit_fragment_program_code()
>>> +{
>>> + setup_fp_regs();
>>> +
>>> + fs_reg null = fs_reg(brw_null_reg());
>>> +
>>> + /* Keep a reg with 0.0 around, for reuse use by emit_sop so that it can
>>
>> "Keep a reg with 1.0 around, for reuse by emit_fp_sop"
>> ^^^ (not 0.0) ^^ (function name)
>
> fixed
>
>>> + case OPCODE_DP2:
>>> + case OPCODE_DP3:
>>> + case OPCODE_DP4:
>>> + case OPCODE_DPH: {
>>> + fs_reg mul = fs_reg(this, glsl_type::float_type);
>>> + fs_reg acc = fs_reg(this, glsl_type::float_type);
>>> + int count;
>>> +
>>> + switch (fpi->Opcode) {
>>> + case OPCODE_DP2: count = 2; break;
>>> + case OPCODE_DP3: count = 3; break;
>>> + case OPCODE_DP4: count = 4; break;
>>> + case OPCODE_DPH: count = 3; break;
>>> + default: assert(!"not reached"); count = 0; break;
>>> + }
>>> +
>>> + emit(BRW_OPCODE_MUL, acc,
>>> + regoffset(src[0], 0), regoffset(src[1], 0));
>>> + for (int i = 1; i < count; i++) {
>>> +emit(BRW_OPCODE_MUL, mul,
>>> + regoffset(src[0], i), regoffset(src[1], i));
>>> +emit(BRW_OPCODE_ADD, acc, acc, mul);
>>> + }
>>
>> Future optimization: MAD would be nice here, but that can be done later.
>
> Yeah, or even MACs. This is a codegen quality regression from
> brw_wm_*.c.
>
>>> + case OPCODE_LIT:
>>> + /* From the ARB_fragment_program spec:
>>> + *
>>> + * tmp = VectorLoad(op0);
>>> + * if (tmp.x < 0) tmp.x = 0;
>>> + * if (tmp.y < 0) tmp.y = 0;
>>> + * if (tmp.w < -(128.0-epsilon)) tmp.w = -(128.0-epsilon);
>>> + * else if (tmp.w > 128-epsilon) tmp.w = 128-epsilon;
>>> + * result.x = 1.0;
>>> + * result.y = tmp.x;
>>> + * result.z = (tmp.x > 0) ? RoughApproxPower(tmp.y, tmp.w) :
>>> 0.0;
>>> + * result.w = 1.0;
>>> + */
>>> + if (fpi->DstReg.WriteMask & WRITEMASK_X)
>>> +emit(BRW_OPCODE_MOV, regoffset(dst, 0), fs_reg(1.0f));
>>> +
>>> + if (fpi->DstReg.WriteMask & WRITEMASK_YZ) {
>>> +fs_inst *inst;
>>> +inst = emit(BRW_OPCODE_CMP, null,
>>> +regoffset(src[0], 0), fs_reg(0.0f));
>>> +inst->conditional_mod = BRW_CONDITIONAL_LE;
>>> +
>>> +if (fpi->DstReg.WriteMask & WRITEMASK_Y) {
>>> + emit(BRW_OPCODE_MOV, regoffset(dst, 1), regoffset(src[0],
>>> 0));
>>> + inst = emit(BRW_OPCODE_MOV, regoffset(dst, 1),
>>> fs_reg(0.0f));
>>> + inst->predicated = true;
>>> +}
>>> +
>>> +if (fpi->DstReg.WriteMask & WRITEMASK_Z) {
>>> + emit_math(SHADER_OPCODE_POW, regoffset(dst, 2),
>>> + regoffset(src[0], 1), regoffset(src[0], 3));
>>> +
>>> + inst = emit(BRW_OPCODE_MOV, regoffset(dst, 2),
>>> fs_reg(0.0f));
>>> + inst->predicated = true;
>>
>> This looks broken...don't you need to handle clamping to (-128, 128)?
>
> Ah, I lifted this code directly from the former backend. I'll put in a
> note that I didn't change behavior.
>
> I don't know of any use for the -128,128 clamping. I think it's just a
> spec artifact from this extension being written for a particular
> hardware instruction set. We
Re: [Mesa-dev] [PATCH 1/7] i965: Create local temporaries for depth buffer slice dimensions.
On 09/27/2012 04:48 PM, Eric Anholt wrote: > Kenneth Graunke writes: > >> We use these in a couple of places, and slice_width/height is a lot >> shorter than mt->level[depth_irb->mt_level].width. Saves a few >> dereferences as well. > > I think we could just use fb->Width/fb->Height, which would similarly > save on typing. Yeah, sorry for not mentioning it...I dropped this patch. Chad told me that the two are not equal and fb->Width is what we really want...at which point, this patch is rather pointless. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52435] Classic DRI drivers fail to install when libdricore8.1.0.so isn't already in the system
https://bugs.freedesktop.org/show_bug.cgi?id=52435 Laurent carlier changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Laurent carlier --- Not fixed: ==> Starting package_ati-dri-git()... make: Entering directory `/build/src/mesa-git/src/mesa/drivers/dri/radeon' /usr/bin/mkdir -p ../../../../../lib; ln -f .libs/radeon_dri.so ../../../../../lib/radeon_dri.so; make[1]: Entering directory `/build/src/mesa-git/src/mesa/drivers/dri/radeon' make[1]: Nothing to be done for `install-exec-am'. /usr/bin/mkdir -p '/build/pkg/ati-dri-git/usr/lib/xorg/modules/dri' /bin/sh ../../../../../libtool --mode=install /usr/bin/install -c radeon_dri.la '/build/pkg/ati-dri-git/usr/lib/xorg/modules/dri' libtool: install: warning: relinking `radeon_dri.la' libtool: install: (cd /build/src/mesa-git/src/mesa/drivers/dri/radeon; /bin/sh /build/src/mesa-git/libtool --silent --tag CC --mode=relink gcc -DRADEON_R100 -I../../../../../include -I../../../../../src/ -I../../../../../src/mapi -I../../../../../src/mesa/ -I../../../../../src/mesa/drivers/dri/common -I../../../../../src/mesa/drivers/dri/radeon/server -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_LLVM=0x0301 -DFEATURE_GL=1 -DFEATURE_ES1=1 -DFEATURE_ES2=1 -I/usr/include/libdrm -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -module -avoid-version -shared -Wl,-O1,--sort-common,--as-needed,-z,relro -o radeon_dri.la -rpath /usr/lib/xorg/modules/dri radeon_buffer_objects.lo radeon_common_context.lo radeon_common.lo radeon_dma.lo radeon_debug.lo radeon_fbo.lo radeon_fog.lo radeon_mipmap_tree.lo radeon_pixel_read.lo radeon_queryobj.lo radeon_span.lo radeon_texture.lo radeon_tex_copy.lo radeon_tile.lo radeon_context.lo radeon_ioctl.lo radeon_screen.lo radeon_state.lo radeon_state_init.lo radeon_tex.lo radeon_texstate.lo radeon_tcl.lo radeon_swtcl.lo radeon_maos.lo radeon_sanity.lo radeon_blit.lo ../../../../../src/mesa/libdricore/libdricore9.1.0.la -ldrm -lexpat -lm -lpthread -ldl -ldrm_radeon ../common/libdricommon.la -inst-prefix-dir /build/pkg/ati-dri-git) /usr/bin/ld: cannot find -ldricore9.1.0 collect2: error: ld returned 1 exit status libtool: install: error: relink `radeon_dri.la' with the above command before installing it make[1]: *** [install-driLTLIBRARIES] Error 1 make[1]: Leaving directory `/build/src/mesa-git/src/mesa/drivers/dri/radeon' make: *** [install-am] Error 2 make: Leaving directory `/build/src/mesa-git/src/mesa/drivers/dri/radeon' ==> ERROR: A failure occurred in package_ati-dri-git(). Aborting... ==> ERROR: Build failed, check /var/lib/archbuild/mesagit-x86_64/lordh/build -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Fix size of temporary etc1 buffer
On 09/25/2012 10:02 PM, Chad Versace wrote: > On 09/21/2012 03:18 AM, Tapani Pälli wrote: >> Hello; >> >> On 09/20/2012 11:01 PM, Chad Versace wrote: >>> Adding Tapani to the CC list. Removing Oliver. >>> >>> On 09/20/2012 09:55 PM, Chad Versace wrote: Fixes valgrind errors in piglit test oes_compressed_etc1_rgb8_texture-miptree: an invalid write in _mesa_store_compressed_store_texsubimage() at line 4406 and invalid reads in texcompress_etc_tmp.h:etc1_parse_block(). The calculation of the size of the temporary etc1 buffer allocated by intel_miptree_map_etc1() was incorrect. Sometimes the allocated buffer was too small, sometimes too large. This patch corrects the size to that expected by _mesa_store_compressed_store_texsubimage(). >> >> With GLBenchmark2.5 on Android including the patch I'm still having some >> issues within etc1 unpack and I think these are related to the size of >> the buffer which is eventually given for '_mesa_etc1_unpack_rgba', >> I'll try to come up with a smaller test case for this if possible and >> step with gdb for some more details. This patch looks proper and correct >> for me, maybe these issues left originate from some place else. > > What are the properties of the texture image for which etc1 unpack fails? > Level, > base width, base height, level width, level height? With that information, I > could also create a small testcase and start investigating. Sorry for the delay, was busy with other things. Actually seems like the error happens because of intel_region_map fails for a certain texture, there are multiple succeeded maps and unmaps before this one though, I will debug some more to find out why we end up in this situation. > By the way, I just posted a v2 of the patch. > -- // Tapani signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 1/1] intel: add support for ANGLE_texture_compression_dxt.
On 09/27/2012 01:56 AM, Oliver McFadden wrote:
> Signed-off-by: Oliver McFadden
> ---
> v4: Off-by-one on a couple of 'if (ctx->Mesa_DXTn)' lines, which could cause a
> crash.
>
> src/glx/glxextensions.h |3 ++-
> src/mapi/glapi/gen/es_EXT.xml |6 ++
> src/mesa/drivers/dri/intel/intel_extensions.c |1 +
> src/mesa/main/APIspec.xml |3 +++
> src/mesa/main/extensions.c|3 +++
> src/mesa/main/glformats.c |6 --
> src/mesa/main/glheader.h | 11 +++
> src/mesa/main/mtypes.h|1 +
> src/mesa/main/texformat.c |9 ++---
> src/mesa/main/teximage.c | 10 ++
> 10 files changed, 47 insertions(+), 6 deletions(-)
>
> diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
> index 90c27a7..9e072e4 100644
> --- a/src/glx/glxextensions.h
> +++ b/src/glx/glxextensions.h
> @@ -67,7 +67,8 @@ enum
>
> enum
> {
> - GL_ARB_depth_texture_bit = 0,
> + GL_ANGLE_texture_compression_dxt_bit = 0,
> + GL_ARB_depth_texture_bit,
> GL_ARB_draw_buffers_bit,
> GL_ARB_fragment_program_bit,
> GL_ARB_fragment_program_shadow_bit,
You shouldn't need to change GLX code to add a purely client-side
extension. I believe you can safely drop this hunk (and please do).
> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> index fc2ec62..2698110 100644
> --- a/src/mapi/glapi/gen/es_EXT.xml
> +++ b/src/mapi/glapi/gen/es_EXT.xml
> @@ -731,4 +731,10 @@
>
>
>
> +
> +
> +
> +
> +
> +
>
> diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
> b/src/mesa/drivers/dri/intel/intel_extensions.c
> index 89f6c1e..8a46488 100755
> --- a/src/mesa/drivers/dri/intel/intel_extensions.c
> +++ b/src/mesa/drivers/dri/intel/intel_extensions.c
> @@ -182,6 +182,7 @@ intelInitExtensions(struct gl_context *ctx)
> }
>
> if (intel->ctx.Mesa_DXTn) {
> + ctx->Extensions.ANGLE_texture_compression_dxt = true;
>ctx->Extensions.EXT_texture_compression_s3tc = true;
>ctx->Extensions.S3_s3tc = true;
> }
> diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
> index a65c5c5..c396952 100644
> --- a/src/mesa/main/APIspec.xml
> +++ b/src/mesa/main/APIspec.xml
> @@ -2172,6 +2172,9 @@
>
>
>
> +
> +
> +
>
>
>
> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> index bd7c7ba..4971ebc 100644
> --- a/src/mesa/main/extensions.c
> +++ b/src/mesa/main/extensions.c
> @@ -195,6 +195,8 @@ static const struct extension extension_table[] = {
> { "GL_EXT_texture3D", o(EXT_texture3D),
> GLL,1996 },
> { "GL_EXT_texture_array", o(EXT_texture_array),
> GL, 2006 },
> { "GL_EXT_texture_compression_dxt1",
> o(EXT_texture_compression_s3tc),GL | ES1 | ES2, 2004 },
> + { "GL_ANGLE_texture_compression_dxt3",
> o(ANGLE_texture_compression_dxt), ES2,2011 },
> + { "GL_ANGLE_texture_compression_dxt5",
> o(ANGLE_texture_compression_dxt), ES2,2011 },
> { "GL_EXT_texture_compression_latc",
> o(EXT_texture_compression_latc),GL, 2006 },
> { "GL_EXT_texture_compression_rgtc",
> o(ARB_texture_compression_rgtc),GL, 2004 },
> { "GL_EXT_texture_compression_s3tc",
> o(EXT_texture_compression_s3tc),GL, 2000 },
> @@ -480,6 +482,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
> ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
> _mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
> if (ctx->Mesa_DXTn) {
> + ctx->Extensions.ANGLE_texture_compression_dxt = GL_TRUE;
>_mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
>_mesa_enable_extension(ctx, "GL_S3_s3tc");
> }
> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> index 04029c0..ccdf56b 100644
> --- a/src/mesa/main/glformats.c
> +++ b/src/mesa/main/glformats.c
> @@ -791,8 +791,10 @@ _mesa_is_compressed_format(struct gl_context *ctx,
> GLenum format)
>return ctx->Extensions.EXT_texture_compression_s3tc;
> case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
> case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
> - return _mesa_is_desktop_gl(ctx)
> - && ctx->Extensions.EXT_texture_compression_s3tc;
> + return (_mesa_is_desktop_gl(ctx) &&
> + ctx->Extensions.EXT_texture_compression_s3tc) ||
> + (ctx->API == API_OPENGLES2 &&
> + ctx->Extensions.ANGLE_texture_compression_dxt);
> case GL_RGB_S3TC:
> case GL_RGB4_S3TC:
> case GL_RGBA_S3TC:
> diff --git a/src/mesa/main/glheader
Re: [Mesa-dev] [PATCH v4 1/1] intel: add support for ANGLE_texture_compression_dxt.
On Fri, Sep 28, 2012 at 01:12:55AM -0700, Kenneth Graunke wrote:
> On 09/27/2012 01:56 AM, Oliver McFadden wrote:
> > Signed-off-by: Oliver McFadden
> > ---
> > v4: Off-by-one on a couple of 'if (ctx->Mesa_DXTn)' lines, which could
> > cause a
> > crash.
> >
> > src/glx/glxextensions.h |3 ++-
> > src/mapi/glapi/gen/es_EXT.xml |6 ++
> > src/mesa/drivers/dri/intel/intel_extensions.c |1 +
> > src/mesa/main/APIspec.xml |3 +++
> > src/mesa/main/extensions.c|3 +++
> > src/mesa/main/glformats.c |6 --
> > src/mesa/main/glheader.h | 11 +++
> > src/mesa/main/mtypes.h|1 +
> > src/mesa/main/texformat.c |9 ++---
> > src/mesa/main/teximage.c | 10 ++
> > 10 files changed, 47 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
> > index 90c27a7..9e072e4 100644
> > --- a/src/glx/glxextensions.h
> > +++ b/src/glx/glxextensions.h
> > @@ -67,7 +67,8 @@ enum
> >
> > enum
> > {
> > - GL_ARB_depth_texture_bit = 0,
> > + GL_ANGLE_texture_compression_dxt_bit = 0,
> > + GL_ARB_depth_texture_bit,
> > GL_ARB_draw_buffers_bit,
> > GL_ARB_fragment_program_bit,
> > GL_ARB_fragment_program_shadow_bit,
>
> You shouldn't need to change GLX code to add a purely client-side
> extension. I believe you can safely drop this hunk (and please do).
I need ANGLE_texture_compression_dxt somewhere in the extension table,
see src/mesa/main/extensions.c. Unfortunately it's not possible to
unconditionally enable this extension. Brian complained about the
ordering of names (alphabetical order) which is why I've added ANGLE at
the top of the enum...
>
> > diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> > index fc2ec62..2698110 100644
> > --- a/src/mapi/glapi/gen/es_EXT.xml
> > +++ b/src/mapi/glapi/gen/es_EXT.xml
> > @@ -731,4 +731,10 @@
> >
> >
> >
> > +
> > +
> > +
> > +
> > +
> > +
> >
> > diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
> > b/src/mesa/drivers/dri/intel/intel_extensions.c
> > index 89f6c1e..8a46488 100755
> > --- a/src/mesa/drivers/dri/intel/intel_extensions.c
> > +++ b/src/mesa/drivers/dri/intel/intel_extensions.c
> > @@ -182,6 +182,7 @@ intelInitExtensions(struct gl_context *ctx)
> > }
> >
> > if (intel->ctx.Mesa_DXTn) {
> > + ctx->Extensions.ANGLE_texture_compression_dxt = true;
> >ctx->Extensions.EXT_texture_compression_s3tc = true;
> >ctx->Extensions.S3_s3tc = true;
> > }
> > diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
> > index a65c5c5..c396952 100644
> > --- a/src/mesa/main/APIspec.xml
> > +++ b/src/mesa/main/APIspec.xml
> > @@ -2172,6 +2172,9 @@
> >
> >
> >
> > +
> > +
> > +
> >
> >
> >
> > diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> > index bd7c7ba..4971ebc 100644
> > --- a/src/mesa/main/extensions.c
> > +++ b/src/mesa/main/extensions.c
> > @@ -195,6 +195,8 @@ static const struct extension extension_table[] = {
> > { "GL_EXT_texture3D", o(EXT_texture3D),
> > GLL,1996 },
> > { "GL_EXT_texture_array", o(EXT_texture_array),
> > GL, 2006 },
> > { "GL_EXT_texture_compression_dxt1",
> > o(EXT_texture_compression_s3tc),GL | ES1 | ES2, 2004 },
> > + { "GL_ANGLE_texture_compression_dxt3",
> > o(ANGLE_texture_compression_dxt), ES2,2011 },
> > + { "GL_ANGLE_texture_compression_dxt5",
> > o(ANGLE_texture_compression_dxt), ES2,2011 },
> > { "GL_EXT_texture_compression_latc",
> > o(EXT_texture_compression_latc),GL, 2006 },
> > { "GL_EXT_texture_compression_rgtc",
> > o(ARB_texture_compression_rgtc),GL, 2004 },
> > { "GL_EXT_texture_compression_s3tc",
> > o(EXT_texture_compression_s3tc),GL, 2000 },
> > @@ -480,6 +482,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
> > ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
> > _mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
> > if (ctx->Mesa_DXTn) {
> > + ctx->Extensions.ANGLE_texture_compression_dxt = GL_TRUE;
> >_mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
> >_mesa_enable_extension(ctx, "GL_S3_s3tc");
> > }
> > diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> > index 04029c0..ccdf56b 100644
> > --- a/src/mesa/main/glformats.c
> > +++ b/src/mesa/main/glformats.c
> > @@ -791,8 +791,10 @@ _mesa_is_compressed_format(struct gl_context *ctx,
> > GLenum
Re: [Mesa-dev] [PATCH v4 1/1] intel: add support for ANGLE_texture_compression_dxt.
On Thu, Sep 27, 2012 at 07:28:47AM -0600, Brian Paul wrote:
> Looks good to me, Oliver.
>
> Reviewed-by: Brian Paul
Thanks Brian. Please also check Kenneth's comments and my reply; I'd
like your input there.
>
> One question below...
OK.
>
> On 09/27/2012 02:56 AM, Oliver McFadden wrote:
> > Signed-off-by: Oliver McFadden
> > ---
> > v4: Off-by-one on a couple of 'if (ctx->Mesa_DXTn)' lines, which could
> > cause a
> > crash.
> >
> > src/glx/glxextensions.h |3 ++-
> > src/mapi/glapi/gen/es_EXT.xml |6 ++
> > src/mesa/drivers/dri/intel/intel_extensions.c |1 +
> > src/mesa/main/APIspec.xml |3 +++
> > src/mesa/main/extensions.c|3 +++
> > src/mesa/main/glformats.c |6 --
> > src/mesa/main/glheader.h | 11 +++
> > src/mesa/main/mtypes.h|1 +
> > src/mesa/main/texformat.c |9 ++---
> > src/mesa/main/teximage.c | 10 ++
> > 10 files changed, 47 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
> > index 90c27a7..9e072e4 100644
> > --- a/src/glx/glxextensions.h
> > +++ b/src/glx/glxextensions.h
> > @@ -67,7 +67,8 @@ enum
> >
> > enum
> > {
> > - GL_ARB_depth_texture_bit = 0,
> > + GL_ANGLE_texture_compression_dxt_bit = 0,
> > + GL_ARB_depth_texture_bit,
> > GL_ARB_draw_buffers_bit,
> > GL_ARB_fragment_program_bit,
> > GL_ARB_fragment_program_shadow_bit,
> > diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> > index fc2ec62..2698110 100644
> > --- a/src/mapi/glapi/gen/es_EXT.xml
> > +++ b/src/mapi/glapi/gen/es_EXT.xml
> > @@ -731,4 +731,10 @@
> >
> >
> >
> > +
> > +
> > +
> > +
> > +
> > +
> >
> > diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
> > b/src/mesa/drivers/dri/intel/intel_extensions.c
> > index 89f6c1e..8a46488 100755
> > --- a/src/mesa/drivers/dri/intel/intel_extensions.c
> > +++ b/src/mesa/drivers/dri/intel/intel_extensions.c
> > @@ -182,6 +182,7 @@ intelInitExtensions(struct gl_context *ctx)
> > }
> >
> > if (intel->ctx.Mesa_DXTn) {
> > + ctx->Extensions.ANGLE_texture_compression_dxt = true;
> > ctx->Extensions.EXT_texture_compression_s3tc = true;
> > ctx->Extensions.S3_s3tc = true;
> > }
> > diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
> > index a65c5c5..c396952 100644
> > --- a/src/mesa/main/APIspec.xml
> > +++ b/src/mesa/main/APIspec.xml
> > @@ -2172,6 +2172,9 @@
> >
> >
> >
> > +
> > +
> > +
> >
> >
> >
> > diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> > index bd7c7ba..4971ebc 100644
> > --- a/src/mesa/main/extensions.c
> > +++ b/src/mesa/main/extensions.c
> > @@ -195,6 +195,8 @@ static const struct extension extension_table[] = {
> > { "GL_EXT_texture3D", o(EXT_texture3D),
> > GLL,1996 },
> > { "GL_EXT_texture_array", o(EXT_texture_array),
> > GL, 2006 },
> > { "GL_EXT_texture_compression_dxt1",
> > o(EXT_texture_compression_s3tc),GL | ES1 | ES2, 2004 },
> > + { "GL_ANGLE_texture_compression_dxt3",
> > o(ANGLE_texture_compression_dxt), ES2,2011 },
> > + { "GL_ANGLE_texture_compression_dxt5",
> > o(ANGLE_texture_compression_dxt), ES2,2011 },
> > { "GL_EXT_texture_compression_latc",
> > o(EXT_texture_compression_latc),GL, 2006 },
> > { "GL_EXT_texture_compression_rgtc",
> > o(ARB_texture_compression_rgtc),GL, 2004 },
> > { "GL_EXT_texture_compression_s3tc",
> > o(EXT_texture_compression_s3tc),GL, 2000 },
> > @@ -480,6 +482,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
> > ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
> > _mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
> > if (ctx->Mesa_DXTn) {
> > + ctx->Extensions.ANGLE_texture_compression_dxt = GL_TRUE;
> > _mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
> > _mesa_enable_extension(ctx, "GL_S3_s3tc");
> > }
> > diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> > index 04029c0..ccdf56b 100644
> > --- a/src/mesa/main/glformats.c
> > +++ b/src/mesa/main/glformats.c
> > @@ -791,8 +791,10 @@ _mesa_is_compressed_format(struct gl_context *ctx,
> > GLenum format)
> > return ctx->Extensions.EXT_texture_compression_s3tc;
> > case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
> > case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
> > - return _mesa_is_desktop_gl(ctx)
> > -&& ctx->Extensions.EXT_texture_
Re: [Mesa-dev] [PATCH v4 1/1] intel: add support for ANGLE_texture_compression_dxt.
On 09/28/2012 02:20 AM, Oliver McFadden wrote:
> On Fri, Sep 28, 2012 at 01:12:55AM -0700, Kenneth Graunke wrote:
>> On 09/27/2012 01:56 AM, Oliver McFadden wrote:
>>> Signed-off-by: Oliver McFadden
>>> ---
>>> v4: Off-by-one on a couple of 'if (ctx->Mesa_DXTn)' lines, which could
>>> cause a
>>> crash.
>>>
>>> src/glx/glxextensions.h |3 ++-
>>> src/mapi/glapi/gen/es_EXT.xml |6 ++
>>> src/mesa/drivers/dri/intel/intel_extensions.c |1 +
>>> src/mesa/main/APIspec.xml |3 +++
>>> src/mesa/main/extensions.c|3 +++
>>> src/mesa/main/glformats.c |6 --
>>> src/mesa/main/glheader.h | 11 +++
>>> src/mesa/main/mtypes.h|1 +
>>> src/mesa/main/texformat.c |9 ++---
>>> src/mesa/main/teximage.c | 10 ++
>>> 10 files changed, 47 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
>>> index 90c27a7..9e072e4 100644
>>> --- a/src/glx/glxextensions.h
>>> +++ b/src/glx/glxextensions.h
>>> @@ -67,7 +67,8 @@ enum
>>>
>>> enum
>>> {
>>> - GL_ARB_depth_texture_bit = 0,
>>> + GL_ANGLE_texture_compression_dxt_bit = 0,
>>> + GL_ARB_depth_texture_bit,
>>> GL_ARB_draw_buffers_bit,
>>> GL_ARB_fragment_program_bit,
>>> GL_ARB_fragment_program_shadow_bit,
>>
>> You shouldn't need to change GLX code to add a purely client-side
>> extension. I believe you can safely drop this hunk (and please do).
>
> I need ANGLE_texture_compression_dxt somewhere in the extension table,
> see src/mesa/main/extensions.c. Unfortunately it's not possible to
> unconditionally enable this extension. Brian complained about the
> ordering of names (alphabetical order) which is why I've added ANGLE at
> the top of the enum...
Yeah, but you already defined that bit (correctly) in struct
gl_extensions in mtypes.h. This one is just superfluous, as far as I
can tell.
[snip]
>>> diff --git a/src/mesa/main/glheader.h b/src/mesa/main/glheader.h
>>> index e93ca30..33cda02 100644
>>> --- a/src/mesa/main/glheader.h
>>> +++ b/src/mesa/main/glheader.h
>>> @@ -59,6 +59,17 @@ extern "C" {
>>> #endif
>>>
>>>
>>> +/* GL_ANGLE_texture_compression_dxt3 */
>>> +#ifndef GL_ANGLE_texture_compression_dxt3
>>> +#define GL_COMPRESSED_RGBA_S3TC_DXT3_ANGLE 0x83F2
>>> +#endif
>>> +
>>> +/* GL_ANGLE_texture_compression_dxt5 */
>>> +#ifndef GL_ANGLE_texture_compression_dxt5
>>> +#define GL_COMPRESSED_RGBA_S3TC_DXT5_ANGLE 0x83F3
>>> +#endif
>>
>> You can actually drop this hunk if you change the teximage.c code to use
>> the _EXT extension instead of the _ANGLE extension. The enums are
>> identical (just as the formats are identical). I'd prefer that.
>
> Hmm, okay. I'd like to leave a GL_COMPRESSED_RGBA_S3TC_DXT[35]_ANGLE
> comment there for grep, but it's not a show-stopper though...
I guess I don't feel too strongly about it one way or another.
>> Otherwise, this looks good! With those changes,
>> Reviewed-by: Kenneth Graunke
>
> I will also wait for Brian's comments on your suggestions and my replies
> before rolling another patch. I'll be happy to see this one done and
> pushed. :-)
Sounds good.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 1/1] intel: add support for ANGLE_texture_compression_dxt.
On Fri, Sep 28, 2012 at 02:29:12AM -0700, Kenneth Graunke wrote:
> On 09/28/2012 02:20 AM, Oliver McFadden wrote:
> > On Fri, Sep 28, 2012 at 01:12:55AM -0700, Kenneth Graunke wrote:
> >> On 09/27/2012 01:56 AM, Oliver McFadden wrote:
> >>> Signed-off-by: Oliver McFadden
> >>> ---
> >>> v4: Off-by-one on a couple of 'if (ctx->Mesa_DXTn)' lines, which could
> >>> cause a
> >>> crash.
> >>>
> >>> src/glx/glxextensions.h |3 ++-
> >>> src/mapi/glapi/gen/es_EXT.xml |6 ++
> >>> src/mesa/drivers/dri/intel/intel_extensions.c |1 +
> >>> src/mesa/main/APIspec.xml |3 +++
> >>> src/mesa/main/extensions.c|3 +++
> >>> src/mesa/main/glformats.c |6 --
> >>> src/mesa/main/glheader.h | 11 +++
> >>> src/mesa/main/mtypes.h|1 +
> >>> src/mesa/main/texformat.c |9 ++---
> >>> src/mesa/main/teximage.c | 10 ++
> >>> 10 files changed, 47 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
> >>> index 90c27a7..9e072e4 100644
> >>> --- a/src/glx/glxextensions.h
> >>> +++ b/src/glx/glxextensions.h
> >>> @@ -67,7 +67,8 @@ enum
> >>>
> >>> enum
> >>> {
> >>> - GL_ARB_depth_texture_bit = 0,
> >>> + GL_ANGLE_texture_compression_dxt_bit = 0,
> >>> + GL_ARB_depth_texture_bit,
> >>> GL_ARB_draw_buffers_bit,
> >>> GL_ARB_fragment_program_bit,
> >>> GL_ARB_fragment_program_shadow_bit,
> >>
> >> You shouldn't need to change GLX code to add a purely client-side
> >> extension. I believe you can safely drop this hunk (and please do).
> >
> > I need ANGLE_texture_compression_dxt somewhere in the extension table,
> > see src/mesa/main/extensions.c. Unfortunately it's not possible to
> > unconditionally enable this extension. Brian complained about the
> > ordering of names (alphabetical order) which is why I've added ANGLE at
> > the top of the enum...
>
> Yeah, but you already defined that bit (correctly) in struct
> gl_extensions in mtypes.h. This one is just superfluous, as far as I
> can tell.
Oh, yes. You're right; I haven't had my coffee this morning (nobody
check the actual time in EEST! ;-))
>
> [snip]
> >>> diff --git a/src/mesa/main/glheader.h b/src/mesa/main/glheader.h
> >>> index e93ca30..33cda02 100644
> >>> --- a/src/mesa/main/glheader.h
> >>> +++ b/src/mesa/main/glheader.h
> >>> @@ -59,6 +59,17 @@ extern "C" {
> >>> #endif
> >>>
> >>>
> >>> +/* GL_ANGLE_texture_compression_dxt3 */
> >>> +#ifndef GL_ANGLE_texture_compression_dxt3
> >>> +#define GL_COMPRESSED_RGBA_S3TC_DXT3_ANGLE 0x83F2
> >>> +#endif
> >>> +
> >>> +/* GL_ANGLE_texture_compression_dxt5 */
> >>> +#ifndef GL_ANGLE_texture_compression_dxt5
> >>> +#define GL_COMPRESSED_RGBA_S3TC_DXT5_ANGLE 0x83F3
> >>> +#endif
> >>
> >> You can actually drop this hunk if you change the teximage.c code to use
> >> the _EXT extension instead of the _ANGLE extension. The enums are
> >> identical (just as the formats are identical). I'd prefer that.
> >
> > Hmm, okay. I'd like to leave a GL_COMPRESSED_RGBA_S3TC_DXT[35]_ANGLE
> > comment there for grep, but it's not a show-stopper though...
>
> I guess I don't feel too strongly about it one way or another.
OK.
>
> >> Otherwise, this looks good! With those changes,
> >> Reviewed-by: Kenneth Graunke
> >
> > I will also wait for Brian's comments on your suggestions and my replies
> > before rolling another patch. I'll be happy to see this one done and
> > pushed. :-)
>
> Sounds good.
>
--
Oliver McFadden.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 1/1] intel: add support for ANGLE_texture_compression_dxt.
Signed-off-by: Oliver McFadden
---
v5: reuse the _EXT defines instead of defining new _ANGLE defines.
v5: removed unnessacary enum in glxextensions.h
src/mapi/glapi/gen/es_EXT.xml |6 ++
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
src/mesa/main/APIspec.xml |3 +++
src/mesa/main/extensions.c|3 +++
src/mesa/main/glformats.c |6 --
src/mesa/main/mtypes.h|1 +
src/mesa/main/texformat.c |9 ++---
src/mesa/main/teximage.c | 11 +++
8 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index fc2ec62..2698110 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -731,4 +731,10 @@
+
+
+
+
+
+
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
index 89f6c1e..8a46488 100755
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -182,6 +182,7 @@ intelInitExtensions(struct gl_context *ctx)
}
if (intel->ctx.Mesa_DXTn) {
+ ctx->Extensions.ANGLE_texture_compression_dxt = true;
ctx->Extensions.EXT_texture_compression_s3tc = true;
ctx->Extensions.S3_s3tc = true;
}
diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
index a65c5c5..c396952 100644
--- a/src/mesa/main/APIspec.xml
+++ b/src/mesa/main/APIspec.xml
@@ -2172,6 +2172,9 @@
+
+
+
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index bd7c7ba..4971ebc 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -195,6 +195,8 @@ static const struct extension extension_table[] = {
{ "GL_EXT_texture3D", o(EXT_texture3D),
GLL,1996 },
{ "GL_EXT_texture_array", o(EXT_texture_array),
GL, 2006 },
{ "GL_EXT_texture_compression_dxt1",
o(EXT_texture_compression_s3tc),GL | ES1 | ES2, 2004 },
+ { "GL_ANGLE_texture_compression_dxt3",
o(ANGLE_texture_compression_dxt), ES2,2011 },
+ { "GL_ANGLE_texture_compression_dxt5",
o(ANGLE_texture_compression_dxt), ES2,2011 },
{ "GL_EXT_texture_compression_latc",
o(EXT_texture_compression_latc),GL, 2006 },
{ "GL_EXT_texture_compression_rgtc",
o(ARB_texture_compression_rgtc),GL, 2004 },
{ "GL_EXT_texture_compression_s3tc",
o(EXT_texture_compression_s3tc),GL, 2000 },
@@ -480,6 +482,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
_mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
if (ctx->Mesa_DXTn) {
+ ctx->Extensions.ANGLE_texture_compression_dxt = GL_TRUE;
_mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
_mesa_enable_extension(ctx, "GL_S3_s3tc");
}
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 04029c0..ccdf56b 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -791,8 +791,10 @@ _mesa_is_compressed_format(struct gl_context *ctx, GLenum
format)
return ctx->Extensions.EXT_texture_compression_s3tc;
case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
- return _mesa_is_desktop_gl(ctx)
- && ctx->Extensions.EXT_texture_compression_s3tc;
+ return (_mesa_is_desktop_gl(ctx) &&
+ ctx->Extensions.EXT_texture_compression_s3tc) ||
+(ctx->API == API_OPENGLES2 &&
+ ctx->Extensions.ANGLE_texture_compression_dxt);
case GL_RGB_S3TC:
case GL_RGB4_S3TC:
case GL_RGBA_S3TC:
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index ba43e57..e790e18 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2946,6 +2946,7 @@ struct gl_extensions
GLboolean dummy; /* don't remove this! */
GLboolean dummy_true; /* Set true by _mesa_init_extensions(). */
GLboolean dummy_false; /* Set false by _mesa_init_extensions(). */
+ GLboolean ANGLE_texture_compression_dxt;
GLboolean ARB_ES2_compatibility;
GLboolean ARB_base_instance;
GLboolean ARB_blend_func_extended;
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index 17270ba..cc3687e 100644
--- a/src/mesa/main/texformat.c
+++ b/src/mesa/main/texformat.c
@@ -302,7 +302,8 @@ _mesa_choose_tex_format(struct gl_context *ctx, GLenum
target,
}
}
- if (ctx->Extensions.EXT_texture_compression_s3tc) {
+ if (ctx->Extensions.EXT_texture_compression_s3tc ||
+ ctx->Extensions.ANGLE
[Mesa-dev] [PATCH v2 1/1] intel: print performance debug messages to `logcat' on Android.
Split the perf_debug() messages into performance debugging information
which may be useful for application developers or driver developers.
Always print the information useful for application developers on the
Android platform.
Signed-off-by: Oliver McFadden
CC: Chad Versace
---
v2: Split perf_debug() into app/driver specific messages; try to only print
useful debug information to the application developer.
Chad, I'd like your opinion on whether I have split the app/driver messages
roughly correctly. Thanks!
src/mesa/drivers/dri/Android.mk |3 +-
src/mesa/drivers/dri/i965/brw_clear.c | 10
src/mesa/drivers/dri/i965/brw_draw.c |4 +-
src/mesa/drivers/dri/i965/brw_fs.cpp |8 +++---
src/mesa/drivers/dri/i965/brw_queryobj.c |2 +-
src/mesa/drivers/dri/i965/brw_state_cache.c |4 +-
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp |4 +-
src/mesa/drivers/dri/i965/brw_vs.c| 16 ++--
src/mesa/drivers/dri/i965/brw_wm.c| 16 ++--
src/mesa/drivers/dri/intel/intel_buffer_objects.c |6 ++--
src/mesa/drivers/dri/intel/intel_context.c|6 +
src/mesa/drivers/dri/intel/intel_context.h| 25 +---
src/mesa/drivers/dri/intel/intel_regions.c|2 +-
src/mesa/drivers/dri/intel/intel_tex_subimage.c |4 +-
14 files changed, 67 insertions(+), 43 deletions(-)
diff --git a/src/mesa/drivers/dri/Android.mk b/src/mesa/drivers/dri/Android.mk
index 577f664..d6196bb 100644
--- a/src/mesa/drivers/dri/Android.mk
+++ b/src/mesa/drivers/dri/Android.mk
@@ -34,7 +34,8 @@ MESA_DRI_MODULE_UNSTRIPPED_PATH :=
$(TARGET_OUT_SHARED_LIBRARIES_UNSTRIPPED)/dri
MESA_DRI_CFLAGS := \
-DFEATURE_GL=1 \
-DFEATURE_ES1=1 \
- -DFEATURE_ES2=1
+ -DFEATURE_ES2=1 \
+ -DHAVE_ANDROID_PLATFORM
MESA_DRI_C_INCLUDES := \
$(addprefix $(MESA_TOP)/, $(mesa_dri_common_INCLUDES)) \
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
b/src/mesa/drivers/dri/i965/brw_clear.c
index 53d8e54..722b0e2 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -120,8 +120,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
* first.
*/
if (ctx->Scissor.Enabled && !noop_scissor(ctx, fb)) {
- perf_debug("Failed to fast clear depth due to scissor being enabled. "
- "Possible 5%% performance win if avoided.\n");
+ perf_app_debug("Failed to fast clear depth due to scissor being enabled.
"
+ "Possible 5%% performance win if avoided.\n");
return false;
}
@@ -130,9 +130,9 @@ brw_fast_clear_depth(struct gl_context *ctx)
*/
if (mt->level[depth_irb->mt_level].width % 8 != 0 ||
mt->level[depth_irb->mt_level].height % 4 != 0) {
- perf_debug("Failed to fast clear depth due to width/height %d,%d not "
- "being aligned to 8,4. Possible 5%% performance win if "
- "avoided\n",
+ perf_app_debug("Failed to fast clear depth due to width/height %d,%d not "
+ "being aligned to 8,4. Possible 5%% performance win if "
+ "avoided\n",
mt->level[depth_irb->mt_level].width,
mt->level[depth_irb->mt_level].height);
return false;
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index a09f555..8597f61 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -574,8 +574,8 @@ void brw_draw_prims( struct gl_context *ctx,
* won't support all the extensions we support.
*/
if (ctx->RenderMode != GL_RENDER) {
- perf_debug("%s render mode not supported in hardware\n",
- _mesa_lookup_enum_by_nr(ctx->RenderMode));
+ perf_app_debug("%s render mode not supported in hardware\n",
+ _mesa_lookup_enum_by_nr(ctx->RenderMode));
_swsetup_Wakeup(ctx);
_tnl_wakeup(ctx);
_tnl_draw_prims(ctx, arrays, prim, nr_prims, ib, min_index, max_index);
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 9ac2a49..a59030e 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2101,8 +2101,8 @@ brw_wm_fs_emit(struct brw_context *brw, struct
brw_wm_compile *c,
fs_visitor v2(c, prog, shader);
v2.import_uniforms(&v);
if (!v2.run()) {
- perf_debug("16-wide shader failed to compile, falling back to "
-"8-wide at a 10-20%% performance cost: %s", v2.fail_msg);
+ perf_drv_debug("16-wide shader failed to compile, falling back to "
+ "8-wide at a 10-20%% performance cost: %s", v2.fail_msg);
}
}
@@ -2114,8 +2114,8 @@ brw_wm_fs_emit(struct brw_context *brw, struct
brw_wm_compile *c,
shader->compiled_once = true;
[Mesa-dev] [PATCH v3 1/1] intel: print performance debug messages to `logcat' on Android.
Split the perf_debug() messages into performance debugging information
which may be useful for application developers or driver developers.
Always print the information useful for application developers on the
Android platform.
Signed-off-by: Oliver McFadden
CC: Chad Versace
---
v3: forgot to change some DEBUG_PERF into (DEBUG_PERF | DEBUG_PERF_APP)
src/mesa/drivers/dri/Android.mk |3 +-
src/mesa/drivers/dri/i965/brw_clear.c | 10
src/mesa/drivers/dri/i965/brw_draw.c |4 +-
src/mesa/drivers/dri/i965/brw_fs.cpp | 12 +-
src/mesa/drivers/dri/i965/brw_queryobj.c |4 +-
src/mesa/drivers/dri/i965/brw_state_cache.c |4 +-
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp |8 +++---
src/mesa/drivers/dri/i965/brw_vs.c| 16 ++--
src/mesa/drivers/dri/i965/brw_wm.c| 16 ++--
src/mesa/drivers/dri/intel/intel_buffer_objects.c |8 +++---
src/mesa/drivers/dri/intel/intel_context.c|6 +
src/mesa/drivers/dri/intel/intel_context.h| 25 +---
src/mesa/drivers/dri/intel/intel_regions.c|2 +-
src/mesa/drivers/dri/intel/intel_tex_subimage.c |4 +-
14 files changed, 73 insertions(+), 49 deletions(-)
diff --git a/src/mesa/drivers/dri/Android.mk b/src/mesa/drivers/dri/Android.mk
index 577f664..d6196bb 100644
--- a/src/mesa/drivers/dri/Android.mk
+++ b/src/mesa/drivers/dri/Android.mk
@@ -34,7 +34,8 @@ MESA_DRI_MODULE_UNSTRIPPED_PATH :=
$(TARGET_OUT_SHARED_LIBRARIES_UNSTRIPPED)/dri
MESA_DRI_CFLAGS := \
-DFEATURE_GL=1 \
-DFEATURE_ES1=1 \
- -DFEATURE_ES2=1
+ -DFEATURE_ES2=1 \
+ -DHAVE_ANDROID_PLATFORM
MESA_DRI_C_INCLUDES := \
$(addprefix $(MESA_TOP)/, $(mesa_dri_common_INCLUDES)) \
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
b/src/mesa/drivers/dri/i965/brw_clear.c
index 53d8e54..722b0e2 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -120,8 +120,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
* first.
*/
if (ctx->Scissor.Enabled && !noop_scissor(ctx, fb)) {
- perf_debug("Failed to fast clear depth due to scissor being enabled. "
- "Possible 5%% performance win if avoided.\n");
+ perf_app_debug("Failed to fast clear depth due to scissor being enabled.
"
+ "Possible 5%% performance win if avoided.\n");
return false;
}
@@ -130,9 +130,9 @@ brw_fast_clear_depth(struct gl_context *ctx)
*/
if (mt->level[depth_irb->mt_level].width % 8 != 0 ||
mt->level[depth_irb->mt_level].height % 4 != 0) {
- perf_debug("Failed to fast clear depth due to width/height %d,%d not "
- "being aligned to 8,4. Possible 5%% performance win if "
- "avoided\n",
+ perf_app_debug("Failed to fast clear depth due to width/height %d,%d not "
+ "being aligned to 8,4. Possible 5%% performance win if "
+ "avoided\n",
mt->level[depth_irb->mt_level].width,
mt->level[depth_irb->mt_level].height);
return false;
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index a09f555..8597f61 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -574,8 +574,8 @@ void brw_draw_prims( struct gl_context *ctx,
* won't support all the extensions we support.
*/
if (ctx->RenderMode != GL_RENDER) {
- perf_debug("%s render mode not supported in hardware\n",
- _mesa_lookup_enum_by_nr(ctx->RenderMode));
+ perf_app_debug("%s render mode not supported in hardware\n",
+ _mesa_lookup_enum_by_nr(ctx->RenderMode));
_swsetup_Wakeup(ctx);
_tnl_wakeup(ctx);
_tnl_draw_prims(ctx, arrays, prim, nr_prims, ib, min_index, max_index);
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 9ac2a49..8e06fcb 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2064,7 +2064,7 @@ brw_wm_fs_emit(struct brw_context *brw, struct
brw_wm_compile *c,
if (!prog)
return false;
- if (unlikely(INTEL_DEBUG & DEBUG_PERF)) {
+ if (unlikely(INTEL_DEBUG & (DEBUG_PERF | DEBUG_PERF_APP))) {
start_busy = (intel->batch.last_bo &&
drm_intel_bo_busy(intel->batch.last_bo));
start_time = get_time();
@@ -2101,21 +2101,21 @@ brw_wm_fs_emit(struct brw_context *brw, struct
brw_wm_compile *c,
fs_visitor v2(c, prog, shader);
v2.import_uniforms(&v);
if (!v2.run()) {
- perf_debug("16-wide shader failed to compile, falling back to "
-"8-wide at a 10-20%% performance cost: %s", v2.fail_msg);
+ perf_drv_debug("16-wide shader failed to compile, falling back to "
+
Re: [Mesa-dev] Adding support for sRGB framebuffers to EGL
For DRI adding a __DRIdrawable sRGB gamma attribute appears to be the way to go. There's __DRI_ATTRIB_FRAMEBUFFER_SRGB_CAPABLE already for __DRIconfig which appears to be unused. That could be used for the capability flag. Implementing it in the gallium EGL backend seems more straightforward, once that actually works. The sorting of EGL_GAMMA_SRGB_BIT also has the desirable function that it prevents simple EGL applications using eglChooseConfig from grabbing the deepest buffer format available (which could easily be a slower 32 bpc floating point format), assuming sRGB support is available and limited to 8 bpc. On Thu, Sep 27, 2012 at 8:57 PM, John Kåre Alsaker wrote: > I failed to consider that premultiplied sRGB color channels can be > stored two ways. The friendly way, to_srgb_gamma(color * alpha) and > what applications actually use, to_srgb_gamma(color) * alpha. That > might affect this proposal. I don't think this has to involve EGL. > > On Thu, Sep 27, 2012 at 3:49 PM, Brian Paul wrote: >> Just some quick comments. >> >> I think the term "GAMMA" should be omitted. I'm no expert but I'm not sure >> that sRGB is strictly a gamma function. The GL_EXT_texture_sRGB spec says >> "The sRGB color space roughly corresponds to 2.2 gamma correction." Also, >> the term GAMMA doesn't appear in any of the existing GLenum values related >> to sRGB. > Only sRGB's gamma function is used and it is explicitly named so to > avoid confusion with the whole sRGB color space. > >> >> Therefore, I think EGL_GAMMA_SRGB_BIT should be just EGL_SRGB_BIT, >> EGL_GAMMA_LINEAR -> EGL_LINEAR, >> EGL_GAMMA_SRGB -> EGL_SRGB. >> >> For the query, you might use "COLOR_ENCODING" like >> GL_ARB_framebuffer_object. > You could use glGetFramebufferAttachmentParameter with > GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING to check if you got a sRGB > framebuffer, but you can't set it. > >> >> You could also take a look at >> http://www.opengl.org/registry/specs/EXT/framebuffer_sRGB.txt to see how >> this was handled for GLX and WGL. > This is done similarly with a capability flag in GLX/WGL, but with the > surface attribute moved into OpenGL (and it affects other > rendertargets). > >> >> -Brian >> >> >> >> On 09/26/2012 04:49 AM, John Kåre Alsaker wrote: >>> >>> EGL_GAMMA_SRGB_BIT should be changed to a boolean EGL config attribute >>> so it can be optionally sorted by eglChooseConfig. It should be sorted >>> after EGL_COLOR_BUFFER_TYPE and true values would be preferred. This >>> sorting should be optional and is done so compositing window managers >>> can sample the framebuffer as an sRGB texture. EGL_GAMMA_SRGB_BIT >>> could also optionally be disabled when the format is not supported as >>> an sRGB texture by the hardware. >>> >>> On Wed, Sep 26, 2012 at 10:19 AM, John Kåre Alsaker >>> wrote: The way this would interact with ARB_framebuffer_sRGB is that the EGL's surface EGL_GAMMA attribute would be ignored. If a EGL config has the EGL_GAMMA_SRGB_BIT, it is required to support sRGB for the default OpenGL framebuffer. On Tue, Sep 25, 2012 at 5:58 PM, John Kåre Alsaker wrote: > > Hello, > > I would like add support for sRGB framebuffers to EGL. Here are my > proposed changes to EGL: > > A new EGL_SURFACE_TYPE bit: > EGL_GAMMA_SRGB_BIT - This format supports sRGB framebuffers. This also > means that ARB_framebuffer_sRGB is supported for this format. > > New values: > EGL_GAMMA_LINEAR - The gamma is linear. > EGL_GAMMA_SRGB - The gamma is as defined by the sRGB standard. > > New EGL surface attribute: > EGL_GAMMA - The gamma of the surface's framebuffer. The default value > is EGL_GAMMA_LINEAR. > > When the surface's EGL_GAMMA attribute's value is EGL_GAMMA_SRGB and > this is supported by > the format, reads from this framebuffer will be converted from sRGB > gamma and writes will > be converted to sRGB gamma. This may not apply to all functions in the > client API. > > There may be something related to the ARB_framebuffer_sRGB extension > in EGL already, in > which case someone should link me to it. > > There's two assumptions behind this proposal. One is that you won't > support sRGB only > formats. The other is that linear gamma and sRGB gamma format support > is the same. > This means that window systems can't add a new linear gamma format > without adding an sRGB > format and the other way around. > > I'd like some comments on this proposal and tips on how it could be > implemented in the > mess that is DRI. > > Thanks, > John Kåre >>> >>> ___ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> >> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists
Re: [Mesa-dev] [PATCH v5 1/1] intel: add support for ANGLE_texture_compression_dxt.
On 09/28/2012 03:52 AM, Oliver McFadden wrote:
Signed-off-by: Oliver McFadden
---
v5: reuse the _EXT defines instead of defining new _ANGLE defines.
v5: removed unnessacary enum in glxextensions.h
"unnessacary"
src/mapi/glapi/gen/es_EXT.xml |6 ++
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
src/mesa/main/APIspec.xml |3 +++
src/mesa/main/extensions.c|3 +++
src/mesa/main/glformats.c |6 --
src/mesa/main/mtypes.h|1 +
src/mesa/main/texformat.c |9 ++---
src/mesa/main/teximage.c | 11 +++
8 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index fc2ec62..2698110 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -731,4 +731,10 @@
+
+
+
+
+
+
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
index 89f6c1e..8a46488 100755
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -182,6 +182,7 @@ intelInitExtensions(struct gl_context *ctx)
}
if (intel->ctx.Mesa_DXTn) {
+ ctx->Extensions.ANGLE_texture_compression_dxt = true;
ctx->Extensions.EXT_texture_compression_s3tc = true;
ctx->Extensions.S3_s3tc = true;
}
diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
index a65c5c5..c396952 100644
--- a/src/mesa/main/APIspec.xml
+++ b/src/mesa/main/APIspec.xml
@@ -2172,6 +2172,9 @@
+
+
+
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index bd7c7ba..4971ebc 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -195,6 +195,8 @@ static const struct extension extension_table[] = {
{ "GL_EXT_texture3D", o(EXT_texture3D),
GLL,1996 },
{ "GL_EXT_texture_array", o(EXT_texture_array),
GL, 2006 },
{ "GL_EXT_texture_compression_dxt1",
o(EXT_texture_compression_s3tc),GL | ES1 | ES2, 2004 },
+ { "GL_ANGLE_texture_compression_dxt3",
o(ANGLE_texture_compression_dxt), ES2,2011 },
+ { "GL_ANGLE_texture_compression_dxt5",
o(ANGLE_texture_compression_dxt), ES2,2011 },
{ "GL_EXT_texture_compression_latc",
o(EXT_texture_compression_latc),GL, 2006 },
{ "GL_EXT_texture_compression_rgtc",
o(ARB_texture_compression_rgtc),GL, 2004 },
{ "GL_EXT_texture_compression_s3tc",
o(EXT_texture_compression_s3tc),GL, 2000 },
@@ -480,6 +482,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
_mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
if (ctx->Mesa_DXTn) {
+ ctx->Extensions.ANGLE_texture_compression_dxt = GL_TRUE;
_mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
_mesa_enable_extension(ctx, "GL_S3_s3tc");
}
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 04029c0..ccdf56b 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -791,8 +791,10 @@ _mesa_is_compressed_format(struct gl_context *ctx, GLenum
format)
return ctx->Extensions.EXT_texture_compression_s3tc;
case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
- return _mesa_is_desktop_gl(ctx)
-&& ctx->Extensions.EXT_texture_compression_s3tc;
+ return (_mesa_is_desktop_gl(ctx)&&
+ ctx->Extensions.EXT_texture_compression_s3tc) ||
+(ctx->API == API_OPENGLES2&&
+ ctx->Extensions.ANGLE_texture_compression_dxt);
case GL_RGB_S3TC:
case GL_RGB4_S3TC:
case GL_RGBA_S3TC:
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index ba43e57..e790e18 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2946,6 +2946,7 @@ struct gl_extensions
GLboolean dummy; /* don't remove this! */
GLboolean dummy_true; /* Set true by _mesa_init_extensions(). */
GLboolean dummy_false; /* Set false by _mesa_init_extensions(). */
+ GLboolean ANGLE_texture_compression_dxt;
GLboolean ARB_ES2_compatibility;
GLboolean ARB_base_instance;
GLboolean ARB_blend_func_extended;
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index 17270ba..cc3687e 100644
--- a/src/mesa/main/texformat.c
+++ b/src/mesa/main/texformat.c
@@ -302,7 +302,8 @@ _mesa_choose_tex_format(struct gl_context *ctx, GLenum
target,
}
}
- if (ctx->Extensions.EXT_texture_compression_s3tc) {
Re: [Mesa-dev] [PATCH] scons: Disable build of assembly sources on Cygwin.
On 09/28/2012 12:35 AM, Vinson Lee wrote:
The assembly sources currently do not build on Cygwin.
Signed-off-by: Vinson Lee
---
src/mapi/glapi/SConscript |2 +-
src/mesa/SConscript |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/SConscript b/src/mapi/glapi/SConscript
index ad007a6..c336c25 100644
--- a/src/mapi/glapi/SConscript
+++ b/src/mapi/glapi/SConscript
@@ -48,7 +48,7 @@ for s in mapi_sources:
#
# Assembly sources
#
-if env['gcc'] and env['platform'] not in ('darwin', 'windows'):
+if env['gcc'] and env['platform'] not in ('cygwin', 'darwin', 'windows'):
GLAPI = '#src/mapi/glapi/'
if env['machine'] == 'x86':
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index dba75a2..9819082 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -371,7 +371,7 @@ if env['gles']:
#
# Assembly sources
#
-if env['gcc'] and env['platform'] not in ('darwin', 'windows'):
+if env['gcc'] and env['platform'] not in ('cygwin', 'darwin', 'windows'):
if env['machine'] == 'x86':
env.Append(CPPDEFINES = [
'USE_X86_ASM',
Looks OK to me.
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 1/1] intel: add support for ANGLE_texture_compression_dxt.
On 09/27/2012 05:41 PM, Ian Romanick wrote:
On 09/27/2012 06:28 AM, Brian Paul wrote:
Looks good to me, Oliver.
Reviewed-by: Brian Paul
One question below...
On 09/27/2012 02:56 AM, Oliver McFadden wrote:
Signed-off-by: Oliver McFadden
---
v4: Off-by-one on a couple of 'if (ctx->Mesa_DXTn)' lines, which could
cause a
crash.
src/glx/glxextensions.h | 3 ++-
src/mapi/glapi/gen/es_EXT.xml | 6 ++
src/mesa/drivers/dri/intel/intel_extensions.c | 1 +
src/mesa/main/APIspec.xml | 3 +++
src/mesa/main/extensions.c | 3 +++
src/mesa/main/glformats.c | 6 --
src/mesa/main/glheader.h | 11 +++
src/mesa/main/mtypes.h | 1 +
src/mesa/main/texformat.c | 9 ++---
src/mesa/main/teximage.c | 10 ++
10 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
index 90c27a7..9e072e4 100644
--- a/src/glx/glxextensions.h
+++ b/src/glx/glxextensions.h
@@ -67,7 +67,8 @@ enum
enum
{
- GL_ARB_depth_texture_bit = 0,
+ GL_ANGLE_texture_compression_dxt_bit = 0,
+ GL_ARB_depth_texture_bit,
GL_ARB_draw_buffers_bit,
GL_ARB_fragment_program_bit,
GL_ARB_fragment_program_shadow_bit,
diff --git a/src/mapi/glapi/gen/es_EXT.xml
b/src/mapi/glapi/gen/es_EXT.xml
index fc2ec62..2698110 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -731,4 +731,10 @@
+
+
+
+
+
+
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
index 89f6c1e..8a46488 100755
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -182,6 +182,7 @@ intelInitExtensions(struct gl_context *ctx)
}
if (intel->ctx.Mesa_DXTn) {
+ ctx->Extensions.ANGLE_texture_compression_dxt = true;
ctx->Extensions.EXT_texture_compression_s3tc = true;
ctx->Extensions.S3_s3tc = true;
}
diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
index a65c5c5..c396952 100644
--- a/src/mesa/main/APIspec.xml
+++ b/src/mesa/main/APIspec.xml
@@ -2172,6 +2172,9 @@
+
+
+
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index bd7c7ba..4971ebc 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -195,6 +195,8 @@ static const struct extension extension_table[]
= {
{ "GL_EXT_texture3D",
o(EXT_texture3D), GLL, 1996 },
{ "GL_EXT_texture_array",
o(EXT_texture_array), GL, 2006 },
{ "GL_EXT_texture_compression_dxt1",
o(EXT_texture_compression_s3tc), GL | ES1 | ES2, 2004 },
+ { "GL_ANGLE_texture_compression_dxt3",
o(ANGLE_texture_compression_dxt), ES2, 2011 },
+ { "GL_ANGLE_texture_compression_dxt5",
o(ANGLE_texture_compression_dxt), ES2, 2011 },
{ "GL_EXT_texture_compression_latc",
o(EXT_texture_compression_latc), GL, 2006 },
{ "GL_EXT_texture_compression_rgtc",
o(ARB_texture_compression_rgtc), GL, 2004 },
{ "GL_EXT_texture_compression_s3tc",
o(EXT_texture_compression_s3tc), GL, 2000 },
@@ -480,6 +482,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
_mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
if (ctx->Mesa_DXTn) {
+ ctx->Extensions.ANGLE_texture_compression_dxt = GL_TRUE;
_mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
_mesa_enable_extension(ctx, "GL_S3_s3tc");
}
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 04029c0..ccdf56b 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -791,8 +791,10 @@ _mesa_is_compressed_format(struct gl_context
*ctx, GLenum format)
return ctx->Extensions.EXT_texture_compression_s3tc;
case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
- return _mesa_is_desktop_gl(ctx)
-&& ctx->Extensions.EXT_texture_compression_s3tc;
+ return (_mesa_is_desktop_gl(ctx)&&
+ ctx->Extensions.EXT_texture_compression_s3tc) ||
+ (ctx->API == API_OPENGLES2&&
+ ctx->Extensions.ANGLE_texture_compression_dxt);
If an extension like this is marked as being "ES2" in extensions.c why
do we need to check ctx->API==API_OPENGLES2? It seems to me that we
should only have to test ctx->Extensions.ANGLE_texture_compression_dxt
and not the API (as you did in the _mesa_choose_tex_format() change).
The controls in extensions.c only select whether or not the string is
advertised to the application. It doesn't control whether or not the
driver sets the flag in gl_context::Extensions. I can imagine a driver
always setting the ANGLE flags but not the EXT flags.
We could easily write a function that loops over the extension list
and disabled those which aren't applicable to the context's API. It
would be called after the driver's done enabling its extensions.
This would have several benefits:
1. Simplified feature checks. Instead of writing "if
(ctx->Extensions.FOO_bar && API==something)" it would just be "if
(ctx->Extensions.FOO_bar)". Quicker to write, easier to read, less
error-prone, etc. There's lots of places where we're checking the
Extensions flags, but not the API
Re: [Mesa-dev] [PATCH v5 1/1] intel: add support for ANGLE_texture_compression_dxt.
On Fri, Sep 28, 2012 at 07:54:14AM -0600, Brian Paul wrote:
> On 09/28/2012 03:52 AM, Oliver McFadden wrote:
> > Signed-off-by: Oliver McFadden
> > ---
> > v5: reuse the _EXT defines instead of defining new _ANGLE defines.
> > v5: removed unnessacary enum in glxextensions.h
>
> "unnessacary"
Oops. Unnecessary.
>
>
> >
> > src/mapi/glapi/gen/es_EXT.xml |6 ++
> > src/mesa/drivers/dri/intel/intel_extensions.c |1 +
> > src/mesa/main/APIspec.xml |3 +++
> > src/mesa/main/extensions.c|3 +++
> > src/mesa/main/glformats.c |6 --
> > src/mesa/main/mtypes.h|1 +
> > src/mesa/main/texformat.c |9 ++---
> > src/mesa/main/teximage.c | 11 +++
> > 8 files changed, 35 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> > index fc2ec62..2698110 100644
> > --- a/src/mapi/glapi/gen/es_EXT.xml
> > +++ b/src/mapi/glapi/gen/es_EXT.xml
> > @@ -731,4 +731,10 @@
> >
> >
> >
> > +
> > +
> > +
> > +
> > +
> > +
> >
> > diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
> > b/src/mesa/drivers/dri/intel/intel_extensions.c
> > index 89f6c1e..8a46488 100755
> > --- a/src/mesa/drivers/dri/intel/intel_extensions.c
> > +++ b/src/mesa/drivers/dri/intel/intel_extensions.c
> > @@ -182,6 +182,7 @@ intelInitExtensions(struct gl_context *ctx)
> > }
> >
> > if (intel->ctx.Mesa_DXTn) {
> > + ctx->Extensions.ANGLE_texture_compression_dxt = true;
> > ctx->Extensions.EXT_texture_compression_s3tc = true;
> > ctx->Extensions.S3_s3tc = true;
> > }
> > diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
> > index a65c5c5..c396952 100644
> > --- a/src/mesa/main/APIspec.xml
> > +++ b/src/mesa/main/APIspec.xml
> > @@ -2172,6 +2172,9 @@
> >
> >
> >
> > +
> > +
> > +
> >
> >
> >
> > diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> > index bd7c7ba..4971ebc 100644
> > --- a/src/mesa/main/extensions.c
> > +++ b/src/mesa/main/extensions.c
> > @@ -195,6 +195,8 @@ static const struct extension extension_table[] = {
> > { "GL_EXT_texture3D", o(EXT_texture3D),
> > GLL,1996 },
> > { "GL_EXT_texture_array", o(EXT_texture_array),
> > GL, 2006 },
> > { "GL_EXT_texture_compression_dxt1",
> > o(EXT_texture_compression_s3tc),GL | ES1 | ES2, 2004 },
> > + { "GL_ANGLE_texture_compression_dxt3",
> > o(ANGLE_texture_compression_dxt), ES2,2011 },
> > + { "GL_ANGLE_texture_compression_dxt5",
> > o(ANGLE_texture_compression_dxt), ES2,2011 },
> > { "GL_EXT_texture_compression_latc",
> > o(EXT_texture_compression_latc),GL, 2006 },
> > { "GL_EXT_texture_compression_rgtc",
> > o(ARB_texture_compression_rgtc),GL, 2004 },
> > { "GL_EXT_texture_compression_s3tc",
> > o(EXT_texture_compression_s3tc),GL, 2000 },
> > @@ -480,6 +482,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
> > ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
> > _mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
> > if (ctx->Mesa_DXTn) {
> > + ctx->Extensions.ANGLE_texture_compression_dxt = GL_TRUE;
> > _mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
> > _mesa_enable_extension(ctx, "GL_S3_s3tc");
> > }
> > diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> > index 04029c0..ccdf56b 100644
> > --- a/src/mesa/main/glformats.c
> > +++ b/src/mesa/main/glformats.c
> > @@ -791,8 +791,10 @@ _mesa_is_compressed_format(struct gl_context *ctx,
> > GLenum format)
> > return ctx->Extensions.EXT_texture_compression_s3tc;
> > case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
> > case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
> > - return _mesa_is_desktop_gl(ctx)
> > -&& ctx->Extensions.EXT_texture_compression_s3tc;
> > + return (_mesa_is_desktop_gl(ctx)&&
> > + ctx->Extensions.EXT_texture_compression_s3tc) ||
> > +(ctx->API == API_OPENGLES2&&
> > + ctx->Extensions.ANGLE_texture_compression_dxt);
> > case GL_RGB_S3TC:
> > case GL_RGB4_S3TC:
> > case GL_RGBA_S3TC:
> > diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> > index ba43e57..e790e18 100644
> > --- a/src/mesa/main/mtypes.h
> > +++ b/src/mesa/main/mtypes.h
> > @@ -2946,6 +2946,7 @@ struct gl_extensions
> > GLboolean dummy; /* don't remove this! */
> > GLboolean dummy_true; /* Set true by _mesa_init_extensions(). */
> > GLboolean dummy_false; /* Set false by _mesa_ini
Re: [Mesa-dev] [PATCH v4 1/1] intel: add support for ANGLE_texture_compression_dxt.
On Fri, Sep 28, 2012 at 08:14:29AM -0600, Brian Paul wrote:
> On 09/27/2012 05:41 PM, Ian Romanick wrote:
> > On 09/27/2012 06:28 AM, Brian Paul wrote:
> >> Looks good to me, Oliver.
> >>
> >> Reviewed-by: Brian Paul
> >>
> >> One question below...
> >>
> >> On 09/27/2012 02:56 AM, Oliver McFadden wrote:
> >>> Signed-off-by: Oliver McFadden
> >>> ---
> >>> v4: Off-by-one on a couple of 'if (ctx->Mesa_DXTn)' lines, which could
> >>> cause a
> >>> crash.
> >>>
> >>> src/glx/glxextensions.h | 3 ++-
> >>> src/mapi/glapi/gen/es_EXT.xml | 6 ++
> >>> src/mesa/drivers/dri/intel/intel_extensions.c | 1 +
> >>> src/mesa/main/APIspec.xml | 3 +++
> >>> src/mesa/main/extensions.c | 3 +++
> >>> src/mesa/main/glformats.c | 6 --
> >>> src/mesa/main/glheader.h | 11 +++
> >>> src/mesa/main/mtypes.h | 1 +
> >>> src/mesa/main/texformat.c | 9 ++---
> >>> src/mesa/main/teximage.c | 10 ++
> >>> 10 files changed, 47 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/src/glx/glxextensions.h b/src/glx/glxextensions.h
> >>> index 90c27a7..9e072e4 100644
> >>> --- a/src/glx/glxextensions.h
> >>> +++ b/src/glx/glxextensions.h
> >>> @@ -67,7 +67,8 @@ enum
> >>>
> >>> enum
> >>> {
> >>> - GL_ARB_depth_texture_bit = 0,
> >>> + GL_ANGLE_texture_compression_dxt_bit = 0,
> >>> + GL_ARB_depth_texture_bit,
> >>> GL_ARB_draw_buffers_bit,
> >>> GL_ARB_fragment_program_bit,
> >>> GL_ARB_fragment_program_shadow_bit,
> >>> diff --git a/src/mapi/glapi/gen/es_EXT.xml
> >>> b/src/mapi/glapi/gen/es_EXT.xml
> >>> index fc2ec62..2698110 100644
> >>> --- a/src/mapi/glapi/gen/es_EXT.xml
> >>> +++ b/src/mapi/glapi/gen/es_EXT.xml
> >>> @@ -731,4 +731,10 @@
> >>> >>> value="0x822B"/>
> >>>
> >>>
> >>> +
> >>> +
> >>> +
> >>> +
> >>> +
> >>> +
> >>>
> >>> diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
> >>> b/src/mesa/drivers/dri/intel/intel_extensions.c
> >>> index 89f6c1e..8a46488 100755
> >>> --- a/src/mesa/drivers/dri/intel/intel_extensions.c
> >>> +++ b/src/mesa/drivers/dri/intel/intel_extensions.c
> >>> @@ -182,6 +182,7 @@ intelInitExtensions(struct gl_context *ctx)
> >>> }
> >>>
> >>> if (intel->ctx.Mesa_DXTn) {
> >>> + ctx->Extensions.ANGLE_texture_compression_dxt = true;
> >>> ctx->Extensions.EXT_texture_compression_s3tc = true;
> >>> ctx->Extensions.S3_s3tc = true;
> >>> }
> >>> diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
> >>> index a65c5c5..c396952 100644
> >>> --- a/src/mesa/main/APIspec.xml
> >>> +++ b/src/mesa/main/APIspec.xml
> >>> @@ -2172,6 +2172,9 @@
> >>>
> >>>
> >>>
> >>> +
> >>> +
> >>> +
> >>>
> >>>
> >>>
> >>> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> >>> index bd7c7ba..4971ebc 100644
> >>> --- a/src/mesa/main/extensions.c
> >>> +++ b/src/mesa/main/extensions.c
> >>> @@ -195,6 +195,8 @@ static const struct extension extension_table[]
> >>> = {
> >>> { "GL_EXT_texture3D",
> >>> o(EXT_texture3D), GLL, 1996 },
> >>> { "GL_EXT_texture_array",
> >>> o(EXT_texture_array), GL, 2006 },
> >>> { "GL_EXT_texture_compression_dxt1",
> >>> o(EXT_texture_compression_s3tc), GL | ES1 | ES2, 2004 },
> >>> + { "GL_ANGLE_texture_compression_dxt3",
> >>> o(ANGLE_texture_compression_dxt), ES2, 2011 },
> >>> + { "GL_ANGLE_texture_compression_dxt5",
> >>> o(ANGLE_texture_compression_dxt), ES2, 2011 },
> >>> { "GL_EXT_texture_compression_latc",
> >>> o(EXT_texture_compression_latc), GL, 2006 },
> >>> { "GL_EXT_texture_compression_rgtc",
> >>> o(ARB_texture_compression_rgtc), GL, 2004 },
> >>> { "GL_EXT_texture_compression_s3tc",
> >>> o(EXT_texture_compression_s3tc), GL, 2000 },
> >>> @@ -480,6 +482,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
> >>> ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
> >>> _mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
> >>> if (ctx->Mesa_DXTn) {
> >>> + ctx->Extensions.ANGLE_texture_compression_dxt = GL_TRUE;
> >>> _mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
> >>> _mesa_enable_extension(ctx, "GL_S3_s3tc");
> >>> }
> >>> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> >>> index 04029c0..ccdf56b 100644
> >>> --- a/src/mesa/main/glformats.c
> >>> +++ b/src/mesa/main/glformats.c
> >>> @@ -791,8 +791,10 @@ _mesa_is_compressed_format(struct gl_context
> >>> *ctx, GLenum format)
> >>> return ctx->Extensions.EXT_texture_compression_s3tc;
> >>> case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
> >>> case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
> >>> - return _mesa_is_desktop_gl(ctx)
> >>> -&& ctx->Extensions.EXT_texture_compression_s3tc;
> >>> + return (_mesa_is_desktop_gl(ctx)&&
> >>> + ctx->Extensions.EXT_texture_compression_s3tc) ||
> >>> + (ctx->API == API_OPENGLES2&&
> >>> + ctx->Extensions.ANGLE_texture_compression_dxt);
> >>
> >> If an extension like this is marked as being "ES2" in extensions.c why
> >> do we need to check ctx->API==API_OPENGLES2? It seems to me that we
> >> should only have to test ctx->Extensions.ANGLE_texture_compression_dxt
> >> and not the API (as
Re: [Mesa-dev] [PATCH v5 1/1] intel: add support for ANGLE_texture_compression_dxt.
On 09/28/2012 08:24 AM, Oliver McFadden wrote:
On Fri, Sep 28, 2012 at 07:54:14AM -0600, Brian Paul wrote:
On 09/28/2012 03:52 AM, Oliver McFadden wrote:
Signed-off-by: Oliver McFadden
---
v5: reuse the _EXT defines instead of defining new _ANGLE defines.
v5: removed unnessacary enum in glxextensions.h
"unnessacary"
Oops. Unnecessary.
src/mapi/glapi/gen/es_EXT.xml |6 ++
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
src/mesa/main/APIspec.xml |3 +++
src/mesa/main/extensions.c|3 +++
src/mesa/main/glformats.c |6 --
src/mesa/main/mtypes.h|1 +
src/mesa/main/texformat.c |9 ++---
src/mesa/main/teximage.c | 11 +++
8 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index fc2ec62..2698110 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -731,4 +731,10 @@
+
+
+
+
+
+
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
index 89f6c1e..8a46488 100755
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -182,6 +182,7 @@ intelInitExtensions(struct gl_context *ctx)
}
if (intel->ctx.Mesa_DXTn) {
+ ctx->Extensions.ANGLE_texture_compression_dxt = true;
ctx->Extensions.EXT_texture_compression_s3tc = true;
ctx->Extensions.S3_s3tc = true;
}
diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
index a65c5c5..c396952 100644
--- a/src/mesa/main/APIspec.xml
+++ b/src/mesa/main/APIspec.xml
@@ -2172,6 +2172,9 @@
+
+
+
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index bd7c7ba..4971ebc 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -195,6 +195,8 @@ static const struct extension extension_table[] = {
{ "GL_EXT_texture3D", o(EXT_texture3D),
GLL,1996 },
{ "GL_EXT_texture_array", o(EXT_texture_array),
GL, 2006 },
{ "GL_EXT_texture_compression_dxt1",
o(EXT_texture_compression_s3tc),GL | ES1 | ES2, 2004 },
+ { "GL_ANGLE_texture_compression_dxt3",
o(ANGLE_texture_compression_dxt), ES2,2011 },
+ { "GL_ANGLE_texture_compression_dxt5",
o(ANGLE_texture_compression_dxt), ES2,2011 },
{ "GL_EXT_texture_compression_latc",
o(EXT_texture_compression_latc),GL, 2006 },
{ "GL_EXT_texture_compression_rgtc",
o(ARB_texture_compression_rgtc),GL, 2004 },
{ "GL_EXT_texture_compression_s3tc",
o(EXT_texture_compression_s3tc),GL, 2000 },
@@ -480,6 +482,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx)
ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE;
_mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
if (ctx->Mesa_DXTn) {
+ ctx->Extensions.ANGLE_texture_compression_dxt = GL_TRUE;
_mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
_mesa_enable_extension(ctx, "GL_S3_s3tc");
}
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 04029c0..ccdf56b 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -791,8 +791,10 @@ _mesa_is_compressed_format(struct gl_context *ctx, GLenum
format)
return ctx->Extensions.EXT_texture_compression_s3tc;
case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
- return _mesa_is_desktop_gl(ctx)
-&& ctx->Extensions.EXT_texture_compression_s3tc;
+ return (_mesa_is_desktop_gl(ctx)&&
+ ctx->Extensions.EXT_texture_compression_s3tc) ||
+(ctx->API == API_OPENGLES2&&
+ ctx->Extensions.ANGLE_texture_compression_dxt);
case GL_RGB_S3TC:
case GL_RGB4_S3TC:
case GL_RGBA_S3TC:
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index ba43e57..e790e18 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2946,6 +2946,7 @@ struct gl_extensions
GLboolean dummy; /* don't remove this! */
GLboolean dummy_true; /* Set true by _mesa_init_extensions(). */
GLboolean dummy_false; /* Set false by _mesa_init_extensions(). */
+ GLboolean ANGLE_texture_compression_dxt;
GLboolean ARB_ES2_compatibility;
GLboolean ARB_base_instance;
GLboolean ARB_blend_func_extended;
diff --git a/src/mesa/main/texformat.c b/src/mesa/main/texformat.c
index 17270ba..cc3687e 100644
--- a/src/mesa/main/texformat.c
+++ b/src/mesa
Re: [Mesa-dev] [PATCH v4 1/1] intel: add support for ANGLE_texture_compression_dxt.
On 09/28/2012 07:14 AM, Brian Paul wrote: On 09/27/2012 05:41 PM, Ian Romanick wrote: On 09/27/2012 06:28 AM, Brian Paul wrote: If an extension like this is marked as being "ES2" in extensions.c why do we need to check ctx->API==API_OPENGLES2? It seems to me that we should only have to test ctx->Extensions.ANGLE_texture_compression_dxt and not the API (as you did in the _mesa_choose_tex_format() change). The controls in extensions.c only select whether or not the string is advertised to the application. It doesn't control whether or not the driver sets the flag in gl_context::Extensions. I can imagine a driver always setting the ANGLE flags but not the EXT flags. We could easily write a function that loops over the extension list and disabled those which aren't applicable to the context's API. It would be called after the driver's done enabling its extensions. The problem is that some of this functionality is used internally whether or not the API can expose it. Awhile ago some of the Intel guys and I had a related discussion around the GLES3 run-up at SIGGRAPH. We discussed having gl_context::Extensions that the driver sets and a separate gl_context::_Extensions that is the subset available in the current API. The former could be checked for internal uses, the latter could be checked in application-facing code. There was some reason that we didn't pursue this at the time, but I don't recall what it was. Paul, do you remember? This would have several benefits: 1. Simplified feature checks. Instead of writing "if (ctx->Extensions.FOO_bar && API==something)" it would just be "if (ctx->Extensions.FOO_bar)". Quicker to write, easier to read, less error-prone, etc. There's lots of places where we're checking the Extensions flags, but not the API versions. Adding API checks (for ES in particular) would be a lot of churn. I know you've done some of that already. 2. If an existing extension is made available on a new API, we could make the change with a single line of code (change the API flags in the extension_table[] array). We already mostly have that. The problem with this new extension is that it's a subset of an existing extension. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 21979] glBlendEquationSeparate not exported in linux-x86 builds
https://bugs.freedesktop.org/show_bug.cgi?id=21979 --- Comment #6 from Ian Romanick --- So... there actually was no bug before. glBlendEquationSeparate isn't part of the ABI, so it's not supposed to be exported! Applications are required to use glXGetProcAddress to access these functions. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/7] i965: Don't spill "smeared" registers.
On 27 September 2012 16:56, Eric Anholt wrote:
> Paul Berry writes:
>
> > On 19 September 2012 13:28, Kenneth Graunke
> wrote:
> >> diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
> >> b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
> >> index e7f11ae..a819ae0 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
> >> +++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
> >> @@ -317,11 +317,19 @@ fs_visitor::choose_spill_reg(struct ra_graph *g)
> >>for (unsigned int i = 0; i < 3; i++) {
> >> if (inst->src[i].file == GRF) {
> >> spill_costs[inst->src[i].reg] += loop_scale;
> >> +
> >> +if (inst->src[i].smear >= 0) {
> >> + no_spill[inst->src[i].reg] = true;
> >> +}
> >>
> >
> > Can we add a comment above the if statement to alert people to why we
> can't
> > spill these registers (and why it's ok that we can't)? Perhaps something
> > like: "Register spilling logic assumes full-width registers; smeared
> > registers have a width of 1 so if we try to spill them we'll generate
> > invalid assembly. This shouldn't be a problem because smeared registers
> > are only used as short-term temporaries when loading pull constants, so
> > spilling them is unlikely to reduce register pressure anyhow."
> >
> > I guess I shouldn't give this patch my "Reviewed-by" since I originated
> it,
> > but assuming a comment is added, feel free to add:
>
> Yeah, that makes me scared that our spilling choices are bogus. I've
> been worried about that -- on LM when I reduced the number of registers
> used in its spilling shader, I got more spills happening, on some things
> that looked like poor choices. I did re-review the code, and didn't
> find anything at the time.
>
>
I am so glad you brought this up, because it led me to re-read through our
register spilling code and I think I see a big bug in it.
The problem is that a lot of registers don't contribute to register
pressure at all (because they are trivially allocatable)--these are the
nodes that register allocation was able to remove from the interference
graph before it gave up. There's no benefit to spilling these registers,
since they're not in the part of the interference graph that's uncolorable.
We'll just have to loop around, discover that the graph is still
uncolorable, and try again.
This explains why we were so frequently trying to spill these "smeared"
registers in the first place: their spilling cost is really low since they
are read and written exactly once. It also may help explain why when we
have to spill, we wind up spilling so many registers: because we spill all
of the low-cost zero-benefit registers before we get around to finding the
few moderate-cost high-benefit registers that are actually worth spilling.
I think the fix should be pretty straightforward: just have
ra_get_best_spill_node() skip registers for which in_stack is GL_TRUE. If
you look at the paper our register allocator is based on ("Retargetable
Graph-Coloring Register Allocation for Irregular Architectures") this is
what they suggest, albeit subtly. From page 8 of that paper:
"4. Spill is invoked if Simplify fails to remove all nodes in the
graph. It picks one of the *remaining* nodes to spill, and inserts a load
before each use of the variable, and a store after each definition."
(emphasis mine)
I'll try this later today and see if it has any benefit.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52435] Classic DRI drivers fail to install when libdricore8.1.0.so isn't already in the system
https://bugs.freedesktop.org/show_bug.cgi?id=52435 --- Comment #6 from Ian Romanick --- >From the original filing date, I assume this also occurs on the 9.0 release branch? If so, this sounds like a release blocker... -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i915: Don't leave dangling pointer to i915 context on failure
On 09/27/2012 10:33 AM, Eric Anholt wrote: Ian Romanick writes: From: Ian Romanick Otherwise intelDestroyContext would try to dereference the pointer to freed memory. Does DestroyContext get called out of all these error paths? If so, why not just remove our freeing? That's a fair point. It also looks like the free in brwCreateContext is bogus. The structure is allocated with rzalloc, but it's freed with free. :( ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] i965: Allow fast depth clears if scissoring doesn't do anything.
On 09/19/2012 01:27 PM, Kenneth Graunke wrote:
A game we're working with leaves scissoring enabled, but frequently sets
the scissor rectangle to the size of the whole screen. In that case,
scissoring has no effect, so it's safe to go ahead with a fast clear.
Chad believe this should help with Oliver McFadden's "Dante" as well.
v2/Chad: Use the drawbuffer dimensions rather than the miptree slice
dimensions. The miptree slice may be slightly larger due to alignment
restrictions.
There was some question of whether this actually gave any performance
improvement or just made the INTEL_DEBUG=perf warning go away. Can we
see any actual performance delta in Dante?
Signed-off-by: Kenneth Graunke
Signed-off-by: Chad Versace
Cc: Oliver McFadden
---
src/mesa/drivers/dri/i965/brw_clear.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
b/src/mesa/drivers/dri/i965/brw_clear.c
index c3c75df..625cc85 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -77,6 +77,18 @@ debug_mask(const char *name, GLbitfield mask)
}
/**
+ * Returns true if the scissor is a noop (cuts out nothing).
+ */
+static bool
+noop_scissor(struct gl_context *ctx, struct gl_framebuffer *fb)
+{
+ return ctx->Scissor.X <= 0 &&
+ ctx->Scissor.Y <= 0 &&
+ ctx->Scissor.Width >= fb->Width &&
+ ctx->Scissor.Height >= fb->Height;
+}
+
+/**
* Implements fast depth clears on gen6+.
*
* Fast clears basically work by setting a flag in each of the subspans
@@ -110,7 +122,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
* a previous clear had happened at a different clear value and resolve it
* first.
*/
- if (ctx->Scissor.Enabled) {
+ if (ctx->Scissor.Enabled && !noop_scissor(ctx, fb)) {
perf_debug("Failed to fast clear depth due to scissor being enabled. "
"Possible 5%% performance win if avoided.\n");
return false;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] FOSDEM2013: DevRoom or not?
On Fri, Sep 21, 2012 at 11:35:12AM +0200, Luc Verhaegen wrote: > On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote: > > Hi, > > > > The FOSDEM organizers have sent out a call for devrooms. FOSDEM this > > year is on the weekend of the 2nd and 3rd of February 2013. > > > > After the success of this formula last year, where, for the first time > > ever, we had a properly filled devroom schedule when the deadline hit, i > > am going to re-apply the same formula: > > * By the 28th of september, i need 6 committed speakers, otherwise i > > will not apply for a DevRoom. 6 people need to apply for a talk slot > > who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. > > This "definitely" means: > > * Don't knowingly plan anything else for this weekend. > > * Come to FOSDEM even if your corporation does not fund you (though > > feel free to contact the board individually for funding) > > * Make sure that you are allowed to travel to the shengen area in > > february. > > * Catastrophies excluded of course. Such catastrophies include > > things like train-derailments and such, but explicitely excludes > > hangovers :p > > * Scheduling based on timeliness of application: the earlier you apply, > > the better slot you get. > > * FOSDEMs final deadline for the full schedule is likely around 15th of > > january 2013. But do not count on that deadline, we will only do > > hourly slots, to keep people from running around between devrooms like > > headless chickens. Only 12-16 slots will be available, first come, > > first serve. > > > > I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 > > > > I hope we get a nice devroom like we had last time. That new building we > > were in was really amazing, even though it took a while before all > > FOSDEM visitors found it. > > > > Thanks, > > > > Luc Verhaegen. > > Just a heads up guys, we have a week left and not a single speaker yet! > > Given the timing of XDC and the FOSDEM deadines, this is not too > surprising, but still, with XDC2012 in its final day it is high time > that we start thinking about FOSDEM. I will later on shout at people > here in the room too :) > > All we need now is people who will definitely come to FOSDEM, and who > are willing to talk in the DevRoom. If a vague idea of a topic is > already known, then great, but this is not necessary yet. I now put up a > preliminary wiki page at wiki.x.org/wiki/fosdem2013, add yourself to the > list there. > > Thanks, > > Luc Verhaegen. Final reminder: the deadline is tonight. So far there are three speakers who lined up, and my feeling is that Matthieu and Marc lined up just so that the deadline and requirement will be met. So only a single person is intending to come to fosdem and has a topic he wants to talk about. Come on guys. Surely we can do better than that. Luc Verhaegen. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] dri_util: Use calloc to allocate __DRIcontext
From: Ian Romanick
The __DRIcontext contains some pointers, and some drivers check for them to be
NULL in some failure paths. Instead of sprinkling NULL assignments across the
various drivers, just zero out the whole thing.
NOTE: This is a candidate for the 9.0 branch.
Signed-off-by: Ian Romanick
Reviewed-and-tested-by: Kenneth Graunke
Tested-by: Lu Hua
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53618
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54301
---
src/mesa/drivers/dri/common/dri_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index 4276ad9..983bbea 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -272,7 +272,7 @@ dri2CreateContextAttribs(__DRIscreen *screen, int api,
return NULL;
}
-context = malloc(sizeof *context);
+context = calloc(1, sizeof *context);
if (!context) {
*error = __DRI_CTX_ERROR_NO_MEMORY;
return NULL;
--
1.7.11.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] i965: Don't free the intel_context structure when intelCreateContext fails.
From: Ian Romanick
intelDestroyContext will eventually be called, and it will clean things
up. The call to brwInitVtbl is moved earlier so that
intelDestroyContext can call the device-specific destructor. This also
makes the code look more like the i915 code.
NOTE: This is a candidate for the 9.0 branch.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54301
---
src/mesa/drivers/dri/i965/brw_context.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 1083e28..418c873 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -140,6 +140,8 @@ brwCreateContext(int api,
return false;
}
+ brwInitVtbl( brw );
+
brwInitDriverFunctions(screen, &functions);
struct intel_context *intel = &brw->intel;
@@ -148,13 +150,10 @@ brwCreateContext(int api,
if (!intelInitContext( intel, api, mesaVis, driContextPriv,
sharedContextPrivate, &functions )) {
printf("%s: failed to init intel context\n", __FUNCTION__);
- free(brw);
*error = __DRI_CTX_ERROR_NO_MEMORY;
return false;
}
- brwInitVtbl( brw );
-
brw_init_surface_formats(brw);
/* Initialize swrast, tnl driver tables: */
--
1.7.11.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] intel: Don't call intelDestroyContext if there is no context to destroy
From: Ian Romanick Some error paths in the device-specific context creation functions can exit before the deintel_context structure is allocated. NOTE: This is a candidate for the 9.0 branch. Signed-off-by: Ian Romanick --- src/mesa/drivers/dri/intel/intel_screen.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/intel/intel_screen.c b/src/mesa/drivers/dri/intel/intel_screen.c index 5cb7e5d..d6e6408 100644 --- a/src/mesa/drivers/dri/intel/intel_screen.c +++ b/src/mesa/drivers/dri/intel/intel_screen.c @@ -821,7 +821,9 @@ intelCreateContext(gl_api api, if (success) return true; - intelDestroyContext(driContextPriv); + if (driContextPriv->driverPrivate != NULL) + intelDestroyContext(driContextPriv); + return false; } -- 1.7.11.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] i915: Don't free the intel_context structure when intelCreateContext fails.
From: Ian Romanick
intelDestroyContext will eventually be called, and it will clean things up.
NOTE: This is a candidate for the 9.0 branch.
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53618
---
src/mesa/drivers/dri/i915/i915_context.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_context.c
b/src/mesa/drivers/dri/i915/i915_context.c
index 8ae1e58..c0d1f93 100644
--- a/src/mesa/drivers/dri/i915/i915_context.c
+++ b/src/mesa/drivers/dri/i915/i915_context.c
@@ -167,7 +167,6 @@ i915CreateContext(int api,
if (!intelInitContext(intel, api, mesaVis, driContextPriv,
sharedContextPrivate, &functions)) {
- free(i915);
*error = __DRI_CTX_ERROR_NO_MEMORY;
return false;
}
@@ -184,7 +183,6 @@ i915CreateContext(int api,
if (req_version > max_version) {
*error = __DRI_CTX_ERROR_BAD_VERSION;
- free(i915);
return false;
}
break;
@@ -194,7 +192,6 @@ i915CreateContext(int api,
break;
default:
*error = __DRI_CTX_ERROR_BAD_API;
- free(i915);
return false;
}
--
1.7.11.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] FOSDEM2013: DevRoom or not?
On Fri, 28 Sep 2012 17:44:27 +0200 Luc Verhaegen wrote: > On Fri, Sep 21, 2012 at 11:35:12AM +0200, Luc Verhaegen wrote: > > On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote: > > > Hi, > > > > > > The FOSDEM organizers have sent out a call for devrooms. FOSDEM this > > > year is on the weekend of the 2nd and 3rd of February 2013. > > > > > > After the success of this formula last year, where, for the first time > > > ever, we had a properly filled devroom schedule when the deadline hit, i > > > am going to re-apply the same formula: > > > * By the 28th of september, i need 6 committed speakers, otherwise i > > > will not apply for a DevRoom. 6 people need to apply for a talk slot > > > who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. > > > This "definitely" means: > > > * Don't knowingly plan anything else for this weekend. > > > * Come to FOSDEM even if your corporation does not fund you (though > > > feel free to contact the board individually for funding) > > > * Make sure that you are allowed to travel to the shengen area in > > > february. > > > * Catastrophies excluded of course. Such catastrophies include > > > things like train-derailments and such, but explicitely excludes > > > hangovers :p > > > * Scheduling based on timeliness of application: the earlier you apply, > > > the better slot you get. > > > * FOSDEMs final deadline for the full schedule is likely around 15th of > > > january 2013. But do not count on that deadline, we will only do > > > hourly slots, to keep people from running around between devrooms like > > > headless chickens. Only 12-16 slots will be available, first come, > > > first serve. > > > > > > I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 > > > > > > I hope we get a nice devroom like we had last time. That new building we > > > were in was really amazing, even though it took a while before all > > > FOSDEM visitors found it. > > > > > > Thanks, > > > > > > Luc Verhaegen. > > > > Just a heads up guys, we have a week left and not a single speaker yet! > > > > Given the timing of XDC and the FOSDEM deadines, this is not too > > surprising, but still, with XDC2012 in its final day it is high time > > that we start thinking about FOSDEM. I will later on shout at people > > here in the room too :) > > > > All we need now is people who will definitely come to FOSDEM, and who > > are willing to talk in the DevRoom. If a vague idea of a topic is > > already known, then great, but this is not necessary yet. I now put up a > > preliminary wiki page at wiki.x.org/wiki/fosdem2013, add yourself to the > > list there. > > > > Thanks, > > > > Luc Verhaegen. > > Final reminder: the deadline is tonight. > > So far there are three speakers who lined up, and my feeling is that > Matthieu and Marc lined up just so that the deadline and requirement > will be met. So only a single person is intending to come to fosdem and > has a topic he wants to talk about. > > Come on guys. Surely we can do better than that. I could come up with something, maybe people would be interested in hearing about some of our recent SoC work? I'd have to see what I could get approval for, but I could probably find *something* that's not still secret. :) -- Jesse Barnes, Intel Open Source Technology Center ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Revert "radeon/llvm: Inital flow control support for SI"
From: Michel Dänzer
This reverts commit bfd55711c1eb32ffbfceb9d566abae98f0015f23.
It makes piglit unreliable due to VM protection faults and GPU lockups.
Signed-off-by: Michel Dänzer
---
Not sure why I wasn't seeing the piglit unreliablity when I tested the patch
before it was applied... I'm not sure how the patch could cause those issues
directly, so it may be pre-existing bugs merely exposed by it. But either way,
we need to make sure piglit works reliably with this before we can apply it
again.
src/gallium/drivers/radeon/AMDGPU.h|1 -
src/gallium/drivers/radeon/AMDGPUTargetMachine.cpp |1 -
.../drivers/radeon/AMDILCFGStructurizer.cpp|2 -
src/gallium/drivers/radeon/AMDILInstrInfo.td |2 +-
src/gallium/drivers/radeon/Makefile.sources|1 -
src/gallium/drivers/radeon/SIISelLowering.cpp |2 +-
src/gallium/drivers/radeon/SILowerFlowControl.cpp | 161
7 files changed, 2 insertions(+), 168 deletions(-)
delete mode 100644 src/gallium/drivers/radeon/SILowerFlowControl.cpp
diff --git a/src/gallium/drivers/radeon/AMDGPU.h
b/src/gallium/drivers/radeon/AMDGPU.h
index f484caa..fe36545 100644
--- a/src/gallium/drivers/radeon/AMDGPU.h
+++ b/src/gallium/drivers/radeon/AMDGPU.h
@@ -25,7 +25,6 @@ FunctionPass *createR600ExpandSpecialInstrsPass(TargetMachine
&tm);
// SI Passes
FunctionPass *createSIAssignInterpRegsPass(TargetMachine &tm);
-FunctionPass *createSILowerFlowControlPass(TargetMachine &tm);
FunctionPass *createSICodeEmitterPass(formatted_raw_ostream &OS);
FunctionPass *createSILowerLiteralConstantsPass(TargetMachine &tm);
diff --git a/src/gallium/drivers/radeon/AMDGPUTargetMachine.cpp
b/src/gallium/drivers/radeon/AMDGPUTargetMachine.cpp
index 0b70191..c1b6840 100644
--- a/src/gallium/drivers/radeon/AMDGPUTargetMachine.cpp
+++ b/src/gallium/drivers/radeon/AMDGPUTargetMachine.cpp
@@ -134,7 +134,6 @@ bool AMDGPUPassConfig::addPreEmitPass() {
addPass(FinalizeMachineBundlesID);
} else {
PM->add(createSILowerLiteralConstantsPass(*TM));
-PM->add(createSILowerFlowControlPass(*TM));
}
return false;
diff --git a/src/gallium/drivers/radeon/AMDILCFGStructurizer.cpp
b/src/gallium/drivers/radeon/AMDILCFGStructurizer.cpp
index 20e27ef..b167d62 100644
--- a/src/gallium/drivers/radeon/AMDILCFGStructurizer.cpp
+++ b/src/gallium/drivers/radeon/AMDILCFGStructurizer.cpp
@@ -2892,8 +2892,6 @@ struct CFGStructTraits
switch (instr->getOpcode()) {
case AMDGPU::JUMP:
return instr->getOperand(instr->findFirstPredOperandIdx()).getReg() == 0;
-case AMDGPU::BRANCH:
- return true;
default:
return false;
}
diff --git a/src/gallium/drivers/radeon/AMDILInstrInfo.td
b/src/gallium/drivers/radeon/AMDILInstrInfo.td
index 050a5bd..f8771af 100644
--- a/src/gallium/drivers/radeon/AMDILInstrInfo.td
+++ b/src/gallium/drivers/radeon/AMDILInstrInfo.td
@@ -211,7 +211,7 @@ include "AMDILIntrinsics.td"
// Custom Inserter for Branches and returns, this eventually will be a
// seperate pass
//===-===//
-let isTerminator = 1, usesCustomInserter = 1, isBranch = 1, isBarrier = 1 in {
+let isTerminator = 1, usesCustomInserter = 1 in {
def BRANCH : ILFormat<(outs), (ins brtarget:$target),
"; Pseudo unconditional branch instruction",
[(br bb:$target)]>;
diff --git a/src/gallium/drivers/radeon/Makefile.sources
b/src/gallium/drivers/radeon/Makefile.sources
index c5d1207..4b0699b 100644
--- a/src/gallium/drivers/radeon/Makefile.sources
+++ b/src/gallium/drivers/radeon/Makefile.sources
@@ -71,7 +71,6 @@ CPP_SOURCES := \
SIInstrInfo.cpp \
SIISelLowering.cpp \
SILowerLiteralConstants.cpp \
- SILowerFlowControl.cpp \
SIMachineFunctionInfo.cpp \
SIRegisterInfo.cpp \
InstPrinter/AMDGPUInstPrinter.cpp \
diff --git a/src/gallium/drivers/radeon/SIISelLowering.cpp
b/src/gallium/drivers/radeon/SIISelLowering.cpp
index 7c2739c..3f23949 100644
--- a/src/gallium/drivers/radeon/SIISelLowering.cpp
+++ b/src/gallium/drivers/radeon/SIISelLowering.cpp
@@ -78,7 +78,7 @@ MachineBasicBlock *
SITargetLowering::EmitInstrWithCustomInserter(
switch (MI->getOpcode()) {
default:
return AMDGPUTargetLowering::EmitInstrWithCustomInserter(MI, BB);
- case AMDGPU::BRANCH: return BB;
+
case AMDGPU::CLAMP_SI:
BuildMI(*BB, I, BB->findDebugLoc(I), TII->get(AMDGPU::V_MOV_B32_e64))
.addOperand(MI->getOperand(0))
diff --git a/src/gallium/drivers/radeon/SILowerFlowControl.cpp
b/src/gallium/drivers/radeon/SILowerFlowControl.cpp
deleted file mode 100644
index bf5192e..000
--- a/src/gallium/drivers/radeon/SILowerFlowControl.cpp
+++ /dev/null
@@ -1,161 +0,0 @@
-//===-- SILowerFlowControl.cpp - Use predicates for flow control
--===//
-//
-// The LLVM Compiler Infrastructu
[Mesa-dev] [PATCH 2/2] radeonsi: Fix double compilation of shader variants.
From: Michel Dänzer
Fixes crash in piglit glsl-max-varyings.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/radeonsi_shader.c |4
src/gallium/drivers/radeonsi/si_state_draw.c |6 --
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index dbf2fa4..0712bcb 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -706,6 +706,10 @@ int si_pipe_shader_create(
dump = debug_get_bool_option("RADEON_DUMP_SHADERS", FALSE);
+ assert(shader->shader.noutput == 0);
+ assert(shader->shader.ninterp == 0);
+ assert(shader->shader.ninput == 0);
+
memset(&si_shader_ctx, 0, sizeof(si_shader_ctx));
radeon_llvm_context_init(&si_shader_ctx.radeon_bld);
bld_base = &si_shader_ctx.radeon_bld.soa.bld_base;
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index e6a2a58..a3d32a9 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -45,9 +45,6 @@ static void si_pipe_shader_vs(struct pipe_context *ctx,
struct si_pipe_shader *s
unsigned nparams, i;
uint64_t va;
- if (si_pipe_shader_create(ctx, shader))
- return;
-
si_pm4_delete_state(rctx, vs, shader->pm4);
pm4 = shader->pm4 = CALLOC_STRUCT(si_pm4_state);
@@ -106,9 +103,6 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
unsigned spi_baryc_cntl, spi_ps_input_ena;
uint64_t va;
- if (si_pipe_shader_create(ctx, shader))
- return;
-
si_pm4_delete_state(rctx, ps, shader->pm4);
pm4 = shader->pm4 = CALLOC_STRUCT(si_pm4_state);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radeonsi: Better indexing of parameters in the pixel shader.
From: Michel Dänzer
We were previously using the TGSI input index, which can exceed the number of
parameters passed from the vertex shader via the parameter cache. Now we use
a separate index which only counts those parameters.
Prevents piglit regressions with the following fix.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 10 ++
src/gallium/drivers/radeonsi/radeonsi_shader.h |1 +
src/gallium/drivers/radeonsi/si_state_draw.c |9 +
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 57950a7..dbf2fa4 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -239,6 +239,7 @@ static void declare_input_fs(
{
const char * intr_name;
unsigned chan;
+ struct si_shader *shader = &si_shader_ctx->shader->shader;
struct lp_build_context * base =
&si_shader_ctx->radeon_bld.soa.bld_base.base;
struct gallivm_state * gallivm = base->gallivm;
@@ -255,10 +256,7 @@ static void declare_input_fs(
* register field value
*/
LLVMValueRef params = use_sgpr(base->gallivm, SGPR_I32, 6);
-
-
- /* XXX: Is this the input_index? */
- LLVMValueRef attr_number = lp_build_const_int32(gallivm, input_index);
+ LLVMValueRef attr_number;
if (decl->Semantic.Name == TGSI_SEMANTIC_POSITION) {
for (chan = 0; chan < TGSI_NUM_CHANNELS; chan++) {
@@ -274,6 +272,10 @@ static void declare_input_fs(
return;
}
+ shader->input[input_index].param_offset = shader->ninterp++;
+ attr_number = lp_build_const_int32(gallivm,
+
shader->input[input_index].param_offset);
+
/* XXX: Handle all possible interpolation modes */
switch (decl->Interp.Interpolate) {
case TGSI_INTERPOLATE_COLOR:
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.h
b/src/gallium/drivers/radeonsi/radeonsi_shader.h
index aa2888c..6d2b188 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.h
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.h
@@ -63,6 +63,7 @@ struct si_shader {
unsignednoutput;
struct si_shader_io output[32];
+ unsignedninterp;
booluses_kill;
boolfs_write_all;
unsignednr_cbufs;
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index db8f17f..e6a2a58 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -101,7 +101,6 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
struct si_pm4_state *pm4;
unsigned i, exports_ps, num_cout, spi_ps_in_control, db_shader_control;
unsigned num_sgprs, num_user_sgprs;
- int ninterp = 0;
boolean have_linear = FALSE, have_centroid = FALSE, have_perspective =
FALSE;
unsigned fragcoord_interp_mode = 0;
unsigned spi_baryc_cntl, spi_ps_input_ena;
@@ -131,7 +130,7 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
}
continue;
}
- ninterp++;
+
/* XXX: Flat shading hangs the GPU */
if (shader->shader.input[i].interpolate ==
TGSI_INTERPOLATE_CONSTANT ||
(shader->shader.input[i].interpolate ==
TGSI_INTERPOLATE_COLOR &&
@@ -172,7 +171,7 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
exports_ps = 2;
}
- spi_ps_in_control = S_0286D8_NUM_INTERP(ninterp);
+ spi_ps_in_control = S_0286D8_NUM_INTERP(shader->shader.ninterp);
spi_baryc_cntl = 0;
if (have_perspective)
@@ -365,7 +364,9 @@ static void si_update_spi_map(struct r600_context *rctx)
tmp |= S_028644_OFFSET(0x20);
}
- si_pm4_set_reg(pm4, R_028644_SPI_PS_INPUT_CNTL_0 + i * 4, tmp);
+ si_pm4_set_reg(pm4,
+ R_028644_SPI_PS_INPUT_CNTL_0 +
ps->input[i].param_offset * 4,
+ tmp);
}
si_pm4_set_state(rctx, spi, pm4);
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] FOSDEM2013: DevRoom or not?
On Fri, Sep 28, 2012 at 6:07 PM, Jesse Barnes wrote: > On Fri, 28 Sep 2012 17:44:27 +0200 > Luc Verhaegen wrote: > >> On Fri, Sep 21, 2012 at 11:35:12AM +0200, Luc Verhaegen wrote: >> > On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote: >> > > Hi, >> > > >> > > The FOSDEM organizers have sent out a call for devrooms. FOSDEM this >> > > year is on the weekend of the 2nd and 3rd of February 2013. >> > > >> > > After the success of this formula last year, where, for the first time >> > > ever, we had a properly filled devroom schedule when the deadline hit, i >> > > am going to re-apply the same formula: >> > > * By the 28th of september, i need 6 committed speakers, otherwise i >> > > will not apply for a DevRoom. 6 people need to apply for a talk slot >> > > who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. >> > > This "definitely" means: >> > > * Don't knowingly plan anything else for this weekend. >> > > * Come to FOSDEM even if your corporation does not fund you (though >> > > feel free to contact the board individually for funding) >> > > * Make sure that you are allowed to travel to the shengen area in >> > > february. >> > > * Catastrophies excluded of course. Such catastrophies include >> > > things like train-derailments and such, but explicitely excludes >> > > hangovers :p >> > > * Scheduling based on timeliness of application: the earlier you apply, >> > > the better slot you get. >> > > * FOSDEMs final deadline for the full schedule is likely around 15th of >> > > january 2013. But do not count on that deadline, we will only do >> > > hourly slots, to keep people from running around between devrooms like >> > > headless chickens. Only 12-16 slots will be available, first come, >> > > first serve. >> > > >> > > I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 >> > > >> > > I hope we get a nice devroom like we had last time. That new building we >> > > were in was really amazing, even though it took a while before all >> > > FOSDEM visitors found it. >> > > >> > > Thanks, >> > > >> > > Luc Verhaegen. >> > >> > Just a heads up guys, we have a week left and not a single speaker yet! >> > >> > Given the timing of XDC and the FOSDEM deadines, this is not too >> > surprising, but still, with XDC2012 in its final day it is high time >> > that we start thinking about FOSDEM. I will later on shout at people >> > here in the room too :) >> > >> > All we need now is people who will definitely come to FOSDEM, and who >> > are willing to talk in the DevRoom. If a vague idea of a topic is >> > already known, then great, but this is not necessary yet. I now put up a >> > preliminary wiki page at wiki.x.org/wiki/fosdem2013, add yourself to the >> > list there. >> > >> > Thanks, >> > >> > Luc Verhaegen. >> >> Final reminder: the deadline is tonight. >> >> So far there are three speakers who lined up, and my feeling is that >> Matthieu and Marc lined up just so that the deadline and requirement >> will be met. So only a single person is intending to come to fosdem and >> has a topic he wants to talk about. >> >> Come on guys. Surely we can do better than that. > > I could come up with something, maybe people would be interested in > hearing about some of our recent SoC work? I'd have to see what I > could get approval for, but I could probably find *something* that's > not still secret. :) Ok, ok, I'll volunteer myself for another a talk about something kernel-ish. Maybe and update on drm/i915 modesettting stuff (we should be able to check off a lot of the todos from the xdc slides by then) or maybe a talk about drm/i915 testing efforts (yeah, a lot has been happening there without much publicity this year). Or something else. To make the intel roundup complete: Chris, can I volunteer you to give another stab at an "updates from flatland" talk? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Unmerged r600 fixes
Marek, There are a handful of r600g patches on master that are marked as candidates for the stable branches. The first in the series (933faae) doesn't apply cleanly to 9.0, and I assume it won't apply cleanly to 8.0 either. Could you pick these over? 933faae2b8669f459e7ab27d6bcbfb6f4136b6d5 r600g: flush FMASK and CMASK when changing colorbuffers on Evergreen 836325bf7edd797e02ab0717a05ca5c51aa1ac93 r600g: fix instance divisor on Cayman fd5c5384648a0d6191c19748a2d1f1148c5ee98f r600g: fix RSQ of negative value on Cayman 96f50d0cf7bb13507f272d2f6ef9a6fca24d18e1 r600g: fix EXP on Cayman ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 52435] Classic DRI drivers fail to install when libdricore8.1.0.so isn't already in the system
https://bugs.freedesktop.org/show_bug.cgi?id=52435
--- Comment #7 from Matt Turner ---
Okay, I can reproduce.
> make -C src/mesa/drivers/dri/radeon DESTDIR="${pkgdir}" install
This is the relevant part. I guess I don't understand why you want to run make
install on individual directories?
Anyway, from the manual
(http://www.gnu.org/software/libtool/manual/html_node/Install-mode.html):
> inst-prefix is also used to insure that if the installed object must be
> relinked upon installation, that it is relinked against the libraries in
> inst-prefix-dir/prefix, not prefix.
Thus, you need to make install libdricore into the inst-prefix before you can
make install DRI drivers that depend on it.
I did
> make -C src/mesa/libdricore/ DESTDIR=`pwd`/p install
before
> make -C src/mesa/drivers/dri/radeon DESTDIR=`pwd`/p install
and everything worked.
As such, I think this isn't a bug. Let me know if you agree.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/7] i965: Don't spill "smeared" registers.
On Fri, Sep 28, 2012 at 8:13 AM, Paul Berry wrote: > I'll try this later today and see if it has any benefit. If you're going to working with the register allocation code, you may want to take a look at fs_visitor::spill_reg at the same time. Reading the code, it seems like there's the potential for a register used as a source operand multiple times by the same instruction to be also unspilled multiple times. Looks possible that the same applies to being used for source and destination. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] dri_util: Use calloc to allocate __DRIcontext
Ian Romanick writes: > From: Ian Romanick > > The __DRIcontext contains some pointers, and some drivers check for them to be > NULL in some failure paths. Instead of sprinkling NULL assignments across the > various drivers, just zero out the whole thing. Series is: Reviewed-by: Eric Anholt pgpq2xEjNuJH2.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] FOSDEM2013: DevRoom or not?
Hello, I believe that the audience at FOSDEM might be interested in a general course about the graphics infrastructure under Linux. What I have in mind would be a talk that explains : what's X, why do we need it, what is so special about 3D applications that you need a "driver" to run any of them (and who's this driver anyway), what's software rendering, HW acceleration, what is Mesa, what is a DRI driver, ... with examples aimed at making people understand not only *how* they are supposed to set up any new hardware they lay their hands upon, but why it works the way it does. Bonus points for a complete status report of current hardware support under Linux at the end. Perhaps I'm wrong but I think that would be a good way to reach out to a community of people who usually have a very, very limited grasp of what it is exactly that we are doing. (I'm including myself because it's easier to do so for the purpose of this e-mail) Would anyone be willing to do such a presentation? -- Greetings, A. Huillet ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/1] intel: print performance debug messages to `logcat' on Android.
Oliver McFadden writes: > Split the perf_debug() messages into performance debugging information > which may be useful for application developers or driver developers. > > Always print the information useful for application developers on the > Android platform. > > Signed-off-by: Oliver McFadden > CC: Chad Versace > --- > v2: Split perf_debug() into app/driver specific messages; try to only print > useful debug information to the application developer. > > Chad, I'd like your opinion on whether I have split the app/driver messages > roughly correctly. Thanks! I don't think you want to split these. As an app dev, do want to know when you're recompiling shaders or mapping busy BOs. (Busy BOs is like the most important thing in perf_debug for you!) pgp6BkXPwTdBM.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/1] intel: print performance debug messages to `logcat' on Android.
On 09/28/2012 01:28 PM, Eric Anholt wrote: > Oliver McFadden writes: > >> Split the perf_debug() messages into performance debugging information >> which may be useful for application developers or driver developers. >> >> Always print the information useful for application developers on the >> Android platform. >> >> Signed-off-by: Oliver McFadden >> CC: Chad Versace >> --- >> v2: Split perf_debug() into app/driver specific messages; try to only print >> useful debug information to the application developer. >> >> Chad, I'd like your opinion on whether I have split the app/driver messages >> roughly correctly. Thanks! > > I don't think you want to split these. As an app dev, do want to know > when you're recompiling shaders or mapping busy BOs. (Busy BOs is like > the most important thing in perf_debug for you!) Agreed. All messages are useful for both classes of developers. Even if an application developer can't do anything about a particular message, it's at least useful to tell them that they're hitting a slow path in our driver and suffering as a consequence. Driver developers want to see everything. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 19/19] mesa/tests: Sanity check the ES2 dispatch table
On 5 September 2012 15:09, Ian Romanick wrote: > From: Ian Romanick > > This test is only built when shared-glapi is used. Because of changes > elsewhere in the tree that were necessary to make shared-glapi work > correct with GLX, it's not feasible to make the test function both ways. > > Signed-off-by: Ian Romanick > This test is failing on my system when I run "make check": [--] 1 test from DispatchSanity_test [ RUN ] DispatchSanity_test.GLES2 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable dispatch_sanity.cpp:122: Failure Value of: table[i] Actual: 0x4de54e Expected: (_glapi_proc) _mesa_generic_nop Which is: 0x41af72 i = 321 [ FAILED ] DispatchSanity_test.GLES2 (4 ms) [--] 1 test from DispatchSanity_test (4 ms total) Is anybody else getting this problem? Here's how I have Mesa configured: ./autogen.sh \ --with-gallium-drivers= \ --enable-gles1 \ --disable-glut \ --enable-debug \ --enable-egl \ --enable-gles2 \ --enable-texture-float \ --enable-glx-tls \ --enable-shared-glapi \ "--prefix=$PLATFORM_INSTALL_DIR" \ --with-dri-drivers=swrast,i915,i965 \ CFLAGS="-O0 $CFLAGS" \ CXXFLAGS="-O0 $CXXFLAGS" ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 19/19] mesa/tests: Sanity check the ES2 dispatch table
On 09/28/2012 01:55 PM, Paul Berry wrote: On 5 September 2012 15:09, Ian Romanick mailto:i...@freedesktop.org>> wrote: From: Ian Romanick mailto:ian.d.roman...@intel.com>> This test is only built when shared-glapi is used. Because of changes elsewhere in the tree that were necessary to make shared-glapi work correct with GLX, it's not feasible to make the test function both ways. Signed-off-by: Ian Romanick mailto:ian.d.roman...@intel.com>> This test is failing on my system when I run "make check": [--] 1 test from DispatchSanity_test [ RUN ] DispatchSanity_test.GLES2 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable dispatch_sanity.cpp:122: Failure Value of: table[i] Actual: 0x4de54e Expected: (_glapi_proc) _mesa_generic_nop Which is: 0x41af72 i = 321 [ FAILED ] DispatchSanity_test.GLES2 (4 ms) [--] 1 test from DispatchSanity_test (4 ms total) Is anybody else getting this problem? Can you put the following in the SET_by_offset macro (src/mesa/main/dispatch.h in your build directory): if (offset == 321) abort(); \ then backtrace to see what API function is at fault? Here's how I have Mesa configured: ./autogen.sh \ --with-gallium-drivers= \ --enable-gles1 \ --disable-glut \ --enable-debug \ --enable-egl \ --enable-gles2 \ --enable-texture-float \ --enable-glx-tls \ --enable-shared-glapi \ "--prefix=$PLATFORM_INSTALL_DIR" \ --with-dri-drivers=swrast,i915,i965 \ CFLAGS="-O0 $CFLAGS" \ CXXFLAGS="-O0 $CXXFLAGS" ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] FOSDEM2013: DevRoom or not?
On Fri, Sep 28, 2012 at 05:44:27PM +0200, Luc Verhaegen wrote: > > Final reminder: the deadline is tonight. > > So far there are three speakers who lined up, and my feeling is that > Matthieu and Marc lined up just so that the deadline and requirement > will be met. So only a single person is intending to come to fosdem and > has a topic he wants to talk about. > > Come on guys. Surely we can do better than that. > > Luc Verhaegen. After a bit of a scramble, we now have 7.5 speakers confirmed, and two pending budget/approval (which do not count towards the limit). I have therefor sent off the request to the organizers, there is little doubt that we will once again get a nice devroom next year :) We still have, i hope (depends on what the FOSDEM organizers have left for us), 6 slots fully open: first come first serve, and the earlier bird gets the nicer slot! Thanks all, especially those who stepped up already. Luc Verhaegen. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/1] intel: print performance debug messages to `logcat' on Android.
On 09/28/2012 01:47 PM, Kenneth Graunke wrote: > On 09/28/2012 01:28 PM, Eric Anholt wrote: >> Oliver McFadden writes: >> >>> Split the perf_debug() messages into performance debugging information >>> which may be useful for application developers or driver developers. >>> >>> Always print the information useful for application developers on the >>> Android platform. >>> >>> Signed-off-by: Oliver McFadden >>> CC: Chad Versace >>> --- >>> v2: Split perf_debug() into app/driver specific messages; try to only print >>> useful debug information to the application developer. >>> >>> Chad, I'd like your opinion on whether I have split the app/driver messages >>> roughly correctly. Thanks! Looks like the consensus is against my suggestions... >> I don't think you want to split these. As an app dev, do want to know >> when you're recompiling shaders or mapping busy BOs. (Busy BOs is like >> the most important thing in perf_debug for you!) > > Agreed. All messages are useful for both classes of developers. Even > if an application developer can't do anything about a particular > message, it's at least useful to tell them that they're hitting a slow > path in our driver and suffering as a consequence. Driver developers > want to see everything. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): i965: Don' t free the intel_context structure when intelCreateContext fails.
On 09/28/2012 03:05 PM, Ian Romanick wrote:
Module: Mesa
Branch: master
Commit: 87f26214d6bdeb439b30615ec53c293c5141cf11
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=87f26214d6bdeb439b30615ec53c293c5141cf11
Author: Ian Romanick
Date: Fri Aug 31 14:55:21 2012 -0700
i965: Don't free the intel_context structure when intelCreateContext fails.
intelDestroyContext will eventually be called, and it will clean things
up. The call to brwInitVtbl is moved earlier so that
intelDestroyContext can call the device-specific destructor. This also
makes the code look more like the i915 code.
NOTE: This is a candidate for the 9.0 branch.
Signed-off-by: Ian Romanick
Reviewed-by: Eric Anholt
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54301
---
src/mesa/drivers/dri/i965/brw_context.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 1083e28..418c873 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -140,6 +140,8 @@ brwCreateContext(int api,
return false;
}
+ brwInitVtbl( brw );
+
Yes, I know this part of the change broke the world. I'm working on
fixing it.
brwInitDriverFunctions(screen, &functions);
struct intel_context *intel = &brw->intel;
@@ -148,13 +150,10 @@ brwCreateContext(int api,
if (!intelInitContext( intel, api, mesaVis, driContextPriv,
sharedContextPrivate, &functions )) {
printf("%s: failed to init intel context\n", __FUNCTION__);
- free(brw);
*error = __DRI_CTX_ERROR_NO_MEMORY;
return false;
}
- brwInitVtbl( brw );
-
brw_init_surface_formats(brw);
/* Initialize swrast, tnl driver tables: */
___
mesa-commit mailing list
mesa-com...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-commit
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 14/19] glx: Reuse setSwapInterval for setting initial swap interval.
On 09/25/2012 07:50 PM, Eric Anholt wrote:
> ---
> src/glx/dri2_glx.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
> @@ -829,7 +826,9 @@ dri2SetSwapInterval(__GLXDRIdrawable *pdraw, int interval)
>
> switch (vblank_mode) {
> case DRI_CONF_VBLANK_NEVER:
> - return GLX_BAD_VALUE;
> + if (interval != 0)
> + return GLX_BAD_VALUE;
> + break;
> case DRI_CONF_VBLANK_ALWAYS_SYNC:
>if (interval <= 0)
>return GLX_BAD_VALUE;
I think this patch should be split into two because it does more than a simple
replacement, as the subject claims. This hunk apparently fixes a bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/19] glx: Replace DRI2SwapInterval custom protocol with XCB.
On 09/25/2012 07:50 PM, Eric Anholt wrote: > --- > src/glx/dri2.c | 19 --- > src/glx/dri2.h |3 --- > src/glx/dri2_glx.c |9 ++--- > 3 files changed, 2 insertions(+), 29 deletions(-) Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/19] glx: Fix some indentation.
Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa 9.0 release plans
There are only a few patches left on master marked as candidates for the branch. These basically fall into three groups: - Fix mipmap generation. There is stil one outstanding bug related to integer textures. Anuj is working on a fix (disable mipmap generation for integer textures). Once this is available, the whole series will be picked. 299acac849eb8506de9760c94c6e8e8b1046d909 _mesa_meta_GenerateMipmap: Support all texture targets by generating shaders at runtime 15bf3103b48a5928321fe56fbb3ed28a0f314418 _mesa_meta_GenerateMipmap: Generate separate shaders for glsl 120 / 130 eb1d87fb945783448cc40ad43c9cd4d98002d424 meta: Add on demand compilation of per target shader programs - TexImage performance improvement for Google Chrome. There's still some debate about whether or not these should be picked. 413c4914129cd26ca87960852d8c0264c0fb29e7 intel: Improve teximage perf for Google Chrome paint rects (v3) b1d0fe022dc4826dadce014ab8fe062a82f75a16 intel: Fix segfault in intel_texsubimage_tiled_memcpy b5891286202987dfc2606ac716050c0ee426de11 intel: Fix yet-another-bug in intel_texsubimage_tiled_memcpy - A set of fixes for r600g. The first had a pile of conflicts, and I don't have hardware to test. I punted this back to Marek. 933faae2b8669f459e7ab27d6bcbfb6f4136b6d5 r600g: flush FMASK and CMASK when changing colorbuffers on Evergreen 836325bf7edd797e02ab0717a05ca5c51aa1ac93 r600g: fix instance divisor on Cayman fd5c5384648a0d6191c19748a2d1f1148c5ee98f r600g: fix RSQ of negative value on Cayman 96f50d0cf7bb13507f272d2f6ef9a6fca24d18e1 r600g: fix EXP on Cayman My goal is to have all of these resolved by Monday or Tuesday, and we'll do the release on Friday (10/5). Sound good? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 17/19] glx: Replace DRI2SwapBuffers() custom protocol with XCB.
> + swap_buffers_cookie = > + xcb_dri2_swap_buffers_unchecked(c, pdraw->xDrawable, > + target_msc_hi, target_msc_lo, > + divisor_hi, divisor_lo, > + remainder_hi, remainder_lo); > + /* Immediately wait on the swapbuffers reply. If we didn't, we'd have > +* to do so some time before reusing a (non-pageflipped) backbuffer. > +* Otherwise, the new rendering could get ahead of the X Server's > +* dispatch of the swapbuffer and you'd display garbage. > +* > +* We use XSync() first to reap the invalidate events through the > event > +* filter, to ensure that the next drawing doesn't use an invalidated > +* buffer. > +*/ > + XSync(pdraw->psc->dpy, False); > + swap_buffers_reply = > + xcb_dri2_swap_buffers_reply(c, swap_buffers_cookie, NULL); > + ret = merge_counter(swap_buffers_reply->swap_hi, > + swap_buffers_reply->swap_lo); > + free(swap_buffers_reply); Will this sync harm performance for artificial benchmarks? I'm asking because this hunk reminds me of Oliver's comments that Dante was slower on EGL than GLX perhaps due to extra X roundtrips. Anyway, roll-our-own-X-protocol needs to die. Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 18/19] egl: Add support for driconf control of swapinterval.
On 09/25/2012 07:50 PM, Eric Anholt wrote: > This behavior mostly matches glx_dri2. It's slightly complicated in > comparison by the EGL exposes the limits on the EGL config. ^^^ mangled sentence? I understand what this patch accomplishes, but I'm unfamiliar with these parts of the codebase. So, Acked-by: Chad Versace I don't understand the invalidate dance at all, so my review stops at this patch. Just a reminder, on some earlier patches my review is pending on some questions. Thanks for the cleanup. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 9.0 release plans
On 09/28/2012 04:10 PM, Ian Romanick wrote: > There are only a few patches left on master marked as candidates for the > branch. These basically fall into three groups: > - TexImage performance improvement for Google Chrome. There's still some > debate about whether or not these should be picked. > 413c4914129cd26ca87960852d8c0264c0fb29e7 intel: Improve teximage perf for > Google Chrome paint rects (v3) > b1d0fe022dc4826dadce014ab8fe062a82f75a16 intel: Fix segfault in > intel_texsubimage_tiled_memcpy > b5891286202987dfc2606ac716050c0ee426de11 intel: Fix yet-another-bug in > intel_texsubimage_tiled_memcpy These are a nice-to-have but not critical. I'd like to see them committed because they improve Chrome's texture upload workload by 3-5x depending on environmental factors. But I won't cry if people object. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 9.0 release plans
On 09/28/2012 04:10 PM, Ian Romanick wrote: > There are only a few patches left on master marked as candidates for the > branch. These basically fall into three groups: > > - Fix mipmap generation. There is stil one outstanding bug related to > integer textures. Anuj is working on a fix (disable mipmap generation > for integer textures). Once this is available, the whole series will be > picked. > > 299acac849eb8506de9760c94c6e8e8b1046d909 _mesa_meta_GenerateMipmap: > Support all texture targets by generating shaders at runtime > 15bf3103b48a5928321fe56fbb3ed28a0f314418 _mesa_meta_GenerateMipmap: > Generate separate shaders for glsl 120 / 130 > eb1d87fb945783448cc40ad43c9cd4d98002d424 meta: Add on demand compilation > of per target shader programs > > - TexImage performance improvement for Google Chrome. There's still > some debate about whether or not these should be picked. > 413c4914129cd26ca87960852d8c0264c0fb29e7 intel: Improve teximage perf > for Google Chrome paint rects (v3) > b1d0fe022dc4826dadce014ab8fe062a82f75a16 intel: Fix segfault in > intel_texsubimage_tiled_memcpy > b5891286202987dfc2606ac716050c0ee426de11 intel: Fix yet-another-bug in > intel_texsubimage_tiled_memcpy > > - A set of fixes for r600g. The first had a pile of conflicts, and I > don't have hardware to test. I punted this back to Marek. > > 933faae2b8669f459e7ab27d6bcbfb6f4136b6d5 r600g: flush FMASK and CMASK > when changing colorbuffers on Evergreen > 836325bf7edd797e02ab0717a05ca5c51aa1ac93 r600g: fix instance divisor on > Cayman > fd5c5384648a0d6191c19748a2d1f1148c5ee98f r600g: fix RSQ of negative > value on Cayman > 96f50d0cf7bb13507f272d2f6ef9a6fca24d18e1 r600g: fix EXP on Cayman > > My goal is to have all of these resolved by Monday or Tuesday, and we'll > do the release on Friday (10/5). > > Sound good? There are still a number of regressions on master vs. 8.0. Notably, Pineview is in really horrible shape. There're a few patches on the list that still need to get into master...then 9.0. But I think we can pull that off still. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] scons: Use full path of texture_builtins.py.
Fixes this build error on Cygwin.
Explicit dependency `src/glsl/builtins/tools/texture_builtins.py' not
found, needed by target
`build/cygwin-x86-debug/glsl/builtin_function.cpp'.
Signed-off-by: Vinson Lee
---
src/glsl/SConscript |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glsl/SConscript b/src/glsl/SConscript
index b034f3b..6314c75 100644
--- a/src/glsl/SConscript
+++ b/src/glsl/SConscript
@@ -87,7 +87,7 @@ else:
command = python_cmd + ' $SCRIPT $SOURCE > $TARGET'
)
-env.Depends(builtin_glsl_function, ['builtins/tools/generate_builtins.py',
'builtins/tools/texture_builtins.py'] + Glob('builtins/ir/*'))
+env.Depends(builtin_glsl_function, ['builtins/tools/generate_builtins.py',
'#src/glsl/builtins/tools/texture_builtins.py'] + Glob('builtins/ir/*'))
Export('builtin_glsl_function')
--
1.7.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
