Re: [Mesa-dev] ipers performance regression (Was: u_upload_mgr changes)

On 04/01/16 12:25, Jose Fonseca wrote: On 21/12/15 22:35, Marek Olšák wrote: Hi, This patch series adds more flexibility to u_upload_mgr. First, it adds the ability to specify the alignment per suballocation. The idea is that several users can use the same upload buffer, but each may need a

Re: [Mesa-dev] ipers performance regression (Was: u_upload_mgr changes)

On 04/01/16 14:03, Marek Olšák wrote: On Mon, Jan 4, 2016 at 2:09 PM, Jose Fonseca wrote: On 04/01/16 12:25, Jose Fonseca wrote: On 21/12/15 22:35, Marek Olšák wrote: Hi, This patch series adds more flexibility to u_upload_mgr. First, it adds the ability to specify the alignment per

Re: [Mesa-dev] [PATCH 3/3] llvmpipe: add sse code for fixed position calculation

= 0; // should be unused position->dx01 = position->x[0] - position->x[1]; position->dy01 = position->y[0] - position->y[1]; position->dx20 = position->x[2] - position->x[0]; position->dy20 = position->y[2] - position->y[0]; +#endif posi

[Mesa-dev] [PATCH] wgl: Rudimentary wglUseFontBitmaps sample.

It uses SYSTEM_FONT which actually creates some challenges when emulating wglUseFontBitmaps: in spite what https://msdn.microsoft.com/en-us/library/windows/desktop/dd374392.aspx implies, GetGlyphOutline(GGO_BITMAP) does not seem to work with certain fonts. The only solution is to draw the font c

Re: [Mesa-dev] [PATCH 2/2] llvmpipe: avoid most 64 bit math in rasterization

On 06/01/16 00:06, srol...@vmware.com wrote: From: Roland Scheidegger The trick here is to recognize that in the c + n * dcdx calculations, not only can the lower FIXED_ORDER bits not change (as the dcdx values have those all zero) but that this means the sign bit of the calculations cannot be

Re: [Mesa-dev] [PATCH 2/2] llvmpipe: avoid most 64 bit math in rasterization

On 06/01/16 16:26, Jose Fonseca wrote: On 06/01/16 00:06, srol...@vmware.com wrote: From: Roland Scheidegger The trick here is to recognize that in the c + n * dcdx calculations, not only can the lower FIXED_ORDER bits not change (as the dcdx values have those all zero) but that this means

Re: [Mesa-dev] [PATCH 1/3] st/mesa: check state->mesa in early return check in st_validate_state()

idate_state( struct st_context *st ) st_manager_validate_framebuffers(st); - if (state->st == 0) + if (state->st == 0 && state->mesa == 0) return; /*printf("%s %x/%x\n", __func__, state->mesa, state->st);*/ Good stuff. Series

Re: [Mesa-dev] [PATCH 4/4] main: s/GLuint/GLbitfield for state bitmasks

-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] st/mesa: check texture target in allocate_full_mipmap()

Anyway, my understanding this function just makes a guess, and it's ok to mis-guess. So, series is Reviewed-by: Jose Fonseca Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] llvmpipe: avoid most 64 bit math in rasterization

On 06/01/16 18:18, Roland Scheidegger wrote: Am 06.01.2016 um 17:31 schrieb Jose Fonseca: On 06/01/16 16:26, Jose Fonseca wrote: On 06/01/16 00:06, srol...@vmware.com wrote: From: Roland Scheidegger The trick here is to recognize that in the c + n * dcdx calculations, not only can the lower

Re: [Mesa-dev] [PATCH] draw: fix line stippling with unfilled prims

