Re: [Mesa-dev] [PATCH] st/mesa: Map packed gallium formats to packed mesa formats.

Am 08.08.2015 um 23:26 schrieb Jason Ekstrand: > On Sat, Aug 8, 2015 at 2:14 PM, Roland Scheidegger wrote: >> Am 08.08.2015 um 22:45 schrieb Jason Ekstrand: >>> Mesa formats and gallium formats are defined a bit differently. In mesa >>> there are "packed"

Re: [Mesa-dev] [PATCH 1/3] util: Cope with LONG_BIT not being defined on Windows.

_mm_load_sd(&x)); > -#elif LONG_BIT == 32 > +#elif LONG_BIT == 32 || defined(_WIN32) > return _mm_cvtsd_si32(_mm_load_sd(&x)); > +#else > +#error "Unsupported or undefined LONG_BIT" > #endif > #else > return lrint(x); > For the series: Reviewed-by:

Re: [Mesa-dev] [PATCH] st/mesa: Map packed gallium formats to packed mesa formats.

Am 09.08.2015 um 12:11 schrieb Oded Gabbay: > On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote: >> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote: >>> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand >>> wrote: >>> >>> If I understand your patch, instead of using the endian-dependent >>>

Re: [Mesa-dev] [PATCH 3/3] util: Use SSE rounding on all platforms that support it.

Am 09.08.2015 um 18:47 schrieb Matt Turner: > On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca wrote: >> As currently only GCC x86_64 builds where using it. >> --- >> src/util/rounding.h | 16 +--- >> 1 file changed, 13 insertions(+), 3 deletions(-) >> >> diff --git a/src/util/rounding.h

Re: [Mesa-dev] [PATCH 3/3] util: Use SSE rounding on all platforms that support it.

Forgot to mention, strictly speaking only __SSE__ is necessary for _mesa_lroundevenf, so it would work on these shiny Pentium 3 and Athlon XP... The double version (though it's unused) however requires __SSE2__. Roland Am 09.08.2015 um 19:23 schrieb Roland Scheidegger: > Am 09.08.2015

Re: [Mesa-dev] [PATCH 1/3] util: Cope with LONG_BIT not being defined on Windows.

Am 09.08.2015 um 20:08 schrieb Jose Fonseca: > On 09/08/15 17:47, Matt Turner wrote: >> On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca wrote: >>> Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a >>> problem as >>> it doesn't define __x86_64__ macro (it's GCC specific.) >>> >>> Howev

Re: [Mesa-dev] [PATCH] util: Use LONG_MAX instead of LONG_BIT.

Looks good to me. Would have been much less trouble if we'd just returned an int, to hell with lrintf's long return type no callers will care about the long returned anyway... Reviewed-by: Roland Scheidegger Am 09.08.2015 um 23:40 schrieb Jose Fonseca: > More portable. Ba

Re: [Mesa-dev] [PATCH] st/mesa: Map packed gallium formats to packed mesa formats.

Am 10.08.2015 um 07:00 schrieb Jason Ekstrand: > On Sun, Aug 9, 2015 at 6:46 AM, Roland Scheidegger wrote: >> Am 09.08.2015 um 12:11 schrieb Oded Gabbay: >>> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote: >>>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wr

Re: [Mesa-dev] [PATCH] mesa/format_utils: Add src_bits == dst_bits cases to [us]norm functions

ed src_bits, unsigned > dst_bits) >return -MAX_INT(dst_bits); > else if (src_bits < dst_bits) >return EXTEND_NORMALIZED_INT(x, src_bits - 1, dst_bits - 1); > - else > + else if (src_bits > dst_bits) >return x >> (src_bits - dst_bits); > +

Re: [Mesa-dev] [PATCH] gallium: add support for GLES texture float extensions

FWIW d3d10 has the same requirements, the "any filter" needs to be supported for half float formats, but is optional for float formats (d3d10.1 made it required for floats). https://msdn.microsoft.com/en-us/library/windows/desktop/cc627090%28v=vs.85%29.aspx So there might well be some more hw where

Re: [Mesa-dev] [PATCH] gallium: add support for GLES texture float extensions (v2)

Makes sense. Reviewed-by: Roland Scheidegger Am 12.08.2015 um 12:45 schrieb Marek Olšák: > From: Marek Olšák > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74329 > > v2: add a CAP for half floats > drivers should not expose the CAPs if they don

Re: [Mesa-dev] [PATCH 1/4] gallium: add an interface for EXT_depth_bounds_test

I guess the question is if those depth bounds floats should be in the dsa state or set separately. That would mostly depend on if you expect frequent changes to the values or not, at least that's the pattern usually followed. Either way though looks ok to me. Reviewed-by: Roland Scheidegger

Re: [Mesa-dev] [PATCH] i965: Don't tell the hardware about our UAV access.

I guess though you'd need these bits when implementing things like ARB_fragment_shader_ordering? (Thus stuff actually looks useful but I don't know if anybody wants to implement it in the near term.) Roland Am 14.08.2015 um 18:27 schrieb Francisco Jerez: > The hardware documentation relating to

Re: [Mesa-dev] [PATCH] scons: Always define __STDC_LIMIT_MACROS.

