Re: [Mesa-dev] [PATCH 2/2] gallium: pause queries for all meta ops

g along these lines or rather just have it per draw. Not sure which one would have less overhead neither... You should get some more feedback from other driver's authors but otherwise Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

Am 12.04.2016 um 00:30 schrieb Brian Paul: > Instead of using an array indexed by SYSTEM_VALUE_x, just use a > switch statement. This fixes a regression caused by inserting new > SYSTEM_VALUE_ enums but not updating the mapping to TGSI semantics. > --- >

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

Am 11.04.2016 um 23:50 schrieb Jose Fonseca: > 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

Re: [Mesa-dev] [PATCH 2/4] i965/tiled_memcpy: Move SSSE3 code back into inline functions.

Am 11.04.2016 um 21:05 schrieb Matt Turner: > This will make adding SSE2 code a lot cleaner. > --- > src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 42 > +++--- > 1 file changed, 24 insertions(+), 18 deletions(-) > > diff --git

Re: [Mesa-dev] [PATCH 1/4] i965/tiled_memcpy: Optimize RGBA -> BGRA swizzle.

es -= 4; > } > return dst; > FWIW mesa core has truckloads of similar per-byte load/swap/store functions for format conversions, which could be optimized similarly (or be done, hint hint, with sse2...). But nonethelss, looking good here. For the series (with some issue mentioned for 2

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

SYSTEM_VALUE_INSTANCE_INDEX here. (fwiw I find the names confusing - we have: SYSTEM_VALUE_VERTEX_ID - includes baseindex SYSTEM_VALUE_VERTEX_ID_ZERO_BASE - without baseindex SYSTEM_VALUE_INSTANCE_ID - without baseinstance SYSTEM_VALUE_INSTANCE_INDEX - includes baseinsta

Re: [Mesa-dev] Building Mesa and LLVM cross compiling Linux to Windows issue

I suspect you simply ran into an issue with old mesa and new llvm. Unfortunately some usage of the c++ abi of llvm is unavoidable, and the abi is unstable, thus breaking quite often. And we do not generally backport such fixes to older mesa releases (if only mostly because nobodoy would actually

Re: [Mesa-dev] tgsi_set_exec_mask?

Am 21.03.2016 um 03:08 schrieb Dave Airlie: > This appears to set some values into some temp register that we never > read from or look at again, > > should it be setting something that ExecMask gets set to at machine run time? > > just noticed it while trying to work out the various mask for

Re: [Mesa-dev] lvm pipe crash under windows

ry? > > Cheers > Jason > > On 17/03/2016 12:36 pm, "Jason Anderssen" <janders...@exactal.com> wrote: > >> Mesa version is 11.1.2 >> LVM - 3.4 >> Ill see what I can do regarding a gdb backtrace. >> >> Cheers >> Jason >> &g

Re: [Mesa-dev] [PATCH] scons: build osmesa swrast and gallium

Not that I really care what you can or can't build (and I won't comment on build changes), what are those features lacking in llvmpipe, beside from anisotropic filtering (which I always considered essentially useless for a software renderer, albeit interesting if you're curious about the math

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

Ah nice, I wasn't aware this would now work. For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 02.04.2016 um 16:13 schrieb Jose Fonseca: > Only provide a fallback for LLVM 3.3. > > One less dependency on LLVM C++ interface. > --- > src/gallium/auxil

Re: [Mesa-dev] [PATCH 4/6] gallium: add way for drivers to create fences without flushing

gestions if anyone has a better idea. But right > now this, plus maybe eventually ripping out the old way, seems like > the best plan. > > BR, > -R > > On Fri, Apr 1, 2016 at 8:03 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> I'll admit I'm not an expert on this but

Re: [Mesa-dev] [PATCH 1/3] r600: Change default behaviour for undefined COLOR0

Am 03.04.2016 um 10:11 schrieb Axel Davy: > d3d 9 needs COLOR0 to be 1.0 on all channels when > undefined. 0.0 for the others is fine. > GL behaviour is undefined. > > Signed-off-by: Axel Davy > --- > src/gallium/drivers/r600/r600_state.c | 4 > 1 file changed, 4

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

t; + util_snprintf(intrinsic, sizeof intrinsic, "llvm.fabs.v%uf%u", > type.length, type.width); > + return lp_build_intrinsic_unary(builder, intrinsic, vec_type, a); > } > > if(type.width*type.length == 128 && util_cpu_caps.has_ssse3) { > Looks like fabs was ne

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

} > + > + util_snprintf(intrinsic, sizeof intrinsic, "%s.v%uf%u", > +intrinsic_root, type.length, type.width); > + > + return lp_build_intrinsic_unary(builder, intrinsic, bld->vec_type, a); > + } > else /* (util_cpu_caps.has_altivec)

Re: [Mesa-dev] [PATCH 4/6] gallium: add way for drivers to create fences without flushing

Am 03.04.2016 um 02:31 schrieb Rob Clark: > On Sat, Apr 2, 2016 at 7:55 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> I don't really have anything against the new interface (though don't >> really feel qualified for a proper review), but it is indeed the >> exis

Re: [Mesa-dev] [PATCH 4/6] gallium: add way for drivers to create fences without flushing

Am 03.04.2016 um 17:05 schrieb Rob Clark: > On Sat, Apr 2, 2016 at 8:31 PM, Rob Clark <robdcl...@gmail.com> wrote: >> On Sat, Apr 2, 2016 at 7:55 PM, Roland Scheidegger <srol...@vmware.com> >> wrote: >>> I don't really have anything against the new int

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

ize, "%s.%c%u", name_root, c, width); > + } > +} > + > + > LLVMValueRef > lp_declare_intrinsic(LLVMModuleRef module, > const char *name, > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_intr.h > b/src/

Re: [Mesa-dev] [PATCH 1/3] r600: Change default behaviour for undefined COLOR0

Am 04.04.2016 um 14:04 schrieb Axel Davy: > On 03/04/2016 20:41, Roland Scheidegger wrote : >> Am 03.04.2016 um 10:11 schrieb Axel Davy: >>> d3d 9 needs COLOR0 to be 1.0 on all channels when >>> undefined. 0.0 for the others is fine. >>> GL behaviour is un

Re: [Mesa-dev] [PATCH 1/2] tgsi: collect texture sampler target info in tgsi_scan_shader()

Am 29.03.2016 um 22:39 schrieb Jose Fonseca: > On 29/03/16 21:22, Roland Scheidegger wrote: >> I actually think "is_tex" is a bit confusing (because there's lots of >> other parts in the code where we don't really distinguish between >> "texture" and

Re: [Mesa-dev] [PATCH 1/2] tgsi: collect texture sampler target info in tgsi_scan_shader()

ally it actually meant there'd be a texture token but we have that with sample instructions as well...) Roland For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 29.03.2016 um 21:41 schrieb Brian Paul: > Texture sample instructions specify a sampler unit and texture t

Re: [Mesa-dev] [PATCH 2/2] mesa: make _mesa_prepare_mipmap_level() static

l_context *ctx, > - struct gl_texture_object *texObj, GLuint level, > - GLsizei width, GLsizei height, GLsizei depth, > - GLsizei border, GLenum intFormat, mesa_format > format); > - > void >

Re: [Mesa-dev] [PATCH] tgsi: split tgsi_util_get_texture_coord_dim() function into two

nsigned num_coords = tgsi_util_get_texture_coord_dim(target, ); > + unsigned num_coords = tgsi_util_get_texture_coord_dim(target); > LLVMValueRef coords[4]; > LLVMValueRef tmp; > int chan; > @@ -3387,8 +3386,8 @@ static void tex_fetch_args( > unsigned target = inst->Texture.Texture; > LLVMValueRef coords[5], derivs[6]; > LLVMValueRef address[16]; > - int ref_pos; > - unsigned num_coords = tgsi_util_get_texture_coord_dim(target, _pos); > + unsigned num_coords = tgsi_util_get_texture_coord_dim(target); > + int ref_pos = tgsi_util_get_shadow_ref_src_index(target); > unsigned count = 0; > unsigned chan; > unsigned num_deriv_channels = 0; > Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] compiler/glsl: invalidate float suffixes for glsl 1.10

Am 31.03.2016 um 04:17 schrieb Ian Romanick: > Arg. :( > > It turns out that shaders in the game PlaneShift use float suffixes in > GLSL 1.10 shaders... at least the version of the shaders in our private > shader-db repo do. Once some one check to make sure the game still does > this, we will

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

r llvm versions had tendencies to lower things to scalars when things weren't directly doable with vector operations...). Hopefully it works on non-x86 backends too but we can't test this, so I'd say we just wait for the bug reports ;-). Reviewed-by: Roland Scheidegger <srol...@vmware.com> _

Re: [Mesa-dev] [PATCH 4/6] gallium: add way for drivers to create fences without flushing

I'll admit I'm not an expert on this but I got a bad feeling on it. Do you really need another per-context fence_finish function? This looks to me like rather than improving the existing api, it throws another one at the same problem, which is to be sort of used in parallel making things confusing

Re: [Mesa-dev] [PATCH 1/3] r600: Change default behaviour for undefined COLOR0

Am 04.04.2016 um 17:27 schrieb Axel Davy: > Le 04/04/2016 15:27, Roland Scheidegger a écrit : >> Am 04.04.2016 um 14:04 schrieb Axel Davy: >>> On 03/04/2016 20:41, Roland Scheidegger wrote : >>>> Am 03.04.2016 um 10:11 schrieb Axel Davy: >>>>> d3d

Re: [Mesa-dev] [PATCH 2/2] st/mesa: simplify st_generate_mipmap()

tLevel); > - } > - > - dstImage = _mesa_get_tex_image(ctx, texObj, target, dstLevel); > - if (!dstImage) { > - _mesa_error(ctx, GL_OUT_OF_MEMORY, "generating mipmaps"); > - return; > - } > - > - /* Free old image data */

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

Am 13.04.2016 um 12:12 schrieb Jose Fonseca: > On 13/04/16 06:51, Jose Fonseca wrote: >> On 13/04/16 04:00, srol...@vmware.com wrote: >>> From: Roland Scheidegger <srol...@vmware.com> >>> >>> We used to use sse roundps intrinsic directly, but s

Re: [Mesa-dev] ARB_framebuffer_no_attachments for llvm and soft pipes

Am 13.04.2016 um 03:35 schrieb eocallag...@alterapraxis.com: > On 2016-04-11 22:27, Roland Scheidegger wrote: >> Am 10.04.2016 um 09:41 schrieb Edward O'Callaghan: >>> All the piglits pass for these two as-is. However, some of the piglits >>> require SSBO support to ru

Re: [Mesa-dev] [PATCH] gallivm: Workaround LLVM PR 27332.

char intrinsic[32]; > + lp_format_intrinsic(intrinsic, sizeof intrinsic, "llvm.fabs", > vec_type); > + return lp_build_intrinsic_unary(builder, intrinsic, vec_type, a); > + } > } > > if(type.width*type.length == 128 && util_cpu_caps.has_sss

Re: [Mesa-dev] [PATCH] gallivm: make sampling more robust against bogus coordinates

ap to use Nans? We need to > use BGRA8 and something else (e.g., RGBA32F) to covert both AoS/SoA paths. Sounds like a good idea (I suppose though it's really only interesting for sw based drivers). Roland > > Jose > > > > On 22/04/16 14:33, srol...@vmware.com wrote: &g

Re: [Mesa-dev] [PATCH] glsl: Relax GLSL 1.10 float suffix error to a warning.

"); > } > yylval->real = _mesa_strtof(yytext, NULL); > return FLOATCONSTANT; > Sine I "voted" for warning instead of making it a driconf option, looks fine to me. Reviewed-by:

Re: [Mesa-dev] [PATCH 1/4] gallium: add bool return to pipe_context::end_query

I don't quite understand why this is necessary. Couldn't you just handle such failures in the driver easily? I can't quite see why informing the state tracker of it really helps. Roland Am 20.04.2016 um 17:43 schrieb Nicolai Hähnle: > From: Nicolai Hähnle > > Even when

Re: [Mesa-dev] [PATCH 1/4] scons: Move fallback HAVE_* definitions to headers.

linedocs/gcc-4.3.6/gcc/Other-Builtins.html */ > +# define HAVE___BUILTIN_BSWAP32 1 > +# define HAVE___BUILTIN_BSWAP64 1 > +#endif > + > +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5) > +# define HAVE___BUILTIN_UNREACHABLE 1 > +#endif &g

Re: [Mesa-dev] [PATCH 1/4] gallium: add bool return to pipe_context::end_query

Am 22.04.2016 um 18:22 schrieb Nicolai Hähnle: > On 22.04.2016 08:56, Roland Scheidegger wrote: >> I don't quite understand why this is necessary. >> Couldn't you just handle such failures in the driver easily? > > How? When we need a new query buffer due to

Re: [Mesa-dev] [PATCH 7/7] softpipe: add support for compute shaders.

Am 26.04.2016 um 23:18 schrieb Dave Airlie: > On 27 April 2016 at 06:07, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 26.04.2016 um 06:42 schrieb Dave Airlie: >>> From: Dave Airlie <airl...@redhat.com> >>> >>> This enables ARB_

Re: [Mesa-dev] [PATCH 7/7] softpipe: add support for compute shaders.

Am 27.04.2016 um 18:13 schrieb Jose Fonseca: > On 27/04/16 02:46, Roland Scheidegger wrote: >> Am 27.04.2016 um 03:05 schrieb Dave Airlie: >>> On 27 April 2016 at 11:00, Dave Airlie <airl...@gmail.com> wrote: >>>>>> So far I've set the execm

Re: [Mesa-dev] [PATCH 7/7] softpipe: add support for compute shaders.

Am 27.04.2016 um 22:45 schrieb Jose Fonseca: > On 27/04/16 18:48, Roland Scheidegger wrote: >> Am 27.04.2016 um 18:13 schrieb Jose Fonseca: >>> On 27/04/16 02:46, Roland Scheidegger wrote: >>>> Am 27.04.2016 um 03:05 schrieb Dave Airlie: >>>>>

Re: [Mesa-dev] [PATCH 2/2] softpipe: bump 3D texture limit to 2048

gt; #define SP_MAX_TEXTURE_CUBE_LEVELS 13 /* 4K x 4K */ > > > d3d10 actually requiers 2048 too. For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] softpipe: add support for compute shaders.

Am 27.04.2016 um 03:05 schrieb Dave Airlie: > On 27 April 2016 at 11:00, Dave Airlie wrote: So far I've set the execmask to 1 active channel, I'm contemplating changing that though and using less machines. >>> Ah yes, I think that would indeed be desirable. >> >>

Re: [Mesa-dev] [android-x86-devel] [RFC 0/7] android: enable llvmpipe for software rendering

Am 28.04.2016 um 17:52 schrieb Chih-Wei Huang: > I clearly understand this point. > Actually I've spent several days to try to > make it work on the master branch. > That's why it was delayed -- I supposed to send them > in the last week. > > However, the master branch is always broken for

Re: [Mesa-dev] [PATCH 1/4] gallium: add bool return to pipe_context::end_query

Am 22.04.2016 um 19:28 schrieb Nicolai Hähnle: > On 22.04.2016 11:52, Roland Scheidegger wrote: >> Am 22.04.2016 um 18:22 schrieb Nicolai Hähnle: >>> On 22.04.2016 08:56, Roland Scheidegger wrote: >>>> I don't quite understand why this is necessary. >>>&

Re: [Mesa-dev] [PATCH 01/29] mesa: Add gl_point_attrib::CoordReplaceBits bitfield.

Am 24.05.2016 um 08:41 schrieb mathias.froehl...@gmx.net: > From: Mathias Fröhlich > > The aim is to replace the CoordReplace array by > a bitfield. Until all drivers are converted, > establish the bitfield in paralell to the > CoordReplace array. > > Signed-off-by:

Re: [Mesa-dev] Add OpenSWR to GL3.txt?

Typically, if you expose the cap bits so that support for some extension is announced you'd consider it done. That does not necessarily mean that all the corresponding piglit tests are passing, but of course you should generally not announce support for features which don't really work (but you

Re: [Mesa-dev] [PATCH 03/39] llvmpipe: Fix overflow for 32 bits available memory computation

if (!os_get_total_physical_memory(_memory)) > return 0; > > +#ifdef PIPE_ARCH_X86 > + /* cap to 2 GB on 32 bits system */ > + system_memory = MIN2(system_memory, 2048); > +#endif > + >return (int)(system_memory >> 20); > } >

Re: [Mesa-dev] [PATCH 03/39] llvmpipe: Fix overflow for 32 bits available memory computation

Am 17.05.2016 um 20:16 schrieb Rob Herring: > On Tue, May 17, 2016 at 11:35 AM, Axel Davy wrote: >> On 16/05/2016 23:28, Rob Herring wrote: >>> >>> On Sun, May 15, 2016 at 5:45 AM, Axel Davy wrote: And cap to 2 GB on 32 bits. Fixes

Re: [Mesa-dev] [PATCH 09/11] tgsi: remove culldist semantic.

On 05/14/2016 04:24 PM, Ilia Mirkin wrote: On Sat, May 14, 2016 at 10:23 AM, Roland Scheidegger <srol...@vmware.com> wrote: Am 14.05.2016 um 14:55 schrieb Marek Olšák: Dave, It should be noted that clip distances can be disabled by pipe_rasterizer_state::clip_plane_enable, but cull dis

Re: [Mesa-dev] [PATCH 09/11] tgsi: remove culldist semantic.

gt; Our hardware only has 2 vec4 outputs. Each component can be configured > to be "clip distance", "cull distance", or "disabled" independently. > Ok. Roland > > On Sat, May 14, 2016 at 12:43 AM, Roland Scheidegger <srol...@vmware.com> > wro

Re: [Mesa-dev] ARB_cull_distance support v4?

Am 13.05.2016 um 06:41 schrieb Dave Airlie: > This is just the core patches, as I think the lowering was pretty > broken in the last couple of reposts. > > The lowering now lowers to one array of 8 or whatever. I need > to recheck the gallium and llvmpipe bits on top of this, as I think >

Re: [Mesa-dev] [PATCH 09/11] tgsi: remove culldist semantic.

my opinion is since we generally don't allow different semantics within the same reg, I see no good reason why we allow it here (and clip dists and cull dists, albeit somewhat similar, are still different). So, if some drivers wanted it in different regs and some in the same regs, I'd prefer it to be dif

Re: [Mesa-dev] ARB_cull_distance support v4?

Am 13.05.2016 um 23:12 schrieb Dave Airlie: > On 14 May 2016 at 01:12, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 13.05.2016 um 06:41 schrieb Dave Airlie: >>> This is just the core patches, as I think the lowering was pretty >>> broken in the last couple

Re: [Mesa-dev] [PATCH] gallium: enable intel jitevents profiling

ITEventListener *JEL = JITEventListener::createIntelJITEventListener(); >> + JIT->RegisterJITEventListener(JEL); >> +#endif >>if (JIT) { >> *OutJIT = wrap(JIT); >> return 0; >> -- >> 1.9.1 >> > I know nothing about how that interface works, but looks reasonable enough to me. Acked-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: print declarations of intrinsics with GALLIVM_DEBUG=ir

Am 10.05.2016 um 06:50 schrieb Jose Fonseca: > On 09/05/16 18:50, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> Those aren't really interesting, however outputting them is helpful when >> trying to feed the IR to llvm llc (or op

Re: [Mesa-dev] [PATCH 07/11] swr: [rasterizer] Interpolation utility functions

Am 14.04.2016 um 21:53 schrieb Tim Rowley: > --- > .../drivers/swr/rasterizer/common/simdintrin.h | 51 > -- > src/gallium/drivers/swr/rasterizer/core/frontend.h | 12 + > src/gallium/drivers/swr/rasterizer/core/state.h| 2 - > 3 files changed, 59 insertions(+),

Re: [Mesa-dev] [PATCH] st/mesa: fix sampler view leak in st_DrawAtlasBitmaps()

> > @@ -793,6 +797,8 @@ st_DrawAtlasBitmaps(struct gl_context *ctx, > > pipe_resource_reference(, NULL); > > + pipe_sampler_view_reference(, NULL); > + > /* We uploaded modified constants, need to invalidate them. */ > st->dirty.mesa |= _NEW_PROGRAM_CONSTANTS; > } > I don't thi

Re: [Mesa-dev] [PATCH v2 04/11] gallium: add endian_format field to struct pipe_resource

Am 14.04.2016 um 14:18 schrieb Oded Gabbay: > This patch adds a new field, called "endian_format", to > "struct pipe_resource". The new field is of type "enum pipe_endian" and > can receive one of two values: > - PIPE_ENDIAN_LITTLE > - PIPE_ENDIAN_NATIVE > > PIPE_ENDIAN_NATIVE is initialized to

Re: [Mesa-dev] [PATCH 3/4] [rfc] gallivm/llvmpipe dynamic samplers support.

Am 18.04.2016 um 04:49 schrieb Dave Airlie: > From: Dave Airlie > > This is a first attempt at adding support for dynamic indexing > of samplers to llvmpipe. This is needed for ARB_gpu_shader5 support. > > This uses the sampler function generator to generate functions > for

Re: [Mesa-dev] [PATCH 2/4] gallivm: prepare for dynamic texture sizes

lvmpipe/lp_tex_sample.c > @@ -91,7 +91,7 @@ static LLVMValueRef > lp_llvm_texture_member(const struct lp_sampler_dynamic_state *base, > struct gallivm_state *gallivm, > LLVMValueRef context_ptr, > - unsigned t

Re: [Mesa-dev] [PATCH 1/6] gallium: use enums in p_defines.h

Makes me wonder why we didn't use enums in the first place. But I can't think of any disadvantages. Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 16.04.2016 um 14:50 schrieb Marek Olšák: > From: Marek Olšák <marek.ol...@amd.com> > > and remove number assignments

Re: [Mesa-dev] [PATCH 4/6] gallium: use PIPE_SHADER_* everywhere, remove TGSI_PROCESSOR_*

Am 16.04.2016 um 14:50 schrieb Marek Olšák: > From: Marek Olšák > > we should use MESA_SHADER_* everywhere, but we're not ready for that yet > --- I think the idea initially was that tgsi is essentially self-contained: you can parse the token stream without any "external"

Re: [Mesa-dev] [PATCH 2/6] gallium: use enums in p_shader_tokens.h

Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 16.04.2016 um 14:50 schrieb Marek Olšák: > From: Marek Olšák <marek.ol...@amd.com> > > --- > src/gallium/include/pipe/p_shader_tokens.h | 303 > - > 1 file changed, 164 insertions(

Re: [Mesa-dev] [PATCH 3/6] gallium: merge PIPE_SWIZZLE_* and UTIL_FORMAT_SWIZZLE_*

Am 16.04.2016 um 14:50 schrieb Marek Olšák: > From: Marek Olšák > > Use PIPE_SWIZZLE_* everywhere. > Use X/Y/Z/W/0/1 instead of RED, GREEN, BLUE, ALPHA, ZERO, ONE. > The new enum is called pipe_swizzle. Using PIPE_SWIZZLE insteads sounds reasonable. Not sure though how I

Re: [Mesa-dev] [PATCH 2/2] radeonsi: Implement ddx/ddy on VI using ds_bpermute

Am 16.04.2016 um 15:19 schrieb eocallag...@alterapraxis.com: > On 2016-04-16 20:20, Marek Olšák wrote: >> On Sat, Apr 16, 2016 at 8:04 AM, Michel Dänzer >> wrote: >>> On 16.04.2016 14:51, Michel Dänzer wrote: On 16.04.2016 11:39, Tom Stellard wrote: > The ds_bpermute

Re: [Mesa-dev] [PATCH] gallivm: don't use vector selects with llvm 3.7

Am 17.04.2016 um 11:06 schrieb Jose Fonseca: > On 16/04/16 22:30, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> llvm 3.7 sometimes simply miscompiles vector selects. > > Reviewed-by: Jose Fonseca <jfons...@vmware.com>

Re: [Mesa-dev] [PATCH] gallivm: don't use vector selects with llvm 3.7

Am 18.04.2016 um 00:31 schrieb Emil Velikov: > Hi gents, > > On 17 April 2016 at 10:06, Jose Fonseca <jfons...@vmware.com> wrote: >> On 16/04/16 22:30, srol...@vmware.com wrote: >>> >>> From: Roland Scheidegger <srol...@vmware.com> >>> &g

Re: [Mesa-dev] [PATCH 1/9] gallivm: Use LLVMPrintValueToString where available.

Series looks great to me. Thanks for the cleanup. Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 18.04.2016 um 11:14 schrieb Jose Fonseca: > And llvm::raw_string_ostream where not (LLVM 3.3). > > Thereby eliminating yet another dependency on unstable LLVM interfaces.

Re: [Mesa-dev] [PATCH 1/4] gallivm: convert size query to using a set of parameters.

unsigned target, > -LLVMValueRef context_ptr, > -boolean is_sviewinfo, > -enum lp_sampler_lod_property lod_property, > -LLVMValueRef explicit_lod, > -

Re: [Mesa-dev] [PATCH 4/4] appveyor: Run unit tests.

ks good to me, though I'm not really all that familiar with any of it. Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] [rfc] gallivm/llvmpipe dynamic samplers support.

Am 18.04.2016 um 23:10 schrieb Dave Airlie: > On 19 April 2016 at 03:40, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 18.04.2016 um 04:49 schrieb Dave Airlie: >>> From: Dave Airlie <airl...@redhat.com> >>> >>> This is a first attempt at add

Re: [Mesa-dev] [PATCH] glsl: add forgotten textureOffset function for sampler2DArrayShadow

Am 19.04.2016 um 00:43 schrieb Ian Romanick: > On 04/18/2016 02:05 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> This was part of EXT_gpu_shader4 - as such it should have been supported >> by glsl 130. >> It was however

Re: [Mesa-dev] [PATCH 2/2] tgsi/lowering: add support to lower CEIL

Am 13.04.2016 um 22:51 schrieb Christian Gmeiner: > Signed-off-by: Christian Gmeiner > --- > src/gallium/auxiliary/tgsi/tgsi_lowering.c | 54 > ++ > src/gallium/auxiliary/tgsi/tgsi_lowering.h | 1 + > 2 files changed, 55 insertions(+) >

Re: [Mesa-dev] [PATCH 7/7] softpipe: add support for compute shaders.

t pipe_screen *_screen, > + enum pipe_shader_ir ir_type, > + enum pipe_compute_cap param, > + void *ret) > +{ > + switch (param) { > + case PIPE_COMPUTE_CAP_IR_TARGET: > +

Re: [Mesa-dev] [PATCH 1/5] gallivm: add helper lp_add_attr_dereferenceable

Am 12.07.2016 um 22:52 schrieb Marek Olšák: > From: Marek Olšák > > Not sure if this is the right way to do it, but it seems to work. > --- > src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 9 + > src/gallium/auxiliary/gallivm/lp_bld_misc.h | 3 +++ > 2 files

Re: [Mesa-dev] GLSL Debugging

Am 14.07.2016 um 15:25 schrieb Rob Conde: > Hello, > >It occurred to me that the llvmpipe might be a good basis for a GLSL > debugger. Has anyone thought about this and how it might be approached? > > > Rob Conde I'm not entirely sure what exactly you want to debug, but if you just want to

Re: [Mesa-dev] [PATCH 1/3] gallium: split transfer_inline_write into buffer and texture callbacks

ons that looks good (plus, buffers and textures are quite different indeed). (We'll have some code to adapt of course, but this should be trivial.) So, Acked-by: Roland Scheidegger <srol...@vmware.com> > > Marek > > On Mon, Jul 18, 2016 at 2:25 PM, Marek Olšák <mar...@g

Re: [Mesa-dev] [PATCH 2/7] gallium/auxiliary: Add u_bitcast.h header.

Am 29.07.2016 um 00:35 schrieb Matt Turner: > --- > src/gallium/auxiliary/Makefile.sources | 1 + > src/gallium/auxiliary/util/u_bitcast.h | 57 > ++ > 2 files changed, 58 insertions(+) > create mode 100644 src/gallium/auxiliary/util/u_bitcast.h > > diff --git

Re: [Mesa-dev] [PATCH 2/7] gallium/auxiliary: Add u_bitcast.h header.

1UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=yFSuLWBBbLWZDrPaxDVOCjO0cX88sn16LdG-wdamPNQ=vIzvE6OQ57S1mnD6755iC9AOD57xXqJKUGtsk_DKBhs= > > > Look especially at footnote 85 of 6.5.2.3. > > Regards, > Gustaw Smolarczyk > > 2016-07-29 15:22 GMT+02:00 Roland Scheidegger <srol...@vmware.com>: >

Re: [Mesa-dev] [PATCH 2/7] gallium/auxiliary: Add u_bitcast.h header.

Am 29.07.2016 um 06:55 schrieb Connor Abbott: > On Thu, Jul 28, 2016 at 7:58 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 29.07.2016 um 00:35 schrieb Matt Turner: >>> --- >>> src/gallium/auxiliary/Makefile.sources | 1 + >>>

Re: [Mesa-dev] [PATCH mesa] gallium/util: fix resource leak

This looks very bogus to me. How is this supposed to work if you immediately close the library again? The functions are still going to get used. This just segfaults right, left and center. If you want to fix this for real, some util_format_s3tc_exit() is probably needed, albeit I'm not entirely

Re: [Mesa-dev] [PATCH v2 1/2] gallium/util: add helper to compute zmin/zmax for a viewport state

Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 14.08.2016 um 19:09 schrieb Ilia Mirkin: > Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> > Cc: "11.2 12.0" <mesa-sta...@lists.freedesktop.org> > --- > src/gallium/auxiliary/Makefile.source

Re: [Mesa-dev] [PATCH 1/3] gallium: change pipe_sampler_view::first_element/last_element -> offset/size

I can't say I'm a big fan of this. From an "api cleanness" point of view, defining things in elements makes more sense imho. This is due to the GL api though which uses generic buffer api to turn buffers into textures which can be sampled (somewhat different to what d3d10 does). Can't you just say

Re: [Mesa-dev] [PATCH 1/5] gallivm: add helper lp_add_attr_dereferenceable

.h > @@ -73,6 +73,9 @@ lp_get_default_memory_manager(); > extern void > lp_free_memory_manager(LLVMMCJITMemoryManagerRef memorymgr); > > +extern void > +lp_add_attr_dereferenceable(LLVMValueRef val, uint64_t bytes); > + > #ifdef __cplusplus > } > #endif > Re

Re: [Mesa-dev] [PATCH] gallium: Fix blend color alignment for 32-bit systems

Am 12.07.2016 um 13:40 schrieb Nicolai Hähnle: > From: Nicolai Hähnle > > This fixes a regression introduced by commit d8d6091a8. > > Heap allocations may be only 8-byte aligned on 32-bit system, and so having > members with 16-byte alignment (such as in the case where

Re: [Mesa-dev] [PATCH] gallium: Force blend color to 16-byte alignment

; > }; > I'm wondering if that's really needed. I have a difficult time to imagine setting blend color is performance critical. And driver internal you can obviously still align pipe_blend_color structs yourself. But OTOH, why not... Acked-by: Roland Scheidegger <srol...@vmware

Re: [Mesa-dev] [PATCH] gallivm: set LLVMNoUnwindAttribute on all intrinsics

Am 05.07.2016 um 11:36 schrieb Marek Olšák: > From: Marek Olšák > > RadeonSI stats: Mostly 0% difference, but Valley shows a small improvement: > > ApplicationFilesSGPRs VGPRs SpillSGPR SpillVGPR Code > SizeLDSMax Waves Waits >

Re: [Mesa-dev] [PATCH 1/5] swr: [rasterizer] add support for llvm-3.9

Am 06.07.2016 um 23:51 schrieb Tim Rowley: > --- > .../drivers/swr/rasterizer/jitter/builder_misc.cpp | 38 > -- > .../jitter/scripts/gen_llvm_ir_macros.py | 5 --- > 2 files changed, 28 insertions(+), 15 deletions(-) > > diff --git

Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture (v2)

Yes, these commands are modelled after d3d10 clears (the only d3d10 clear methods are clear_rt/clear_dsv), so gallium at some point only had the "ordinary" clear (useful for d3d9 and gl, but doesn't cover everything neither). It is unfortunate all apis handle clear differently. Making them

Re: [Mesa-dev] [PATCH 1/3] gallium: add render_condition_enable param to clear_render_target/depth_stencil

Am 09.08.2016 um 00:59 schrieb Marek Olšák: > From: Marek Olšák > > --- > src/gallium/auxiliary/util/u_clear.h| 5 +++-- > src/gallium/auxiliary/vl/vl_bicubic_filter.c| 2 +- > src/gallium/auxiliary/vl/vl_compositor.c| 2 +- >

Re: [Mesa-dev] [PATCH 2/3] gallivm: add lp_build_alloca_undef

d_alloca_undef, but do not zero-initialize the variable. Like lp_build_alloca For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> > + */ > +LLVMValueRef > +lp_build_alloca_undef(struct gallivm_state *gallivm, > + LLVMTypeRef type, > +

Re: [Mesa-dev] [PATCH 4/6] util/rgb9e5: Get rid of the float754 union

what we were doing with the union was float <-> uint32_t bitcasts > and the remaining 10% can be done with a sinmple left-shift by 23. simple For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> > > Signed-off-by: Jason Ekstrand <ja...@jlekstrand.net>

Re: [Mesa-dev] [PATCH 1/2] mesa: Drop -fno-builtin-memcmp.

Am 01.07.2016 um 00:59 schrieb Matt Turner: > According to the referenced bug report, gcc-4.5 and newer do not inline > memcmp(). I see no difference in performance of ipers with llvmpipe on a > Sandybridge (which does not have "Enhanced REP MOVSB/STOSB") by removing > this flag. > > I attempted

Re: [Mesa-dev] [PATCH] gallium/util: check for window cliprects in util_can_blit_via_copy_region()

& mask) != mask || > blit->filter != PIPE_TEX_FILTER_NEAREST || > blit->scissor_enable || > + blit->num_window_rectangles > 0 || > blit->alpha_blend) { >return FALSE; > } > Reviewed-by: Roland Scheidegger <srol...@vmware

Re: [Mesa-dev] [PATCH v2] gallium: Force blend color to 16-byte alignment

ation and added a lengthy comment explaining the > reason for the alignment. > > Reported-by: Tim Rowley <timothy.o.row...@intel.com> > Tested-by: Tim Rowley <timothy.o.row...@intel.com> > Signed-off-by: Chuck Atkins <chuck.atk...@kitware.com> > Acked-by: Roland Sc

Re: [Mesa-dev] [PATCH 02/16] util: simplify a few things in util_can_blit_via_copy_region()

35,6 @@ util_can_blit_via_copy_region(const struct pipe_blit_info > *blit) >return FALSE; > } > > - if (blit->alpha_blend) > - return FALSE; > - > return TRUE; > } > > Now that you've simplified this, it looks to me like it should a

Re: [Mesa-dev] [PATCH 05/16] svga: don't advertise support for R32G32B32_UINT/SINT surface formats

MAT_A8_UINT, SVGA3D_FORMAT_INVALID, > SVGA3D_FORMAT_INVALID, 0 }, > { PIPE_FORMAT_I8_UINT, SVGA3D_FORMAT_INVALID, > SVGA3D_FORMAT_INVALID, 0 }, > I don't doubt that it didn't work, but I don't quite understand the reasoning - R32G32B32_FLOAT seems to be s

Re: [Mesa-dev] Samping GL_R32UI?

Am 01.02.2017 um 05:32 schrieb Andrew A.: > Are there any known issues with using usampler2D on a GL_R32UI texture > in llvmpipe from within a VS/FS? I'm getting expected results on > Nvidia drivers (proprietary), but not with mesa llvmpipe (always get > zero). Not that I know of. There should be

Re: [Mesa-dev] [PATCH 1/5] gallium/u_inlines: fix member access within null pointer

good idea - basically the idea is that reference counting is used everywhere, so it should be as cheap as possible. (Note that this is used in a lot of places with an explicit NULL pointer as the second argument, and noone has ever claimed it caused actual issues.) Roland > > Cheers, > Nicola

Re: [Mesa-dev] [PATCH 1/5] gallium/u_inlines: fix member access within null pointer

I'm not quite sure there's really a bug here? As far as I can tell, these functions are architected specifically to look like that - they do not actually dereference potential null pointers, but only take the address in the end. This change seems to add some overhead. Roland Am 07.02.2017 um

Re: [Mesa-dev] [PATCH 1/5] gallium/u_inlines: fix member access within null pointer

__((no_sanitize("undefined"))) ? > > On Wed, Feb 8, 2017 at 3:48 PM, Roland Scheidegger <srol...@vmware.com > <mailto:srol...@vmware.com>> wrote: > > Am 08.02.2017 um 10:21 schrieb Nicolai Hähnle: > > On 07.02.2017 23:00, Brian Paul wrote: >

<    10   11   12   13   14   15   16   17   18   19   >