W_PIPE_EDGE_FLAG_2) && v2->edgeflag) + line(stage, header, v2, v0); + if ((header->flags & DRAW_PIPE_EDGE_FLAG_0) && v0->edgeflag) + line(stage, header, v0, v1); + if ((header->flags & DRAW_PIPE_EDGE_FLAG_1) && v1->edgeflag) + line(

Re: [Mesa-dev] [PATCH] configure.ac: add --enable-llvmpipe-profile

On 07/01/16 16:27, Oded Gabbay wrote: To profile llvmpipe you need to define PROFILE in mesa's code. Currently, this define can only be generated if mesa is built using scons. This patch makes it possible to generate this define also when building mesa through automake tools. Signed-off-by: Oded

Re: [Mesa-dev] [PATCH] llvmpipe: use sse2 conv code for altivec

On 07/01/16 18:18, Oded Gabbay wrote: In lp_build_conv() and lp_build_conv_auto(), there is a special case of conversion when sse2 is present. That code path is suitable without any changes to altivec, because all the functions that are called in that code path already support altivec. This patc

Re: [Mesa-dev] [PATCH v2] configure.ac: add --enable-profile

Thanks for the update. autotools is not my forte, but changes looks good AFAICT. Reviewed-by: Jose Fonseca Jose On 07/01/16 17:01, Oded Gabbay wrote: For profiling mesa's code, especially llvmpipe, PROFILE should be defined. Currently, this define can only be generated if mesa is

Re: [Mesa-dev] [PATCH] draw: initialize prim header flags when clipping lines

/draw_pipe_clip.c @@ -611,6 +611,8 @@ do_clip_line(struct draw_stage *stage, struct prim_header newprim; int viewport_index; + newprim.flags = header->flags; + if (stage->draw->rasterizer->flatshade_first) { prov_vertex = v0; } Thanks. Reviewed-by:

[Mesa-dev] [PATCH 2/2] glsl: Ensure 64bits shift is used.

I believe that `1u << x`, where x >= 32 yields undefined results according to the C standard. Particularly MSVC says `warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)`. --- src/glsl/link_varyings.cpp | 6 +++--- 1 file changed, 3 insertions

[Mesa-dev] [PATCH 1/2] mesa/main: Avoid `void function returning a value` warning.

Trivial. --- src/mesa/main/shaderimage.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c index c4ebf42..040e9fd 100644 --- a/src/mesa/main/shaderimage.c +++ b/src/mesa/main/shaderimage.c @@ -738,8 +738,10 @@ _mesa_

Re: [Mesa-dev] [PATCH 3/3] llvmpipe: add sse code for fixed position calculation

On 08/01/16 20:04, Roland Scheidegger wrote: Am 08.01.2016 um 20:33 schrieb Roland Scheidegger: Am 07.01.2016 um 19:56 schrieb Roland Scheidegger: Am 07.01.2016 um 16:40 schrieb Jose Fonseca: On 07/01/16 06:18, Roland Scheidegger wrote: Am 04.01.2016 um 20:38 schrieb Jose Fonseca: On 02/01

[Mesa-dev] Fwd: Build failed: mesa 231

Forwarded Message Subject:Build failed: mesa 231 Date: Fri, 08 Jan 2016 22:56:40 + From: AppVeyor To: jrfons...@freedesktop.org Build mesa 231 failed Commit e3706a7118 by Ilia Mirkin

Re: [Mesa-dev] Fwd: Build failed: mesa 231

On 08/01/16 23:27, Ilia Mirkin wrote: c:\projects\mesa\src\glsl\nir\nir.h(41) : fatal error C1083: Cannot open include file: 'nir_opcodes.h': No such file or directory It seems unlikely to be my bad, given that my commit didn't touch anything outside of nouveau... or does that just list the late

Re: [Mesa-dev] Mesa (master): glsl: Move _mesa_shader_stage_to_string/ abbrev to shader_enums.c

Scons deosn't build nir, so adding nir files to glsl is not an option. We either need to revert e97caba1f6c2bd803f9c8b969b52c21f93daf1d0, or move the nir+glsl files in a different variable ,e.g.,: diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am index 33a34e4..cdb9e72 100644 --- a/src/

Re: [Mesa-dev] [PATCH] glsl: Don't add nir files to libglsl_la_SOURCES

Looks great. Thanks. Reviewed-by: Jose Fonseca We really need to get NIR into SCons. There's no reason not to. It takes time, but when consider the time we all spend with build issues, it's probably not that much. Jose On 08/01/16 23:44, Kristian Høgsberg wrote: From: Kristia

[Mesa-dev] NIR, SCons, and Gallium

FWIW, I updated SCons to build NIR, both with GCC and MSVC: http://cgit.freedesktop.org/~jrfonseca/mesa/log/?h=scons-nir It was actually simpler than I anticipated. But I hit a wall -- there's actually no way to get NIR used with softpipe/llvmpipe, not even as an intermediate IR somewhere be

Re: [Mesa-dev] [PATCH] configure.ac: always define __STDC_CONSTANT_MACROS

cppdefines += ['__STDC_LIMIT_MACROS'] +cppdefines += ['__STDC_LIMIT_MACROS', '__STDC_CONSTANT_MACROS'] if env['build'] in ('debug', 'checked'): cppdefines += ['DEBUG'] else: Either way, Reviewed-by:

Re: [Mesa-dev] [PATCH] configure.ac: always define __STDC_CONSTANT_MACROS

The type of the resulting variable is `uint64_t` not `unsigned long long`. To use ULL on constants one should also use `unsigned long long` everywhere else in Mesa. Mixing uint64_t and unsigned long long seems sloppy to me, as these types could potentially be different things on different pla

Re: [Mesa-dev] [PATCH] configure.ac: always define __STDC_CONSTANT_MACROS

#x27;s bigger. On Tue, Jan 12, 2016 at 2:55 AM, Jose Fonseca wrote: The type of the resulting variable is `uint64_t` not `unsigned long long`. To use ULL on constants one should also use `unsigned long long` everywhere else in Mesa. Mixing uint64_t and unsigned long long seems sloppy to me, as th

Re: [Mesa-dev] [PATCH] configure.ac: always define __STDC_CONSTANT_MACROS

Anyway, my point is that this is not a precendent. No idea why this caused problems for Oded now. LLVM headers already requires __STDC_CONSTANT_MACROS being defined. Jose And by your argument, it's pointless to use uint32_t because On 12/01/16 08:15, Jose Fonseca wrote: It'

Re: [Mesa-dev] [PATCH] st/mesa: fix incorrect buffer token passed to _mesa_BindFramebuffer()

nums look so much alike makes it even worse to spot. Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure.ac: always define __STDC_CONSTANT_MACROS

have to agree on disagreeing here. I agree it's a matter of style. If people prefer using ULL I won't be nitpicking, but to me UINT64_C() seems more concise, and I'd like to be able to continue using it. Anyway, I think we spent enough time on this already. Jose On Tue, Jan 1

Re: [Mesa-dev] [PATCH] draw: fix key comparison with uninitialized value

tic_state samplers[1]; }; The change looks OK, but I wonder if it wouldn't be more future proof to just memset the whole structure to zero? And then ensure we always use memcpy to copy, memcmp to compare. I believe this is the pattern we've been following elsewhere. Either way,

Re: [Mesa-dev] [PATCH v4 1/3] gallium/st: add pipe_context::generate_mipmap()

ipmap looks good to me now. Otherwise series looks good to me too. Reviewed-by: Jose Fonseca Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] draw: fix key comparison with uninitialized value