I'm hardly a build expert, but looks good to me. Reviewed-by: Roland Scheidegger Am 15.08.2015 um 00:22 schrieb Vinson Lee: > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91591 > Signed-off-by: Vinson Lee > --- > scons/gallium.py | 1 + > 1 file changed, 1 in

Re: [Mesa-dev] [PATCH 2/2] gallium/auxiliary: optimize rgb9e5 helper some more

Ping? Am 09.08.2015 um 17:28 schrieb srol...@vmware.com: > From: Roland Scheidegger > > I used this as some testing ground for investigating some compiler > bits initially (e.g. lrint calls etc.), figured I could do much better > in the end just for fun... > This is mathema

Re: [Mesa-dev] [PATCH 7/9] softpipe: don't use 3-component formats

Am 25.08.2015 um 01:08 schrieb Ilia Mirkin: > On Mon, Aug 24, 2015 at 7:04 PM, Brian Paul wrote: >> Mesa and gallium don't have a complete set of matching 3-component >> texture formats. For example, 8-bit sRGB unorm. To fully support >> the GL_ARB_copy_image extension we need to have support fo

Re: [Mesa-dev] [PATCH] st/mesa: only enable MSAA coverage options when we have a MSAA buffer

date_state(struct gl_context * ctx, > GLbitfield new_state) > struct st_context *st = st_context(ctx); > > if (new_state & _NEW_BUFFERS) { > - st->dirty |= ST_NEW_DSA | > + st->dirty |= ST_NEW_BLEND | > + ST_

Re: [Mesa-dev] [PATCH] st/mesa: update comment in st_atom_msaa.c

mebuffer); > > if (st->ctx->Multisample.Enabled && sample_count > 1) { > - /* unlike in gallium/d3d10 the mask is only active if msaa is enabled */ > + /* unlike in gallium/d3d10 the mask is only active if msaa is enabled > */ >if (st->ctx->Multisample.Sa

Re: [Mesa-dev] [PATCH] gallium/docs: document alpha_to_coverage and alpha_to_one blend state

ense (albeit we don't do that for d3d10 - maybe this behavior isn't tested). But in any case, this documentation is an improvement. (alpha_to_one is not possible with d3d10, therefore the semantics could be different, but it probably makes sense it follows the same rules.) Reviewed-by:

Re: [Mesa-dev] [PATCH 1/9] gallium: add opcode and types for 64-bit integers. (v2)

Am 16.09.2016 um 15:48 schrieb Nicolai Hähnle: > From: Dave Airlie > > This just adds the basic support for 64-bit opcodes, > and the new types. > > v2: add conversion opcodes. > add documentation. > > Reviewed-by: Marek Olšák > Reviewed-by: Nicolai Hähnle > Signed-off-by: Dave Airlie > ---

Re: [Mesa-dev] [PATCH] st/mesa: only enable MSAA coverage options when we have a MSAA buffer

We can't change how gallium is supposed to behave since other apis rely on coverage-to-alpha working even if msaa is disabled. Roland Am 16.09.2016 um 18:58 schrieb Ilia Mirkin: > FTR, the new piglit test passed as-is on NVIDIA hw (at least nv50 and > nvc0). I'm not opposed to this new state depe

Re: [Mesa-dev] [PATCH v2 1/6] gallium: add opcode and types for 64-bit integers. (v3)

> 0) ? 1 : 0 > + dst.zw = (src0.zw < 0) ? -1 : (src0.zw > 0) ? 1 : 0 > + > +.. opcode:: U64ADD - 64-bit Integer Add > + > +.. math:: > + > + dst.xy = src0.xy + src1.xy > + dst.zw = src0.zw + src1.zw > + > +.. opcode:: U64MUL - 64-bit Integer Multiply > + >

Re: [Mesa-dev] [PATCH v2 4/6] gallivm/llvmpipe: prepare support for ARB_gpu_shader_int64.

ED || > + stype == TGSI_TYPE_DOUBLE || > + stype == TGSI_TYPE_SIGNED64 || > + stype == TGSI_TYPE_UNSIGNED64) { >struct lp_build_context *bld_fetch = stype_to_fetch(bld_base, stype); >res = LLVMBuildBitCast(builder, res, bld_fetch->vec_type, ""); > } > > return res; > } > > static LLVMValueRef > emit_fetch_system_value( > struct lp_build_tgsi_context * bld_base, > @@ -3038,20 +3056,22 @@ void lp_emit_immediate_soa( > const uint size = imm->Immediate.NrTokens - 1; > assert(size <= 4); > switch (imm->Immediate.DataType) { > case TGSI_IMM_FLOAT32: >for( i = 0; i < size; ++i ) > imms[i] = > lp_build_const_vec(gallivm, bld_base->base.type, > imm->u[i].Float); > >break; > case TGSI_IMM_FLOAT64: > + case TGSI_IMM_UINT64: > + case TGSI_IMM_INT64: > case TGSI_IMM_UINT32: >for( i = 0; i < size; ++i ) { > LLVMValueRef tmp = lp_build_const_vec(gallivm, > bld_base->uint_bld.type, imm->u[i].Uint); > imms[i] = LLVMConstBitCast(tmp, bld_base->base.vec_type); >} > >break; > case TGSI_IMM_INT32: >for( i = 0; i < size; ++i ) { > LLVMValueRef tmp = lp_build_const_vec(gallivm, > bld_base->int_bld.type, imm->u[i].Int); > @@ -3895,20 +3915,32 @@ lp_build_tgsi_soa(struct gallivm_state *gallivm, > lp_build_context_init(&bld.bld_base.base, gallivm, type); > lp_build_context_init(&bld.bld_base.uint_bld, gallivm, > lp_uint_type(type)); > lp_build_context_init(&bld.bld_base.int_bld, gallivm, lp_int_type(type)); > lp_build_context_init(&bld.elem_bld, gallivm, lp_elem_type(type)); > { >struct lp_type dbl_type; >dbl_type = type; >dbl_type.width *= 2; >lp_build_context_init(&bld.bld_base.dbl_bld, gallivm, dbl_type); > } > + { > + struct lp_type uint64_type; > + uint64_type = lp_uint_type(type); > + uint64_type.width *= 2; > + lp_build_context_init(&bld.bld_base.uint64_bld, gallivm, uint64_type); > + } > + { > + struct lp_type int64_type; > + int64_type = lp_int_type(type); > + int64_type.width *= 2; > + lp_build_context_init(&bld.bld_base.int64_bld, gallivm, int64_type); > + } > bld.mask = mask; > bld.inputs = inputs; > bld.outputs = outputs; > bld.consts_ptr = consts_ptr; > bld.const_sizes_ptr = const_sizes_ptr; > bld.sampler = sampler; > bld.bld_base.info = info; > bld.indirect_files = info->indirect_files; > bld.context_ptr = context_ptr; > bld.thread_data_ptr = thread_data_ptr; > diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.h > b/src/gallium/auxiliary/tgsi/tgsi_info.h > index 8830f5a..e60888f 100644 > --- a/src/gallium/auxiliary/tgsi/tgsi_info.h > +++ b/src/gallium/auxiliary/tgsi/tgsi_info.h > @@ -98,21 +98,22 @@ enum tgsi_opcode_type { > TGSI_TYPE_UNSIGNED, > TGSI_TYPE_SIGNED, > TGSI_TYPE_FLOAT, > TGSI_TYPE_DOUBLE, > TGSI_TYPE_UNSIGNED64, > TGSI_TYPE_SIGNED64, > }; > > static inline bool tgsi_type_is_64bit(enum tgsi_opcode_type type) > { > - if (type == TGSI_TYPE_DOUBLE) > + if (type == TGSI_TYPE_DOUBLE || type == TGSI_TYPE_UNSIGNED64 || > + type == TGSI_TYPE_SIGNED64) >return true; > return false; > } > > enum tgsi_opcode_type > tgsi_opcode_infer_src_type( uint opcode ); > > enum tgsi_opcode_type > tgsi_opcode_infer_dst_type( uint opcode ); > > There's a couple bogus comments wrt opcode names marked above - either fix them up or drop the comment. Otherwise, for 2-4, Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: add comment on util_is_format_compatible()

_desc) > Otherwise looks good to me. (Though I'm always thinking this doesn't really do the right thing, since you can't determine if formats are compatible with resource_copy_region as the unorm/uint/float etc. foramts aren't compatible here. But this is how it has to work for now...) Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i915g: fix incorrect gl_FragCoord value

this) and Stéphane (the author of > this driver). > > Gents, any input on the above ? Oh, I wasn't aware I broke this... This looks to me like before my patch there i915g was indeed just relying on draw code redirecting undefined inputs to 0, which near certainly was unsp

Re: [Mesa-dev] mesa/llvmpipe select alpha visual

Am 30.09.2016 um 01:49 schrieb Thomas Søndergaard: > My application window becomes transparent when I run my application with > llvmpipe by setting LD_LIBRARY_PATH instead of the proprietary NVIDIA > driver that I otherwise use. I've come to the understanding, after > digging into the code for a fe

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

I don't think that's really a good idea. Zero-initializing things is one thing, but explicitly overwrite things which were given to the driver by the st is something else. (I'm not even sure how it works if the driver always overwrites this to zero no matter what. Well I suppose those are the conse

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

is a bit hand-wavey, ie. w/ things like prsc->screen > overwriten by driver.. I guess I can try to track down the > screen->resource_create() callers that aren't zero-init'ing the templ, > although the # of callers seemed much higher than # of drivers > > BR, > -R &g

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

s out to be the more reasonable thing.. > > BR, > -R > > On Mon, Oct 3, 2016 at 12:53 PM, Roland Scheidegger > wrote: >> In an ideal world everybody would zero-intialize the template I suppose >> - then it would easily survive such interface changes. >> I

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

mited and they are easy to find. > > Marek > > On Tue, Oct 4, 2016 at 1:45 AM, Roland Scheidegger wrote: >> Sounds reasonable to me. >> >> Roland >> >> Am 04.10.2016 um 01:44 schrieb Rob Clark: >>> There are a lot of callers for ->resource_cr

Re: [Mesa-dev] [PATCH] gallium/drivers: initialize pipe_resource::next to NULL

Am 04.10.2016 um 03:16 schrieb Michel Dänzer: > On 04/10/16 01:53 AM, Roland Scheidegger wrote: >> In an ideal world everybody would zero-intialize the template I suppose >> - then it would easily survive such interface changes. > > As long as there are no fields where

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

use something which works on all 32bit archs, not just x86. We don't have a define for that I think, so maybe just use sizeof(void *) == 4 or something like that (of course, it can't be an ifdef then, but that shouldn't matter). Also, this code is identical to the one in softpipe

Re: [Mesa-dev] [PATCH 3/3] softpipe: Cap to 2 GB on 32 bits

t application memory, which is quite limited on 32 bits. App > + * shouldn't expect too much available memory. */ > + system_memory = MIN2(system_memory, 2048 << 20); > + >return (int)(system_memory >> 20); >

Re: [Mesa-dev] [PATCH 20/75] st/nine: Initial ProcessVertices support

Am 07.10.2016 um 00:33 schrieb Axel Davy: > On 06/10/2016 22:28, Ilia Mirkin wrote: >> On Thu, Oct 6, 2016 at 4:24 PM, Axel Davy wrote: >>> On 05/10/2016 22:08, Axel Davy wrote: HRESULT NINE_WINAPI NineDevice9_ProcessVertices( struct NineDevice9 *This,

Re: [Mesa-dev] [PATCH] tgsi: fix parsing nan float inputs

Am 10.10.2016 um 23:57 schrieb Roland Mainz: > On Mon, Oct 10, 2016 at 11:40 PM, Ilia Mirkin wrote: >> On Mon, Oct 10, 2016 at 5:36 PM, Roland Mainz >> wrote: >>> On Mon, Oct 10, 2016 at 6:12 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin --- src/gallium/auxiliary/tgsi/tgsi_

Re: [Mesa-dev] [PATCH] gallium: add missing zero-init for resource templates

Am 07.10.2016 um 19:08 schrieb Rob Clark: > so, btw, the question is whether to push this patch, or the one that > initializes ->next to NULL in the drivers, or possibly both for good > measure. Yes, why not do both. It makes it explicit that this magic next pointer isn't going to do anything with

Re: [Mesa-dev] [PATCH] draw: initialize shader inputs

Am 12.10.2016 um 02:21 schrieb Kenneth Graunke: > On Wednesday, October 12, 2016 12:04:34 AM PDT srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> This should make the code more robust if a shader tries to use inputs which >> aren't defined by the vert

Re: [Mesa-dev] [PATCH] gallium: add PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY

newtex = screen->resource_create(screen, &pt); > > assert(!newtex || pipe_is_referenced(&newtex->reference)); > > return newtex; > } > > > I guess, why not... I bet though there are apps which create everything as a texture, regardless if they

Re: [Mesa-dev] [PATCH] draw: initialize shader inputs

Am 12.10.2016 um 18:12 schrieb Marek Olšák: > On Wed, Oct 12, 2016 at 12:04 AM, wrote: >> From: Roland Scheidegger >> >> This should make the code more robust if a shader tries to use inputs which >> aren't defined by the vertex element layout (which usually sh

Re: [Mesa-dev] [PATCH] gallium: add PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY

Am 13.10.2016 um 11:33 schrieb Marek Olšák: > On Thu, Oct 13, 2016 at 2:09 AM, Roland Scheidegger > wrote: >> Am 12.10.2016 um 15:29 schrieb Marek Olšák: >>> From: Marek Olšák >>> >>> For performance tuning in drivers. It filters out window system &g

Re: [Mesa-dev] [PATCH] gallivm: print out time for jitting functions with GALLIVM_DEBUG=perf

Am 14.10.2016 um 18:05 schrieb Jose Fonseca: > On 14/10/16 15:36, Brian Paul wrote: >> On 10/13/2016 09:38 PM, srol...@vmware.com wrote: >>> From: Roland Scheidegger >>> >>> Compilation to actual machine code can easily take as much time as the >>>

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 honoring

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 +- > src/gallium/docs/source/context.rst

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

e *gallivm, > res = LLVMBuildAlloca(first_builder, type, name); > LLVMBuildStore(builder, LLVMConstNull(type), res); > > LLVMDisposeBuilder(first_builder); > > return res; > } > > > /** > + * Like lp_build_alloca_undef, but do not zero-initialize

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 v2 1/2] gallium/util: add helper to compute zmin/zmax for a viewport state

Reviewed-by: Roland Scheidegger Am 14.08.2016 um 19:09 schrieb Ilia Mirkin: > Signed-off-by: Ilia Mirkin > Cc: "11.2 12.0" > --- > src/gallium/auxiliary/Makefile.sources | 3 +- > src/gallium/auxiliary/util/u_viewport.h | 59 >

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

Am 15.08.2016 um 19:48 schrieb Marek Olšák: > On Sun, Aug 14, 2016 at 11:38 AM, Marek Olšák wrote: >> On Aug 12, 2016 8:49 PM, "Roland Scheidegger" wrote: >>> >>> I can't say I'm a big fan of this. >>> From an "api cleanness" po

Re: [Mesa-dev] [PATCH 1/3] gallium: add explicit return type to texture opcodes

I don't really like this - I'd like to keep d3d10 semantics unless there's a good reason to change it. And I don't see such a reason - even with variable indexing you cannot use mixed int/uint/float textures since texturing results with using the wrong type of sampler are undefined anyway. Hence yo

Re: [Mesa-dev] [PATCH 2/3] gallium: add a pipe_context parameter to resource_get_handle

I admit I'm not familiar with the interopability stuff. But how is the coherency stuff handled after you get the handle? Does this also work if you've got multiple users of resource_get_handle? Roland Am 22.08.2016 um 16:06 schrieb Marek Olšák: > From: Marek Olšák > > radeonsi needs to do some

Re: [Mesa-dev] [PATCH 1/3] gallium: add explicit return type to texture opcodes

Am 22.08.2016 um 23:13 schrieb Marek Olšák: > On Mon, Aug 22, 2016 at 10:18 PM, Dave Airlie wrote: >> On 23 August 2016 at 06:14, Marek Olšák wrote: >>> On Mon, Aug 22, 2016 at 7:05 PM, Brian Paul wrote: On 08/22/2016 08:38 AM, Marek Olšák wrote: > > From: Marek Olšák > > S

Re: [Mesa-dev] [PATCH 1/3] gallium: add explicit return type to texture opcodes

Am 24.08.2016 um 11:26 schrieb Marek Olšák: > On Wed, Aug 24, 2016 at 2:10 AM, Roland Scheidegger > wrote: >> Am 22.08.2016 um 23:13 schrieb Marek Olšák: >>> On Mon, Aug 22, 2016 at 10:18 PM, Dave Airlie wrote: >>>> On 23 August 2016 at 06:14, Marek Olšák wrote

Re: [Mesa-dev] [PATCH 2/3] gallium: add a pipe_context parameter to resource_get_handle

Am 24.08.2016 um 11:22 schrieb Marek Olšák: > On Wed, Aug 24, 2016 at 2:02 AM, Roland Scheidegger > wrote: >> I admit I'm not familiar with the interopability stuff. >> But how is the coherency stuff handled after you get the handle? >> Does this also work if

Re: [Mesa-dev] [PATCH 2/3] gallium: add a pipe_context parameter to resource_get_handle

Am 24.08.2016 um 17:42 schrieb Marek Olšák: > On Wed, Aug 24, 2016 at 5:31 PM, Roland Scheidegger > wrote: >> Am 24.08.2016 um 11:22 schrieb Marek Olšák: >>> On Wed, Aug 24, 2016 at 2:02 AM, Roland Scheidegger >>> wrote: >>>> I admit I'm not famil

Re: [Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

Am 05.09.2016 um 18:37 schrieb Ilia Mirkin: > On Mon, Sep 5, 2016 at 12:32 PM, Rob Clark wrote: + single plane (interleaved) YUV formats? And seems like android wants YV12 (which is I420 with the 2nd and 3rd planes swapped). In general I don't want to go too crazy and add ev

Re: [Mesa-dev] [PATCH] gallium: remove PIPE_BIND_TRANSFER_READ/WRITE

Looks reasonable to me, seems like the transfer stuff didn't quite turn out like initially expected. Reviewed-by: Roland Scheidegger Am 07.09.2016 um 21:37 schrieb Marek Olšák: > From: Marek Olšák > > not used in any useful way > --- > src/gallium/auxiliary/util/u_debug.

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

Am 08.09.2016 um 22:30 schrieb Rob Clark: > Support multi-planar YUV for external EGLImage's (currently just in the > dma-buf import path) by lowering to multiple texture fetch's for each > plane and CSC in shader. > > Signed-off-by: Rob Clark > --- > src/gallium/auxiliary/util/u_inlines.h

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

Am 08.09.2016 um 23:43 schrieb Rob Clark: > On Thu, Sep 8, 2016 at 5:11 PM, Roland Scheidegger wrote: >> Am 08.09.2016 um 22:30 schrieb Rob Clark: >>> Support multi-planar YUV for external EGLImage's (currently just in the >>> dma-buf import path) by lowering to m

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

Am 09.09.2016 um 02:19 schrieb Rob Clark: > On Thu, Sep 8, 2016 at 7:54 PM, Rob Clark wrote: >> On Thu, Sep 8, 2016 at 6:41 PM, Roland Scheidegger >> wrote: >>> Am 08.09.2016 um 23:43 schrieb Rob Clark: >>>> On Thu, Sep 8, 2016 at 5:11 PM, Roland Scheidegger

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

Am 09.09.2016 um 02:58 schrieb Rob Clark: > On Thu, Sep 8, 2016 at 8:28 PM, Roland Scheidegger wrote: >> Am 09.09.2016 um 02:19 schrieb Rob Clark: >>> On Thu, Sep 8, 2016 at 7:54 PM, Rob Clark wrote: >>>> On Thu, Sep 8, 2016 at 6:41 PM, Roland Scheidegger >>

Re: [Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

Am 12.09.2016 um 21:36 schrieb Rob Clark: > On Sat, Sep 10, 2016 at 10:04 AM, Roland Scheidegger > wrote: >> Am 09.09.2016 um 02:58 schrieb Rob Clark: >>> On Thu, Sep 8, 2016 at 8:28 PM, Roland Scheidegger >>> wrote: >>>> Am 09.09.2016 um 02:19 schrieb

Re: [Mesa-dev] [PATCH 05/14] glsl_to_tgsi: reduce the size of glsl_to_tgsi_instruction using bitfields

Am 17.10.2016 um 15:39 schrieb Marek Olšák: > From: Marek Olšák > > sizeof(glsl_to_tgsi_instruction): 464 -> 416 > --- > src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 33 > +++--- > 1 file changed, 16 insertions(+), 17 deletions(-) > > diff --git a/src/mesa/state_tracker

Re: [Mesa-dev] [PATCH] st/mesa: use u_bit_scan64() on 64-bit CPUs

Am 21.10.2016 um 15:17 schrieb Marek Olšák: > On Oct 21, 2016 12:06 PM, "Jan Ziak" <0xe2.0x9a.0...@gmail.com > > wrote: >> >> On Fri, Oct 21, 2016 at 12:04 PM, Marek Olšák > wrote: >> > This won't make it faster. >> >> Why? > > It's obviou

Re: [Mesa-dev] [PATCH] st/glsl_to_tgsi: fix mismatch between TGSI BFI/BFE and GLSL

On 10/24/2016 04:05 PM, Nicolai Hähnle wrote: On 24.10.2016 15:49, Ilia Mirkin wrote: On Mon, Oct 24, 2016 at 9:43 AM, Nicolai Hähnle wrote: On 24.10.2016 15:38, Nicolai Hähnle wrote: On 24.10.2016 15:34, Ilia Mirkin wrote: These work properly on nvc0. I'd rather you work around it in your

Re: [Mesa-dev] [PATCH] radv: add support for anisotropic filtering on VI+

On 10/26/2016 06:02 PM, Fredrik Höglund wrote: Ported from radeonsi. --- src/amd/vulkan/radv_device.c | 30 +++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c index 512d366..9184308 100644 ---

Re: [Mesa-dev] [PATCH 1/2] gallium: detect avx512 cpu features

I didn't check the actual bits, but looks good to me. Even includes the new cannonlake avx512 bits :-). Reviewed-by: Roland Scheidegger Am 03.11.2016 um 22:29 schrieb Tim Rowley: > v3: fix check for xmm/ymm test > v2: style code, add avx512 to cpu dump > --- > src/galli

Re: [Mesa-dev] [PATCH 2/2] gallivm: permit use of avx512 instructions on llvm-3.9+

I'm a bit worried by this. We've had some (a lot actually) unpleasant surprises in the past with llvm choosing to use instruction sets not appropriate for a given cpu... Hence only setting flags we checked ourselves being available, and disabling everything else. Not sure if this actually still wor

Re: [Mesa-dev] [PATCH 1/2] draw: fix undefined input handling some more...

Am 03.11.2016 um 11:48 schrieb Nicolai Hähnle: > On 03.11.2016 02:15, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> Previous fixes were incomplete - some code still iterated through the >> number >> of elements provided by velem layout instead o

Re: [Mesa-dev] [PATCH 1/2] draw: fix undefined input handling some more...

José > > > > > On Thu, Nov 3, 2016 at 10:48 AM +, "Nicolai Hähnle" > mailto:nhaeh...@gmail.com>> wrote: > > On 03.11.2016 02:15, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> Previous fixes were incomplete - some cod

Re: [Mesa-dev] [PATCH 2/2] gallivm: permit use of avx512 instructions on llvm-3.9+

Am 04.11.2016 um 04:24 schrieb Rowley, Timothy O: > >> On Nov 3, 2016, at 7:09 PM, Roland Scheidegger wrote: >> >> I'm a bit worried by this. >> We've had some (a lot actually) unpleasant surprises in the past with >> llvm choosing to use instr

Re: [Mesa-dev] [PATCH 1/2] gallivm: introduce 32x32->64bit lp_build_mul_32_lohi function

Am 06.11.2016 um 16:50 schrieb Jose Fonseca: > On 04/11/16 04:14, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> This is used by shader umul_hi/imul_hi functions (and soon by draw). >> It's actually useful separating this out on its own, however th

Re: [Mesa-dev] [PATCH 1/2] gallivm: introduce 32x32->64bit lp_build_mul_32_lohi function

Am 07.11.2016 um 22:34 schrieb Jose Fonseca: > On 07/11/16 19:09, Roland Scheidegger wrote: >> Am 06.11.2016 um 16:50 schrieb Jose Fonseca: >>> On 04/11/16 04:14, srol...@vmware.com wrote: >>>> From: Roland Scheidegger >>>> >>>> This is used

Re: [Mesa-dev] [PATCH] gallivm: fix [IU]MUL_HI regression

as I didn't consider this, I don't know if you want to change the shift/trunc to shuffle in the end - feel free to change it back if it doesn't generate good code on radeonsi... Reviewed-by: Roland Scheidegger Am 08.11.2016 um 10:15 schrieb Nicolai Hähnle: > From: Nicolai Hähnl

Re: [Mesa-dev] [PATCH] gallivm: fix [IU]MUL_HI regression

Am 08.11.2016 um 16:23 schrieb Nicolai Hähnle: > On 08.11.2016 14:44, Roland Scheidegger wrote: >> Sorry for breaking radeonsi, I somehow thought this way only used for >> cpu only already, without actually checking... >> And thanks for fixing that typo, apparently you can pa

Re: [Mesa-dev] [PATCH] gallivm: fix [IU]MUL_HI regression

Am 08.11.2016 um 20:10 schrieb Marek Olšák: > FYI, this doesn't fix the regression fully. (GLCTS failures with > piglit: -t mulextended) Maybe using shuffle isn't such a good idea then. Not sure how well you handle them, and there's probably a problem with scalar build contexts (initially this was

Re: [Mesa-dev] [PATCH] gallivm: fix [IU]MUL_HI regression harder

Reviewed-by: Roland Scheidegger I'm curious though, is for radeonsi zext not equivalent to interleaving the low 32bits of each number with zeros (and hence doing the a uninterleave doesn't give you back the low respectively high bits)? Roland Am 09.11.2016 um 12:46 schrieb Nico

Re: [Mesa-dev] [PATCH] gallivm: fix [IU]MUL_HI regression harder

Am 09.11.2016 um 14:55 schrieb Nicolai Hähnle: > On 09.11.2016 14:46, Roland Scheidegger wrote: >> Reviewed-by: Roland Scheidegger >> >> I'm curious though, is for radeonsi zext not equivalent to interleaving >> the low 32bits of each number with zeros (and h

Re: [Mesa-dev] [PATCH] gallivm: fix [IU]MUL_HI regression harder

Am 09.11.2016 um 16:26 schrieb Nicolai Hähnle: > On 09.11.2016 16:10, Roland Scheidegger wrote: >> Am 09.11.2016 um 14:55 schrieb Nicolai Hähnle: >>> On 09.11.2016 14:46, Roland Scheidegger wrote: >>>> Reviewed-by: Roland Scheidegger >>>> >>

Re: [Mesa-dev] [PATCH 1/2] gallivm: Fix build after removal of deprecated attribute API v3

; #define LP_MAX_FUNC_ARGS 32 > > +enum lp_func_attr { > + LP_FUNC_ATTR_ALWAYSINLINE = (1 << 0), > + LP_FUNC_ATTR_BYVAL= (1 << 1), > + LP_FUNC_ATTR_INREG= (1 << 2), > + LP_FUNC_ATTR_NOALIAS = (1 << 3), > + LP_FU

Re: [Mesa-dev] [PATCH 1/2] gallivm: Fix build after removal of deprecated attribute API v3

Am 10.11.2016 um 17:14 schrieb Tom Stellard: > On Wed, Nov 09, 2016 at 11:45:38PM +0100, Roland Scheidegger wrote: >> Am 09.11.2016 um 16:22 schrieb Tom Stellard: >>> v2: >>> Fix adding parameter attributes with LLVM < 4.0. >>> >>> v3: >&g

Re: [Mesa-dev] [PATCH] glsl: include inttypes.h for PRIx64 macro

" > #include "ir_hierarchical_visitor.h" > #include "ir_builder_print_visitor.h" > Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] softpipe and PIPE_CAP_MIXED_COLORBUFFER_FORMATS?

Am 14.11.2016 um 20:15 schrieb A223 A223: > My application requires PIPE_CAP_MIXED_COLORBUFFER_FORMATS and I > noticed that it is not enabled for softpipe. I hardcoded it to be > turned on and did not notice any ill effects so far. > > Is it necessary that PIPE_CAP_MIXED_COLORBUFFER_FORMATS be dis

Re: [Mesa-dev] [PATCH 10/13] gallium: introduce format modifier querying

It looks like there aren't any possible modifier bits defined, so how is this supposed to work? Roland Am 15.11.2016 um 15:24 schrieb Varad Gautam: > From: Varad Gautam > > drivers should implement pipe_screen->get_modifiers_for_format and > advertise it with PIPE_CAP_QUERY_DMABUF_MODIFIERS to

Re: [Mesa-dev] Determinism in the results of llvmpipe?

Am 18.11.2016 um 02:11 schrieb Ilia Mirkin: > On Thu, Nov 17, 2016 at 2:37 AM, Andrew A. wrote: >> Hello, >> >> I'm using Mesa's software renderer for the purposes of regression >> testing in our graphics software. We render various scenes, save a >> screencap of the framebuffer for each scene, th

Re: [Mesa-dev] [PATCH] util: fix missing swizzle components in the SINT <-> UINT conversion string

t;IMM[0] INT32 {0, 0, 0, 0}\n"; > - conversion = "IMAX TEMP[0], TEMP[0], IMM[0].x\n"; > + conversion = "IMAX TEMP[0], TEMP[0], IMM[0].\n"; >} > } else { >assert(dtype == TGSI_RETURN_TYPE_FLOAT); > Reviewed-by: Rolan

Re: [Mesa-dev] Determinism in the results of llvmpipe?

Am 29.11.2016 um 15:18 schrieb Jose Fonseca: > On 29/11/16 14:13, Jose Fonseca wrote: >> On 29/11/16 14:00, Andrew A. wrote: >>> On Fri, Nov 18, 2016 at 2:58 AM, Jose Fonseca >>> wrote: On 17/11/16 07:37, Andrew A. wrote: > > Hello, > > I'm using Mesa's software renderer for t

Re: [Mesa-dev] Determinism in the results of llvmpipe?

Am 29.11.2016 um 17:21 schrieb Andrew A.: >> Am 29.11.2016 um 15:18 schrieb Jose Fonseca: >>> Actually, IIUC https://github.com/divVerent/s2tc/wiki/libtxc_dxtn picks >>> colors at random, so its possible you have the same version of s2tc >>> library, but random colors are being picked. >>> >>> If s

Re: [Mesa-dev] [AppVeyor] mesa master #2842 failed

It's the second time it reached a timeout today - albeit the first time it didn't even start compiling... No idea what's up, but it looks like things are really slow today, one hour build time should be quite sufficient I think. Roland Am 30.11.2016 um 04:05 schrieb Ilia Mirkin: > "Build executi

Re: [Mesa-dev] [PATCH 02/23] tgsi: add Stream{X, Y, Z, W} fields to tgsi_declaration_semantic

Am 30.11.2016 um 14:35 schrieb Nicolai Hähnle: > From: Nicolai Hähnle > > This is for geometry shader outputs. Without it, drivers have no way of > knowing which stream each output is intended for, and have to > conservatively write all outputs to all streams. > > Separate stream numbers for eac

Re: [Mesa-dev] [PATCH 02/23] tgsi: add Stream{X, Y, Z, W} fields to tgsi_declaration_semantic

Am 30.11.2016 um 20:19 schrieb Nicolai Hähnle: > On 30.11.2016 19:06, Roland Scheidegger wrote: >> Am 30.11.2016 um 14:35 schrieb Nicolai Hähnle: >>> From: Nicolai Hähnle >>> >>> This is for geometry shader outputs. Without it, drivers have no way of >

Re: [Mesa-dev] [PATCH 02/23] tgsi: add Stream{X, Y, Z, W} fields to tgsi_declaration_semantic

Am 02.12.2016 um 18:23 schrieb Nicolai Hähnle: > On 30.11.2016 21:37, Roland Scheidegger wrote: >> Am 30.11.2016 um 20:19 schrieb Nicolai Hähnle: >>> On 30.11.2016 19:06, Roland Scheidegger wrote: >>>> Am 30.11.2016 um 14:35 schrieb Nicolai Hähnle: >>>>&

Re: [Mesa-dev] [PATCH 3/3] st/mesa: round lod_bias to a multiple of 1/256

Ideally this wouldn't be tied to specific hardware... That said, I believe the clamping limits are sane (d3d10 will use these too). If GL has some requirements for lod accuracy or if it's queryable, it should probably honor this (d3d10 only would require 6 fractional bits), although I'd guess that

Re: [Mesa-dev] [PATCH 2/3] gallium: decrease the size of pipe_sampler_state fields

Reviewed-by: Roland Scheidegger Not that it really makes a difference... Am 02.12.2016 um 21:38 schrieb Marek Olšák: > From: Marek Olšák > > We've had unused bits. > --- > src/gallium/include/pipe/p_state.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-

Re: [Mesa-dev] [PATCH 02/23] tgsi: add Stream{X, Y, Z, W} fields to tgsi_declaration_semantic

Am 02.12.2016 um 20:44 schrieb Nicolai Hähnle: > On 02.12.2016 19:46, Roland Scheidegger wrote: >> Am 02.12.2016 um 18:23 schrieb Nicolai Hähnle: >>> On 30.11.2016 21:37, Roland Scheidegger wrote: >>>> Am 30.11.2016 um 20:19 schrieb Nicolai Hähnle: >>>>

Re: [Mesa-dev] GL_DEPTH_STENCIL_TEXTURE_MODE and filter type

According to the bug, this was a mistake in ARB_stencil_texturing, which was fixed in GL 4.5. Albeit since the extension itself wasn't updated, I'm not entirely sure it really is supposed to work without gl 4.5 but this extension. In any case, with 4.5 this clearly is a bug and it should work. Seem

Re: [Mesa-dev] [PATCH v2 1/6] gallium: add pipe_screen::resource_changed

Am 05.12.2016 um 16:49 schrieb Philipp Zabel: > Add a hook to tell drivers that an imported resource may have changed > and they need to update their internal derived resources. > > Signed-off-by: Philipp Zabel > --- > Changes since v1: > - Clarified intended of pipe_screen::resource_changed > -

Re: [Mesa-dev] [PATCH] gallivm: use getHostCPUFeatures on x86/llvm-4.0+.

lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT, > MAttrs.push_back("-avx512vl"); > #endif > #endif > +#endif > > #if defined(PIPE_ARCH_PPC) > MAttrs.push_back(util_cpu_caps.has_altivec ? "+altivec" : "-altivec"

Re: [Mesa-dev] [PATCH v3 1/6] gallium: add pipe_screen::resource_changed

Thanks for fixing docs. Reviewed-by: Roland Scheidegger Am 06.12.2016 um 14:57 schrieb Philipp Zabel: > Add a hook to tell drivers that an imported resource may have changed > and they need to update their internal derived resources. > > Signed-off-by: Philipp Zabel > --- >

Re: [Mesa-dev] [PATCH] gallivm: use getHostCPUFeatures on x86/llvm-4.0+.

Interesting. Can you show the IR / assembly? I don't get any failures here. I'm wondering if it's trying to use XOP and there's some bug there (or we're relying on undefined behavior which doesn't happen to work with it). Albeit since there's not actually any conversion involved in this case (float

Re: [Mesa-dev] [PATCH] glsl: fix ldexp lowering if bitfield insert lowering is also requested

On 04/12/16 01:09 AM, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> Trivial, this just resurrects the code which was there once upon a time >> (the code can't lower instructions generated in the lowering pass there, >> and even if it could it would

Re: [Mesa-dev] [PATCH] gallivm: use getHostCPUFeatures on x86/llvm-4.0+.

issing vector shift which otherwise requires avx2). Roland Am 06.12.2016 um 17:34 schrieb Roland Scheidegger: > Interesting. Can you show the IR / assembly? I don't get any failures here. > I'm wondering if it's trying to use XOP and there's some bug there (or > we&#x

<    1   2   3   4   5   6   7   8   9   10   >