e padding here - must use memset */ struct draw_sampler_static_state samplers[1]; }; Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] NIR, SCons, and Gallium

On 11/01/16 14:21, Jose Fonseca wrote: FWIW, I updated SCons to build NIR, both with GCC and MSVC: http://cgit.freedesktop.org/~jrfonseca/mesa/log/?h=scons-nir It was actually simpler than I anticipated. But I hit a wall -- there's actually no way to get NIR used with softpipe/llv

Re: [Mesa-dev] [PATCH 1/2] llvmpipe: fix "leaking" textures

last; I think `current_tex_num` might be more self-documenting -- making it clear it refers current_tex array. No need for `last`. } fs; /** fragment shader constants */ Reviewed-by: Jose Fonseca Jose ___ mesa-dev mailing list mesa-de

Re: [Mesa-dev] [PATCH 2/2] llvmpipe: ditch ref counting for vertex/geometry shader sampler views

ipe_cleanup_geometry_sampling(struct llvmpipe_context *ctx) -{ - unsigned i; - for (i = 0; i < Elements(ctx->mapped_gs_tex); i++) { - pipe_resource_reference(&ctx->mapped_gs_tex[i], NULL); - } -} void llvmpipe_init_sampler_funcs(struct llvmpipe_context *llv

Re: [Mesa-dev] [PATCH] llvmpipe: use vpkswss when dst is signed

On 17/01/16 20:55, Oded Gabbay wrote: This patch fixes a bug when building a pack instruction. For POWER (altivec), in case the destination is signed and the src width is 32, we need to use vpkswss. The original code used vpkuwus, which emits an unsigned result. This fixes the following piglit

[Mesa-dev] Bugzilla (Was: [Bug 93686] Performance improvement : Please consider hardware ɢᴘᴜ rendering in llvmpipe)

On 18/01/16 12:21, bugzilla-dae...@freedesktop.org wrote: *Comment # 34 on bug 93686 from Daniel Stone * @ytrezq: Please stop CCing so many people. Everyone

Re: [Mesa-dev] [PATCH] util/u_pstipple.c: copy immediates during transformation

he emit_immediate() call one line up, so it lines up with draw_pipe_pstipple.c. Otherwise, Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] llvmpipe: turn depth clears into full depth/stencil clears for d24x8 formats

's "X" bits so we can do full + * clear (without rmw). + */ + uint32_t zsmask_full = 0; + zsmask_full = util_pack_mask_z_stencil(format, ~0, ~0); + zsmask |= ~zsmask_full; + } + if (setup->state == SETUP_ACTIVE) { str

Re: [Mesa-dev] [PATCH] llvmpipe: warn about illegal use of objects in different contexts

+ } + util_copy_framebuffer_state(&lp->framebuffer, fb); if (LP_PERF & PERF_NO_DEPTH) { -pipe_surface_reference(&lp->framebuffer.zsbuf, NULL); + pipe_surface_reference(&lp->framebuffer.zsbuf, NULL); } /* Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] llvmpipe, i915: add back NEW_RASTERIZER dependency when computing vertex info

W; } - if (llvmpipe->dirty & (LP_NEW_FS | + if (llvmpipe->dirty & (LP_NEW_RASTERIZER | + LP_NEW_FS | LP_NEW_VS)) compute_vertex_info(llvmpipe); Given it's not obvious, let's add a comment

Re: [Mesa-dev] [PATCH v2] glx: update to updated version of EXT_create_context_es2_profile

FWIW see https://bugs.freedesktop.org/show_bug.cgi?id=92869 http://cgit.freedesktop.org/~jrfonseca/mesa/commit/?h=es2_profile On 21/01/16 16:58, Ilia Mirkin wrote: The EXT spec has been updated to: - logically combine the es2_profile and es_profile exts - allow any legal version to be r

Re: [Mesa-dev] [PATCH v2] glx: update to updated version of EXT_create_context_es2_profile

On 21/01/16 18:43, Ian Romanick wrote: On 01/21/2016 09:10 AM, Jose Fonseca wrote: FWIW see https://bugs.freedesktop.org/show_bug.cgi?id=92869 http://cgit.freedesktop.org/~jrfonseca/mesa/commit/?h=es2_profile On 21/01/16 16:58, Ilia Mirkin wrote: The EXT spec has been updated to

Re: [Mesa-dev] [PATCH v2] glx: update to updated version of EXT_create_context_es2_profile

On 21/01/16 17:35, Ilia Mirkin wrote: On Thu, Jan 21, 2016 at 12:10 PM, Jose Fonseca wrote: FWIW see https://bugs.freedesktop.org/show_bug.cgi?id=92869 http://cgit.freedesktop.org/~jrfonseca/mesa/commit/?h=es2_profile Ah, I was unaware of your prior work. FWIW I also sent an X server

Re: [Mesa-dev] [PATCH 0/6] Move nir/glsl to src/compiler, take 2

good to me AFAICS. Thanks for run it through on AppVeyor. In the unlikely event there's an issue we can deal with it then. Series is Acked-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailma

[Mesa-dev] [PATCH] appveyor: Bump shallow clone depth.

To prevent build failures when a large patch series is committed, like happened in https://ci.appveyor.com/project/jrfonseca-fdo/mesa/build/322 due to 10 commits between dac2964f3ebd96d5ac227984ab0cd79c2c3b2a1a and 6f428328d34bed16edb8709e4a117eb710d7893d where submitted before the build slave star

Re: [Mesa-dev] [PATCH v2 1/4] mesa: add GREMEDY_string_marker

On 20/01/16 19:48, Rob Clark wrote: On Wed, Jan 20, 2016 at 2:44 PM, Ilia Mirkin wrote: On Wed, Jan 20, 2016 at 2:32 PM, Rob Clark wrote: From: Rob Clark Signed-off-by: Rob Clark --- src/mapi/glapi/gen/GREMEDY_string_marker.xml | 18 ++ src/mapi/glapi/gen/Makefile.am

mesa-dev@lists.freedesktop.org

On 01/02/16 15:27, Marek Olšák wrote: On Mon, Feb 1, 2016 at 3:51 PM, Miklós Máté wrote: On 12/19/2015 12:24 AM, Marek Olšák wrote: On Fri, Dec 18, 2015 at 11:45 PM, Miklós Máté wrote: On 12/17/2015 01:06 PM, Marek Olšák wrote: On Wed, Dec 16, 2015 at 11:30 PM, Miklós Máté wrot

Re: [Mesa-dev] [PATCH 3/3] llvmpipe: drop scissor planes early if the tri is fully inside them

plane[scis_index].c = (scissor->x1+1) << 8; + plane[scis_index].eo = 0 << 8; + scis_index++; + } + if (bbox.y0 < scissor->y0) { + plane[scis_index].dcdx = 0; + plane[scis_index].dcdy = 1 << 8; + plane[scis_index].c = (1-scissor->y0) << 8; + plane[scis_index].eo = 1 << 8; + scis_index++; + } + if (bbox.y1 > scissor->y1) { + plane[scis_index].dcdx = 0; + plane[scis_index].dcdy = -1 << 8; + plane[scis_index].c = (scissor->y1+1) << 8; + plane[scis_index].eo = 0; + scis_index++; + } + assert(scis_index == nr_planes); } return lp_setup_bin_triangle(setup, tri, &bbox, nr_planes, viewport_index); Otherwise looks good. The other patches of this series looks good too, and are Reviwed-by: Jose Fonseca http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] gallivm: add PK2H/UP2H support

ns[TGSI_OPCODE_POW] = pow_action; bld_base->op_actions[TGSI_OPCODE_SCS] = scs_action; + bld_base->op_actions[TGSI_OPCODE_UP2H] = up2h_action; bld_base->op_actions[TGSI_OPCODE_XPD] = xpd_action; bld_base->op_actions[TGSI_OPCODE_BREAKC].fetch_args = scalar_unary_fetch_args; Otherwise series looks good. Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] radeonsi: implement PK2H and UP2H opcodes

On 03/02/16 17:01, Marek Olšák wrote: On Wed, Feb 3, 2016 at 5:37 PM, Roland Scheidegger wrote: Am 03.02.2016 um 10:38 schrieb Michel Dänzer: On 03.02.2016 18:29, Marek Olšák wrote: On Wed, Feb 3, 2016 at 10:19 AM, Michel Dänzer wrote: On 03.02.2016 05:15, Marek Olšák wrote: On Sat, Jan 30

Re: [Mesa-dev] [PATCH 1/2] draw: use util_pstipple_create_fragment_shader

Thanks for this this. Series looks good to me. Reviewed-by: Jose Fonseca Sorry for not replying sooner -- I missed it. (Unfortunately I haven't been able to keep up with mesa-dev traffic and if I'm not CC'ed the odds are I miss things.) Jose On 08/02/16 14:59, Nicol

Re: [Mesa-dev] [PATCH] mesa: fix incorrect viewport position when GL_CLIP_ORIGIN = GL_LOWER_LEFT

translate[2] = 0.5 * (n + f); Looks good. Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Are gallium unpack_rgba_8unorm/pack_rgba_8unorm safe for in-place conversion ?

On 09/02/16 19:17, Axel Davy wrote: Hi, We'd need to do some formats conversion in gallium nine, and if possible we would like to do them in-place. unpack_rgba_8unorm/pack_rgba_8unorm doesn't seem to explicitly allow in-place conversion, but the generated code seems to be fine with that. Can w

[Mesa-dev] [PATCH 1/3] configure: Eliminate MSVC2008 compatibility.

We no longer need to build any part of Mesa with Windows SDK 7.0.7600 or MSVC 2008. MSVC 2013 will be the oldest we support. In practice this means people are now free to declare variables in the middle of blocks, on the whole Mesa tree. Care should still be taken with variable length arrays and

[Mesa-dev] [PATCH 2/3] scons: Eliminate MSVC2008 compatibility.

--- scons/gallium.py | 16 src/gallium/auxiliary/SConscript | 2 +- src/gallium/auxiliary/pipe-loader/SConscript | 2 +- src/gallium/drivers/llvmpipe/SConscript | 2 +- src/gallium/drivers/softpipe/SConscript | 2 +- src/galliu

[Mesa-dev] [PATCH 3/3] include, gallium: Remove pre-MSVC 2013 compatibility.

--- Makefile.am | 1 - include/c99/inttypes.h| 305 -- include/c99/stdbool.h | 46 - include/c99/stdint.h | 247 include/c99_compat.h

Re: [Mesa-dev] [PATCH 3/3] include, gallium: Remove pre-MSVC 2013 compatibility.

On 11/02/16 22:13, Emil Velikov wrote: On 11 February 2016 at 13:02, Jose Fonseca wrote: --- Makefile.am | 1 - include/c99/inttypes.h| 305 -- include/c99/stdbool.h | 46 - include

Re: [Mesa-dev] [PATCH] glsl: replace _strtoui64() with strtoull() for MSVC

long long value = strtoull(digits, NULL, base); -#endif lval->n = (int)value; Looks good. Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: Use _aligned_malloc/free for MinGW too.

We already use these for gallium in src/gallium/auxiliary/os/os_memory_stdc.h and it's always better to minimize divergences between MinGW and MSVC. --- src/mesa/main/imports.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/mesa/main/imports.c b/src/mesa/main/impor

Re: [Mesa-dev] [PATCH] xlib: add support for GLX_ARB_create_context

On 29/03/16 21:44, Brian Paul wrote: On 03/29/2016 02:27 PM, Emil Velikov wrote: On 26 March 2016 at 17:45, Brian Paul wrote: This adds the glXCreateContextAttribsARB() function for the xlib/swrast driver. This allows more piglit tests to run with this driver. For example, without this patch

Re: [Mesa-dev] [RFCv3 01/11] gallium: refactor pipe_shader_state to support multiple IR's

On 31/01/16 20:16, Rob Clark wrote: The goal is to allow the pipe driver to request something other than TGSI, but detect whether what is getting is TGSI vs what it requested. The pipe drivers will always have to support TGSI (and convert that into whatever it is that they prefer), but in some ca

Re: [Mesa-dev] [RFCv3 01/11] gallium: refactor pipe_shader_state to support multiple IR's

On 30/03/16 14:43, Rob Clark wrote: On Wed, Mar 30, 2016 at 9:32 AM, Jose Fonseca wrote: On 31/01/16 20:16, Rob Clark wrote: The goal is to allow the pipe driver to request something other than TGSI, but detect whether what is getting is TGSI vs what it requested. The pipe drivers will

Re: [Mesa-dev] [RFCv3 01/11] gallium: refactor pipe_shader_state to support multiple IR's

On 30/03/16 14:59, Rob Clark wrote: On Wed, Mar 30, 2016 at 9:49 AM, Jose Fonseca wrote: On 30/03/16 14:43, Rob Clark wrote: On Wed, Mar 30, 2016 at 9:32 AM, Jose Fonseca wrote: On 31/01/16 20:16, Rob Clark wrote: The goal is to allow the pipe driver to request something other than

Re: [Mesa-dev] [PATCH] docs: remove docs/COPYING which contains GPL license

Thanks! Reviewed-by: Jose Fonseca I was about to do the same, but you beat me to it. What caused me pause was some recent talk I read somewhere of bringing back src/mesa/drivers/windows/gdi driver. I can no longer remember where. But I really rather not dealing with GPL/LPGL code, and all

[Mesa-dev] [PATCH] gallivm: Use vector selects on LLVM 3.4+.

This is an old patch I had around. Vector selects seem to work well from LLVM 3.4. Using them might improve code quality, as it might make constant propagation pass more effective. Tested lp_test_* --- src/gallium/auxiliary/gallivm/lp_bld_logic.c | 8 +--- 1 file changed, 5 insertions(+), 3

Re: [Mesa-dev] [PATCH] gallivm: Use vector selects on LLVM 3.4+.

On 01/04/16 00:04, Roland Scheidegger wrote: Am 01.04.2016 um 00:42 schrieb Jose Fonseca: This is an old patch I had around. Vector selects seem to work well from LLVM 3.4. Using them might improve code quality, as it might make constant propagation pass more effective. Tested lp_test_

Re: [Mesa-dev] [PATCH v2] math: Import isinf and others to global namespace

are not accessible any longer. v2: Move the fix outside of Nouveau, as suggested by Jose Fonseca, since anyone might need it when GCC switches to C++14 by default with GCC 6.0. Signed-off-by: Pierre Moreau --- include/cpp11_math.h| 61

Re: [Mesa-dev] [PATCH] docs: minor updates to license.html file

include/GL/glext.h Khronos include/GL/glxext.h +GLX client code src/glx/ SGI Free Software License B + C11 threadinclude/c11/threads*.h Boost (permissive) emulation Reviewed-by: Jose Fonseca ___ mesa-d

Re: [Mesa-dev] [PATCH 3/3] svga: remove unused svga_compile_key::texture_msaa field

nsigned texture_msaa:1;/**< A multisample texture? */ unsigned sprite_texgen:1; unsigned swizzle_r:3; unsigned swizzle_g:3; Series is Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org h

[Mesa-dev] [PATCH 1/2] gallivm: Use standard LLVMSetAlignment from LLVM 3.4 onwards.

Only provide a fallback for LLVM 3.3. One less dependency on LLVM C++ interface. --- src/gallium/auxiliary/draw/draw_llvm.c | 4 ++-- src/gallium/auxiliary/gallivm/lp_bld.h | 14 .../auxiliary/gallivm/lp_bld_format_aos_array.c| 2 +- src/gallium/auxiliar

[Mesa-dev] [PATCH 2/2] gallivm: Remove lp_build_load_volatile.

No longer needed. --- src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 8 src/gallium/auxiliary/gallivm/lp_bld_misc.h | 4 2 files changed, 12 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp index 61a50fa..c1e

[Mesa-dev] [PATCH] gallivm: Fix performance regressions due to vector selects.

LLVM often can't determine the mask elements are all ones/zeros, and there doesn't seem to be a good way to hint that. Thanks to Roland Scheidegger for spotting and analyzing the issue. --- src/gallium/auxiliary/gallivm/lp_bld_logic.c | 33 ++-- 1 file changed, 17 insertio

Re: [Mesa-dev] [PATCH 1/2] gallivm: Use standard LLVMSetAlignment from LLVM 3.4 onwards.

On 02/04/16 15:19, Brian Paul wrote: On 04/02/2016 08:13 AM, Jose Fonseca wrote: Only provide a fallback for LLVM 3.3. One less dependency on LLVM C++ interface. --- src/gallium/auxiliary/draw/draw_llvm.c | 4 ++-- src/gallium/auxiliary/gallivm/lp_bld.h | 14

[Mesa-dev] [PATCH 3/3] gallivm: Use llvm.fabs.

Exactly the same code. --- src/gallium/auxiliary/gallivm/lp_bld_arit.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c b/src/gallium/auxiliary/gallivm/lp_bld_arit.c index 1277743..587c83a 100644 --- a/src/gallium/auxiliar

[Mesa-dev] [PATCH 2/3] gallivm: Prefer backend agnostic intrinsic for rounding.

We could unconditionally use these instrinsics, but performance with SSE2 would suck, as LLVM falls back to calling libm. lp_test_arit. --- src/gallium/auxiliary/gallivm/lp_bld_arit.c | 46 - 1 file changed, 39 insertions(+), 7 deletions(-) diff --git a/src/gallium/au

[Mesa-dev] [PATCH 1/3] gallivm: Add debug option to force SSE2.

For simulating less capable machines. --- src/gallium/auxiliary/gallivm/lp_bld_init.c | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c b/src/gallium/auxiliary/gallivm/lp_bld_init.c index ab55be4..6e08ac4 10

Re: [Mesa-dev] [PATCH 2/3] gallivm: Prefer backend agnostic intrinsic for rounding.

On 03/04/16 16:20, Roland Scheidegger wrote: Am 03.04.2016 um 12:24 schrieb Jose Fonseca: We could unconditionally use these instrinsics, but performance with SSE2 would suck, as LLVM falls back to calling libm. Would that really work now? Last time I checked, calls out to libm from the jitted

[Mesa-dev] [PATCH] gallivm: Introduce lp_format_intrinsic.

For adding .v4f32 like suffixes to intrinsics, taking special care for scalar case, which was being often neglected. This fixes invalid IR when doing mipmap filtering on SSE2 (the only case where we'd use intrinsics with scalars.) --- src/gallium/auxiliary/gallivm/lp_bld_arit.c | 19 -

Re: [Mesa-dev] [PATCH] nir: Use PRIi64 and PRIu64 instead of %ld and %lu.

On 04/04/16 06:37, Jason Ekstrand wrote: On Apr 3, 2016 7:51 PM, "Kenneth Graunke" mailto:kenn...@whitecape.org>> wrote: > > %ld and %lu aren't the right format specifiers for int64_t and uint64_t > on 32-bit (x86) systems. They're %zu on Linux and %Iu on Windows. > > Use the standard C99

Re: [Mesa-dev] [PATCH] st/mesa: fix glReadBuffer() assertion failure

e == GL_NONE) { /* add the buffer */ st_manager_add_color_renderbuffer(st, fb, fb->_ColorReadBufferIndex); + _mesa_update_state(ctx); st_validate_state(st, ST_PIPELINE_RENDER); } } Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir: remove duplicate Makefile.sources

On 02/04/16 19:35, Rob Clark wrote: From: Rob Clark Allegedly this was needed still by scons build.. but in practice it doesn't seem to be needed. Removing it and running 'scons' results in no build errors. Signed-off-by: Rob Clark --- So, afaict NIR is not even built w/ scons build (I'm jus

Re: [Mesa-dev] [PATCH 12/26] glsl/shader_enums: Add the other two compute builtins

On 25/03/16 23:12, Jason Ekstrand wrote: These weren't added before because they are actually calculated values that are computed from other inputs. However, in order to handle them in nir_lower_system_values, it's nice for them to have a cannonical locaiton. --- src/compiler/shader_enums.c |

Re: [Mesa-dev] [PATCH] st/mesa: replace _mesa_sysval_to_semantic table with function

p; (1 << i)) { -unsigned semName = _mesa_sysval_to_semantic[i]; +unsigned semName = _mesa_sysval_to_semantic(i); t->systemValues[i] = ureg_DECL_system_value(ureg, semName, 0); Looks great. Thanks Brian. Reviewed-by: Jose Fonseca _

[Mesa-dev] [PATCH 2/4] svga: Use STATIC_ASSERT whenever possible.

--- src/gallium/drivers/svga/svga_pipe_depthstencil.c | 6 +++--- src/gallium/drivers/svga/svga_state_rss.c | 4 ++-- src/gallium/drivers/svga/svga_state_tss.c | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/gallium/drivers/svga/svga_pipe_depthstencil.c

[Mesa-dev] [PATCH 1/4] mesa: Use STATIC_ASSERT whenever possible.

--- src/mesa/main/imports.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c index 14cd588..fe54109 100644 --- a/src/mesa/main/imports.c +++ b/src/mesa/main/imports.c @@ -262,7 +262,7 @@ ffsll(long long int val) { int bit;

[Mesa-dev] [PATCH 3/4] softpipe: Use STATIC_ASSERT whenever possible.

--- src/gallium/drivers/softpipe/sp_tile_cache.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/softpipe/sp_tile_cache.c b/src/gallium/drivers/softpipe/sp_tile_cache.c index 9cc8ac1..c623326 100644 --- a/src/gallium/drivers/softpipe/sp_tile_cache.c +++

[Mesa-dev] [PATCH 4/4] gallium: Use STATIC_ASSERT whenever possible.

--- src/gallium/auxiliary/rtasm/rtasm_x86sse.c | 2 +- src/gallium/auxiliary/tgsi/tgsi_lowering.c | 2 +- src/gallium/auxiliary/tgsi/tgsi_parse.c| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/gallium/auxiliary/rtasm/rtasm_x86sse.c b/src/gallium/auxiliary/rtasm/rtas

[Mesa-dev] [PATCH 1/2] scons: Allow building with Address Sanitizer.

libasan is never linked to shared objects (which doesn't go well with -z,defs). It must either be linked to the main executable, or (more practically for OpenGL drivers) be pre-loaded via LD_PRELOAD. Otherwise works. I didn't find anything with llvmpipe. I suspect the fact that the JIT compiled

[Mesa-dev] [PATCH 2/2] softpipe: Free tgsi.image elements on context destruction.

Courtesy of address sanitizer. --- src/gallium/drivers/softpipe/sp_context.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/drivers/softpipe/sp_context.c b/src/gallium/drivers/softpipe/sp_context.c index f66fea2..1d62177 100644 --- a/src/gallium/drivers/softpipe/sp_context.c

Re: [Mesa-dev] [PATCH] st/mesa: fix memleak in glDrawPixels cache code

e(&sv[1], NULL); -#if !USE_DRAWPIXELS_CACHE + /* free the texture (but may persist in the cache) */ pipe_resource_reference(&pt, NULL); -#endif } Looks good AFAICT. Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: use llvm.nearbyint instead of llvm.round

On 13/04/16 04:00, srol...@vmware.com wrote: From: Roland Scheidegger We used to use sse roundps intrinsic directly, but switched to use the llvm intrinsics for rounding with e4f01da15d8c6ce3e8c77ff3ff3d2ce2574a3f7b. However, llvm semantics follows standard math lib round function which is spec

Re: [Mesa-dev] [PATCH v2] math: Import isinf and others to global namespace

On 01/04/16 13:18, Pierre Moreau wrote: On 01:11 PM - Apr 01 2016, Jose Fonseca wrote: On 31/03/16 23:08, Pierre Moreau wrote: Starting from C++11, several math functions, like isinf, moved into the std namespace. Since cmath undefines those functions before redefining them inside the

Re: [Mesa-dev] [PATCH] nv50/ra: `isinf()` is in namespace `std` since C++11

Pierre, I'm going to commit this one for now, as it seems the safest thing to do. I still think we should try to fix the generic case, but it seems much harder to get this right. I still don't understand how come isinf sometimes appears in the global namespace some times, but not others. Jo

Re: [Mesa-dev] [PATCH] gallivm: use llvm.nearbyint instead of llvm.round

On 13/04/16 06:51, Jose Fonseca wrote: On 13/04/16 04:00, srol...@vmware.com wrote: From: Roland Scheidegger We used to use sse roundps intrinsic directly, but switched to use the llvm intrinsics for rounding with e4f01da15d8c6ce3e8c77ff3ff3d2ce2574a3f7b. However, llvm semantics follows

Re: [Mesa-dev] [PATCH] nv50/ra: `isinf()` is in namespace `std` since C++11

generally, what was wrong with that one? Please read my reply this morning, on the thread "Re: [Mesa-dev] [PATCH v2] math: Import isinf and others to global namespace" Jose On Apr 13, 2016 3:07 AM, "Jose Fonseca" mailto:jfons...@vmware.com>> wrote: Pierre, I'm g

Re: [Mesa-dev] swr forces c++11 for whole compilation

On 13/04/16 11:43, Ilia Mirkin wrote: Hi Tim, It seems like building swr forces c++11 mode for the whole build, even other drivers being built that aren't necessarily ready for it. Unfortunately c++11 isn't backwards compatible with c++03, so the switch can't be made unilaterally. Could you have

Re: [Mesa-dev] swr forces c++11 for whole compilation

On 13/04/16 13:48, Jose Fonseca wrote: On 13/04/16 11:43, Ilia Mirkin wrote: Hi Tim, It seems like building swr forces c++11 mode for the whole build, even other drivers being built that aren't necessarily ready for it. Unfortunately c++11 isn't backwards compatible with c++03, so

Re: [Mesa-dev] [PATCH 1/2] scons: Allow building with Address Sanitizer.

On 13/04/16 14:41, Emil Velikov wrote: Hi Jose, On 12 April 2016 at 17:03, Jose Fonseca wrote: libasan is never linked to shared objects (which doesn't go well with -z,defs). It must either be linked to the main executable, or (more practically for OpenGL drivers) be pre-loade

Re: [Mesa-dev] swr forces c++11 for whole compilation

On 13/04/16 14:21, Ilia Mirkin wrote: On Wed, Apr 13, 2016 at 8:48 AM, Jose Fonseca wrote: On 13/04/16 11:43, Ilia Mirkin wrote: Hi Tim, It seems like building swr forces c++11 mode for the whole build, even other drivers being built that aren't necessarily ready for it. Unfortunately

<    4   5   6   7   8   9   10   11   12   13   >