Re: [Mesa-dev] [PATCH 2/2] glsl: Handle bits=32 case in bitfieldInsert/bitfieldExtract.

Am 30.12.2015 um 21:26 schrieb Matt Turner: > The OpenGL specifications for these functions say: > >The result will be undefined if or is negative, or if >the sum of and is greater than the number of bits >used to store the operand. > > Therefore passing bits=32, offset=0 is legal

Re: [Mesa-dev] [PATCH 3/5] llvmpipe: Optimize do_triangle_ccw for POWER8

Am 30.12.2015 um 10:59 schrieb Oded Gabbay: > On Wed, Dec 30, 2015 at 1:17 AM, Roland Scheidegger > wrote: >> The idea looks right to me. >> Though frankly I don't like our current setup code too much - in >> particular the mix between c, assembly, and jit code, w

Re: [Mesa-dev] [PATCH 3/5] llvmpipe: Optimize do_triangle_ccw for POWER8

Am 31.12.2015 um 10:15 schrieb Oded Gabbay: > On Thu, Dec 31, 2015 at 4:13 AM, Roland Scheidegger > wrote: >> >> Am 30.12.2015 um 10:59 schrieb Oded Gabbay: >>> On Wed, Dec 30, 2015 at 1:17 AM, Roland Scheidegger >>> wrote: >>>> The idea looks r

Re: [Mesa-dev] [PATCH 1/5] configure.ac: Detect if running on POWER8 arch

Am 31.12.2015 um 10:30 schrieb Oded Gabbay: > On Wed, Dec 30, 2015 at 5:41 PM, Roland Scheidegger > wrote: >> Am 30.12.2015 um 10:46 schrieb Oded Gabbay: >>> On Wed, Dec 30, 2015 at 1:11 AM, Roland Scheidegger >>> wrote: >>>> >>>> So

Re: [Mesa-dev] [PATCH 3/5] llvmpipe: Optimize do_triangle_ccw for POWER8

Am 31.12.2015 um 19:41 schrieb Roland Scheidegger: > Am 31.12.2015 um 10:15 schrieb Oded Gabbay: >> On Thu, Dec 31, 2015 at 4:13 AM, Roland Scheidegger >> wrote: >>> >>> Am 30.12.2015 um 10:59 schrieb Oded Gabbay: >>>> On Wed, Dec 30, 2015 at 1:17 A

Re: [Mesa-dev] [PATCH 1/6] gallium: document PK2H/UP2H

>> 16) > I'm certainly ok with that, albeit (just like PK2H unless you do replication) it's not what the original source for this opcode does (which would have been NV_fragment_program). For the series (with the first point addressed either way,though a tgsi exec implementation whic

Re: [Mesa-dev] [PATCH 1/5] configure.ac: Detect if running on POWER8 arch

Am 03.01.2016 um 13:50 schrieb Oded Gabbay: > On Thu, Dec 31, 2015 at 8:48 PM, Roland Scheidegger > wrote: >> Am 31.12.2015 um 10:30 schrieb Oded Gabbay: >>> On Wed, Dec 30, 2015 at 5:41 PM, Roland Scheidegger >>> wrote: >>>> Am 30.12.2015 um 10:46

Re: [Mesa-dev] [PATCH 1/6] gallium: document PK2H/UP2H

Am 03.01.2016 um 19:02 schrieb Ilia Mirkin: > On Sun, Jan 3, 2016 at 12:33 PM, Roland Scheidegger > wrote: >> Am 03.01.2016 um 01:37 schrieb Ilia Mirkin: >>> Signed-off-by: Ilia Mirkin >>> --- >>> src/gallium/docs/source/tgsi.rst | 10 --

Re: [Mesa-dev] [PATCH 1/5] configure.ac: Detect if running on POWER8 arch

Am 03.01.2016 um 19:20 schrieb Oded Gabbay: > On Sun, Jan 3, 2016 at 8:14 PM, Roland Scheidegger wrote: >> Am 03.01.2016 um 13:50 schrieb Oded Gabbay: >>> On Thu, Dec 31, 2015 at 8:48 PM, Roland Scheidegger >>> wrote: >>>> Am 31.12.2015 um 10:30 schrieb

Re: [Mesa-dev] [PATCH 1/6] gallium: document PK2H/UP2H

Am 03.01.2016 um 21:32 schrieb Ilia Mirkin: > On Sun, Jan 3, 2016 at 2:15 PM, Ilia Mirkin wrote: >> On Sun, Jan 3, 2016 at 2:08 PM, Roland Scheidegger >> wrote: >>>>> For the series (with the first point addressed either way,though a tgsi >>>>>

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

Am 03.01.2016 um 22:29 schrieb Ilia Mirkin: > It seems like there's something horribly wrong with the > util_float_to_half function. In a standalone compilation it works fine > for -6.10203e-05, generating 0x8400, but inside mesa it ends up with > 0x8000. The result of the magic.f multiplication is

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

Am 03.01.2016 um 22:29 schrieb Ilia Mirkin: > This hits assertion failures on LLVM 3.5 > > Signed-off-by: Ilia Mirkin > --- > > It definitely worked at one point or another, but it might have been with > a later LLVM version and/or on a different CPU. On my i7-920 with LLVM 3.5 > I definitely ge

Re: [Mesa-dev] [PATCH 1/6] gallium: document PK2H/UP2H

Am 04.01.2016 um 02:05 schrieb Ilia Mirkin: > On Sun, Jan 3, 2016 at 7:51 PM, Roland Scheidegger wrote: >> Am 03.01.2016 um 21:32 schrieb Ilia Mirkin: >>> On Sun, Jan 3, 2016 at 2:15 PM, Ilia Mirkin wrote: >>>> On Sun, Jan 3, 2016 at 2:08 PM, Roland Scheidegger

Re: [Mesa-dev] [PATCH 1/8] tgsi: add ureg support for image decls

Am 04.01.2016 um 22:00 schrieb Samuel Pitoiset: > > > On 01/04/2016 09:25 PM, Ilia Mirkin wrote: >> On Mon, Jan 4, 2016 at 3:13 PM, Samuel Pitoiset >> wrote: >>> On 01/03/2016 05:37 AM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.

Re: [Mesa-dev] [PATCH v2 5/5] llvmpipe: Optimize lp_rast_triangle_32_3_16 for POWER8

quads_mask(task, > + &tri->inputs, > + x + 4 * out[i].j, > + y + 4 * out[i].i, > + 0x & ~out[i].mask);

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

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 o

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

Am 04.01.2016 um 20:38 schrieb Jose Fonseca: > On 02/01/16 20:39, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> This is quite a few less instructions, albeit still do the 2 64bit muls >> with scalar c code (they'd need way more shuffles, plus fixu

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

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/16 20:39, srol...@vmware.com wrote: >>>> From: Roland Scheidegger >>>> >>>> This is quit

Re: [Mesa-dev] [PATCH 0/7] vbo: introduce a minmax_index cache

Am 08.01.2016 um 05:01 schrieb Timothy Arceri: > On Thu, 2016-01-07 at 19:57 -0500, Nicolai Hähnle wrote: >> Hi, >> >> this series is intended to address a (big) part of the performance >> problems >> that occur when games use an index buffer from a VBO together with >> vertex >> attributes supplie

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

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/16 20:39, srol...@vmware.com wrote: >>>>>

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

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: >>>&

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

Am 08.01.2016 um 23:28 schrieb Jose Fonseca: > 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: >>>&

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

Am 12.01.2016 um 10:49 schrieb Jose Fonseca: > On 12/01/16 02:11, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> Discovered by accident, valgrind was complaining (could have possibly >> caused >> us to create redundant geometry shader variants). &g

Re: [Mesa-dev] [PATCH 1/2] nir: Add a fquantize2f16 opcode

Am 13.01.2016 um 02:23 schrieb Jason Ekstrand: > On Tue, Jan 12, 2016 at 4:50 PM, Ian Romanick > wrote: > > With the SPIR-V link added and the wording change suggested by Erik RE: > precision vs. number of bits in the type, this series is > > > How about: >

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

rate_mipmap(struct gl_context *ctx, GLenum > target, >last_layer = util_max_layer(pt, baseLevel); > } > > - /* Try to generate the mipmap by rendering/texturing. If that fails, > -* use the software fallback. > + /* First see if the driver supports hardware mipmap generation, > +* if not then generate the mipmap by rendering/texturing. > +* If that fails, use the software fallback. > */ > - if (!util_gen_mipmap(st->pipe, pt, pt->format, baseLevel, lastLevel, > -first_layer, last_layer, PIPE_TEX_FILTER_LINEAR)) { > - _mesa_generate_mipmap(ctx, target, texObj); > + if (!st->pipe->screen->get_param(st->pipe->screen, > +PIPE_CAP_GENERATE_MIPMAP) || > + !st->pipe->generate_mipmap(st->pipe, pt, pt->format, baseLevel, > + lastLevel, first_layer, last_layer)) { > + > + if (!util_gen_mipmap(st->pipe, pt, pt->format, baseLevel, lastLevel, > + first_layer, last_layer, PIPE_TEX_FILTER_LINEAR)) > { > + _mesa_generate_mipmap(ctx, target, texObj); > + } > } > > /* Fill in the Mesa gl_texture_image fields */ > Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] nir: Add a fquantize2f16 opcode

Am 13.01.2016 um 02:41 schrieb Matt Turner: > On Tue, Jan 12, 2016 at 4:10 PM, Jason Ekstrand wrote: >> On Tue, Jan 12, 2016 at 3:52 PM, Matt Turner wrote: >>> >>> On Tue, Jan 12, 2016 at 3:35 PM, Jason Ekstrand >>> wrote: This opcode simply takes a 32-bit floating-point value and reduces i

Re: [Mesa-dev] [PATCH] gallivm: merge two identical LLVM version checks

ndif > -#if HAVE_LLVM >= 0x0304 > MAttrs.push_back(util_cpu_caps.has_sse4_2 ? "+sse4.2" : "-sse4.2"); > #else > + MAttrs.push_back(util_cpu_caps.has_sse4_1 ? "+sse41" : "-sse41" ); > MAttrs.push_back(util_cpu_caps

Re: [Mesa-dev] [PATCH] st/mesa: use surface format to generate mipmaps when available

Looks good to me. Reviewed-by: Roland Scheidegger Am 14.01.2016 um 19:46 schrieb Ilia Mirkin: > This fixes the recently posted mipmap + texture views piglit test. > > Signed-off-by: Ilia Mirkin > Cc: "11.0 11.1" > --- > src/mesa/state_tracker/st_gen_mipmap

Re: [Mesa-dev] [PATCH] avoid crashing in mod by 0 with llvmpipe

u( > const struct lp_build_tgsi_action * action, > struct lp_build_tgsi_context * bld_base, > struct lp_build_emit_data * emit_data) Subject should probably say: gallivm: ... With that fixed: Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] avoid crashing in mod by 0 with llvmpipe

Ok, pushed. Roland Am 15.01.2016 um 21:01 schrieb Jeff Muizelaar: > Do you mind fixing up the language to match what you're looking for > and committing it? > > Thanks, > > -Jeff > > On Fri, Jan 15, 2016 at 3:00 PM, Roland Scheidegger > wrote: >&g

Re: [Mesa-dev] [PATCH] i965: Provide sse2 version for rgba8 <-> bgra8 swizzle

There's actually a small bug in it, the argument order to _mm_andnot_si128 is swapped. Otherwise it should be ok... Roland Am 16.01.2016 um 03:58 schrieb srol...@vmware.com: > From: Roland Scheidegger > > The existing code used ssse3, and because it isn't compiled in a separ

Re: [Mesa-dev] [PATCH] llvmpipe: fix arguments order given to vec_andc

eo = vec_sub_epi32(vec_andnot_si128(dcdy_neg_mask, dcdy), > vec_and(dcdx_neg_mask, dcdx)); > >/* ei = _mm_sub_epi32(_mm_sub_epi32(dcdy, dcdx), eo); */ > Reviewed-by: Roland Scheidegger FWIW the order on the SSE intrinsic intuitively feels wrong t

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

Reviewed-by: Roland Scheidegger Am 17.01.2016 um 21:55 schrieb Oded Gabbay: > 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, >

Re: [Mesa-dev] [PATCH] gallium: make image views non-persistent objects

FWIW why exactly are pipe_sampler_view and pipe_surface ref counted? These are all the same too from a high level perspective. I guess though there'd be significant effort to change that... Roland Am 19.01.2016 um 04:08 schrieb Ilia Mirkin: > Make them akin to shader buffers, with no refcounting

Re: [Mesa-dev] [PATCH v2 01/10] tgsi: add MEMBAR opcode to handle memoryBarrier* GLSL intrinsics

I am actually wondering how well that would work for d3d11. d3d11 just has AllMemoryBarrier, DeviceMemoryBarrier plus GroupMemoryBarrier - and for each of them also a "WithGroupSync" version. Hmm. Roland Am 19.01.2016 um 03:30 schrieb Ilia Mirkin: > Signed-off-by: Ilia Mirkin > Reviewed-by: Mare

Re: [Mesa-dev] [PATCH v2 01/10] tgsi: add MEMBAR opcode to handle memoryBarrier* GLSL intrinsics

roup or global sync (the former more looks like TGSI_OPCODE_BARRIER?). Anyway, I don't have any objections to this. Roland > > On Tue, Jan 19, 2016 at 12:04 PM, Roland Scheidegger > wrote: >> I am actually wondering how well that would work for d3d11. >> d3d11

Re: [Mesa-dev] [PATCH 2/4] i965: Provide sse2 version for rgba8 <-> bgra8 swizzle

Ping? Am 17.01.2016 um 22:49 schrieb srol...@vmware.com: > From: Roland Scheidegger > > The existing code used ssse3, and because it isn't compiled in a separate > file compiled with that, it is usually not used (that, of course, could > be fixed...), whereas sse2 is alw

Re: [Mesa-dev] [PATCH v4 01/11] tgsi: add MEMBAR opcode to handle memoryBarrier* GLSL intrinsics

Reviewed-by: Roland Scheidegger Am 24.01.2016 um 19:59 schrieb Ilia Mirkin: > Signed-off-by: Ilia Mirkin > Reviewed-by: Marek Olšák (v1) > > v1 -> v2: add defines for the various bits > --- > src/gallium/auxiliary/tgsi/tgsi_info.c | 2 +- > src/gall

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

Drepositories&d=BQIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=Gk3CFJ05oqh1znZSK1leG9LvG7wkREWxQVsngYqVz1I&s=wFvmNDxxHy03-JtSUUpyCLwXuXnfEH-YGa90ke-LrXw&e= > > +clone_depth: 100 > > cache: > - win_flex_bison-2.4.5.zip > Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] i965: Provide sse2 version for rgba8 <-> bgra8 swizzle

Am 29.01.2016 um 00:31 schrieb Matt Turner: > On Sun, Jan 17, 2016 at 1:49 PM, wrote: >> From: Roland Scheidegger >> >> The existing code used ssse3, and because it isn't compiled in a separate >> file compiled with that, it is usually not used (that, of course

Re: [Mesa-dev] [PATCH 1/3] gallivm: don't crash on UP2H and set correct src type

PCODE_UMUL_HI: > + case TGSI_OPCODE_UP2H: >return TGSI_TYPE_UNSIGNED; > case TGSI_OPCODE_IMUL_HI: > case TGSI_OPCODE_I2F: > Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

Am 01.02.2016 um 02:00 schrieb srol...@vmware.com: > From: Roland Scheidegger > > If the tri is fully inside a scissor edge (or rather, we just use the > bounding box of the tri for the comparison), then we can drop these > additional scissor "planes" early. We do

Re: [Mesa-dev] [RFCv3 00/11] gallium: add support for NIR as alternate IR

For the first 2 in the series: Reviewed-by: Roland Scheidegger Am 31.01.2016 um 21:16 schrieb Rob Clark: > From: Rob Clark > > Ok, v3 of something I've been working on here and there for a while.. > > Since the last time I've sent this patchset, I've added

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

Am 01.02.2016 um 17:14 schrieb Brian Paul: > On 01/31/2016 06:00 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> If the tri is fully inside a scissor edge (or rather, we just use the >> bounding box of the tri for the comparison), then we can drop

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

colors, this shader opcode). >> Hence for now don't enable the cap bit (so the code is unused). >> (Code is from imirkin, comment from sroland) > > Minor code nit-picks below. > > Otherwise, > Reviewed-by: Brian Paul > > >> >> Signed-off-by

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

Am 01.02.2016 um 16:36 schrieb Brian Paul: > Just a few more nitpicks below... > > Reviewed-by: Brian Paul > > On 01/30/2016 07:08 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> Add support for these opcodes, the conversion functions were alre

Re: [Mesa-dev] [PATCH 2/4] i965: Provide sse2 version for rgba8 <-> bgra8 swizzle

MNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=nGNQk9Ygig92I2slinye-TToGAmNP8dl5F9AsSX4ehA&s=uowtFMWBy9fKM5iN6ZsSGHoOLkYskpAvf4coEYs3ESg&e= > > > > /Marta > >> -Original Message- >> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedes

Re: [Mesa-dev] [PATCH 2/5] mesa: implement GL_NVX_gpu_memory_info

Does anyone use these extensions? I suppose maybe to get the total amount of video memory? From the dynamic counts, I would have thought the eviction one would be the most interesting, but this one isn't implemented. Ah well I guess a sloppily implemented extension is better than none. Roland Am

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

Am 02.02.2016 um 13:39 schrieb Jose Fonseca: > On 31/01/16 02:08, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> Add support for these opcodes, the conversion functions were already >> there albeit need some new packing stuff. >> Just like the tgsi

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

Am 02.02.2016 um 13:32 schrieb Jose Fonseca: > On 01/02/16 01:00, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> If the tri is fully inside a scissor edge (or rather, we just use the >> bounding box of the tri for the comparison), then we can drop these &g

Re: [Mesa-dev] [PATCH 2/5] mesa: implement GL_NVX_gpu_memory_info

Am 02.02.2016 um 20:41 schrieb Marek Olšák: > On Tue, Feb 2, 2016 at 4:02 PM, Roland Scheidegger wrote: >> Does anyone use these extensions? >> I suppose maybe to get the total amount of video memory? >> From the dynamic counts, I would have thought the eviction one

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

Am 02.02.2016 um 21:15 schrieb Marek Olšák: > On Sat, Jan 30, 2016 at 12:46 AM, Marek Olšák wrote: >> From: Marek Olšák >> >> Based on a gallivm patch by Ilia Mirkin. >> >> +8 piglit regressions due to precision issues >> --- >> .../drivers/radeon/radeon_setup_tgsi_llvm.c| 72 >> +++

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

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, 2016 at 12:46 AM, Marek Olšák wrote: > From: Marek Olšák > > Based on a ga

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

Am 03.02.2016 um 18:01 schrieb Marek Olšák: > 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: >>

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

Am 03.02.2016 um 18:29 schrieb Roland Scheidegger: > Am 03.02.2016 um 18:01 schrieb Marek Olšák: >> 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: &

Re: [Mesa-dev] [PATCH] mesa: Use SSE prefetch instructions rather than 3DNow instructions

rting prefetcht1, so why not.) Reviewed-by: Roland Scheidegger Am 03.02.2016 um 22:05 schrieb Timothy Arceri: > From: Patrick Baggett > > 64-bit Pentium 4 CPUs don't have the 3DNow prefetch instructions > which results in an Illegal instruction crash. > > Cc: Rola

Re: [Mesa-dev] [PATCH] Add (un)packHalf tests which don't fail on GCN

Would probably make more sense on the piglit ml... That said, the existing unpack works on llvmpipe just fine even if you enable that half cap bit (unpack is always exact). The only potential gotcha I see is with denorms - the result of course is never a fp32 denorm but I suppose depending on your

Re: [Mesa-dev] [Piglit] [PATCH] Add (un)packHalf tests which don't fail on GCN

Am 05.02.2016 um 01:55 schrieb Matt Turner: > On Thu, Feb 4, 2016 at 10:50 AM, Marek Olšák wrote: >> From: Marek Olšák >> >> This is a subset of the generated tests which are known to fail >> on everything except CPU emulation (AFAIK). >> --- > > This is really awful. Committing a generated test

Re: [Mesa-dev] [Piglit] [PATCH] Add (un)packHalf tests which don't fail on GCN

Am 05.02.2016 um 15:44 schrieb Marek Olšák: > On Fri, Feb 5, 2016 at 10:57 AM, Marek Olšák wrote: >> On Fri, Feb 5, 2016 at 1:55 AM, Matt Turner wrote: >>> On Thu, Feb 4, 2016 at 10:50 AM, Marek Olšák wrote: From: Marek Olšák This is a subset of the generated tests which are know

Re: [Mesa-dev] [Piglit] [PATCH] Add (un)packHalf tests which don't fail on GCN

Am 05.02.2016 um 16:08 schrieb Marek Olšák: > On Fri, Feb 5, 2016 at 3:56 PM, Roland Scheidegger wrote: >> Am 05.02.2016 um 15:44 schrieb Marek Olšák: >>> On Fri, Feb 5, 2016 at 10:57 AM, Marek Olšák wrote: >>>> On Fri, Feb 5, 2016 at 1:55 AM, Matt Turner wrote: &

Re: [Mesa-dev] [Piglit] [PATCH] Add (un)packHalf tests which don't fail on GCN

Am 05.02.2016 um 17:04 schrieb Marek Olšák: > On Fri, Feb 5, 2016 at 4:48 PM, Roland Scheidegger wrote: >> Am 05.02.2016 um 16:08 schrieb Marek Olšák: >>> On Fri, Feb 5, 2016 at 3:56 PM, Roland Scheidegger >>> wrote: >>>> Am 05.02.2016 um 15:44 schrieb Ma

Re: [Mesa-dev] [RFCv3 11/11] mesa/st: add support for NIR as possible driver IR

Am 06.02.2016 um 22:30 schrieb Marek Olšák: > On Sat, Feb 6, 2016 at 2:45 PM, Rob Clark wrote: >> On Sun, Jan 31, 2016 at 3:16 PM, Rob Clark wrote: >>> + // XXX get from pipe_screen? Or just let pipe driver provide? >>> + nir_options.lower_fpow = true; >>> + nir_options.lower_fsat = true;

Re: [Mesa-dev] [PATCH] radeonsi: enable denorms for 64-bit and 16-bit floats

This looks good to me, albeit I know nothing about the hw. So VI could do (just with some restrictios) even full-speed fp32 denorms whereas SI/CI can't? Interesting, I suppose that would be intended for compute. intel x86 can't even do that (actually, I think skylake can), though certainly other cp

Re: [Mesa-dev] [RFCv3 11/11] mesa/st: add support for NIR as possible driver IR

Am 08.02.2016 um 14:59 schrieb Rob Clark: > On Mon, Feb 8, 2016 at 6:58 AM, Roland Scheidegger wrote: >> Am 06.02.2016 um 22:30 schrieb Marek Olšák: >>> On Sat, Feb 6, 2016 at 2:45 PM, Rob Clark wrote: >>>> On Sun, Jan 31, 2016 at 3:16 PM, Rob Clark wrote: >>

Re: [Mesa-dev] [PATCH] radeonsi: enable denorms for 64-bit and 16-bit floats

Am 09.02.2016 um 00:02 schrieb Ian Romanick: > On 02/08/2016 12:38 PM, Marek Olšák wrote: >> On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard wrote: >>> On Sat, Feb 06, 2016 at 01:15:42PM +0100, Marek Olšák wrote: From: Marek Olšák This fixes FP16 conversion instructions for VI, which

Re: [Mesa-dev] [PATCH] radeonsi: enable denorms for 64-bit and 16-bit floats

Am 09.02.2016 um 00:53 schrieb Ian Romanick: > On 02/08/2016 03:37 PM, Roland Scheidegger wrote: >> Am 09.02.2016 um 00:02 schrieb Ian Romanick: >>> On 02/08/2016 12:38 PM, Marek Olšák wrote: >>>> On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard wrote: >>>>

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

f_height + y; > + > if (ctx->Transform.ClipDepthMode == GL_NEGATIVE_ONE_TO_ONE) { >scale[2] = 0.5 * (f - n); >translate[2] = 0.5 * (n + f); > With the caveat that I always get confused by the top/bottom flip stuff, this looks right to me... Reviewed-by

Re: [Mesa-dev] [PATCH 3/3] st/mesa: clarify some texture target code in st_cb_drawpix.c

olean normalized = sv[0]->texture->target != PIPE_TEXTURE_RECT; > + boolean normalized = sv[0]->texture->target == PIPE_TEXTURE_2D; > + > + assert(sv[0]->texture->target == st->internal_target); > > /* limit checks */ > /* XXX if DrawPixels image is larger

Re: [Mesa-dev] building with -Wshadow

Am 10.02.2016 um 05:43 schrieb Dave Airlie: > I was just messing with warning flags on virglrenderer and noticed > -Wshadow generated a fair few warnings with gallium, so I did a mesa > build with -Wshadow enabled and it was fairly messy, > > do we care? there could be bugs hiding in -Wshadow land

Re: [Mesa-dev] [PATCH] llvmpipe: Do not use barriers if not using threads.

{ > + pipe_barrier_destroy( &rast->barrier ); > + } > > lp_scene_queue_destroy(rast->full_scenes); > > Oh good find. I am wondering why it worked before - barriers with 0 count were never legal, and it looks like the glibc implementation would always ha

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

13_COMPAT_CFLAGS) > > noinst_LTLIBRARIES = libtrace.la > > diff --git a/src/util/Makefile.am b/src/util/Makefile.am > index e05a2c5..0935891 100644 > --- a/src/util/Makefile.am > +++ b/src/util/Makefile.am > @@ -38,7 +38,7 @@ libmesautil_la_CPPFLAGS = \ > -I$(top_srcdir)/src/gallium/auxiliary \ > $(SHA1_CFLAGS) \ > $(VISIBILITY_CFLAGS) \ > - $(MSVC2008_COMPAT_CFLAGS) > + $(MSVC2013_COMPAT_CFLAGS) > > libmesautil_la_SOURCES = \ > $(MESA_UTIL_FILES) \ > For the series: 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 1/5] mesa: remove _ARB suffix from cube map enums

POSITIVE_Y_ARB: > - case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB: > - case GL_TEXTURE_CUBE_MAP_POSITIVE_Z_ARB: > - case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB: > + case GL_TEXTURE_CUBE_MAP_POSITIVE_X: > + case GL_TEXTURE_CUBE_MAP_NEGATIVE_X: > + case GL_TEXTURE_CUBE_MAP_POSITIVE_Y: > + c

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 nee

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

e; > - int sample; > - unsigned num_coords = tgsi_util_get_texture_coord_dim(target, &sample); > + 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, &ref_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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

41 isn't available - earlier 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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/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 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/auxiliary/draw/draw_llv

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

> I'm open to better suggestions 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 wrote: >> I'll admit I&#

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

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

gt; + } > + > + 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_a

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 insertions(+) > > diff --g

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

{ > + util_snprintf(name, size, "%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 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 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 >> existence of the tw

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 wrote: >> On Sat, Apr 2, 2016 at 7:55 PM, Roland Scheidegger >> wrote: >>> I don't really have anything against the new interface (though don't >>> really feel quali

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/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] About border values in fp64 conversion tests

Pretty sure this should be all undefined. double->int isn't really any different than float->int there where you can have values which are too large too. Note that for float->int (and it should be the same for doubles) d3d10 requires that you clamp to destination type range, and NaN gets converted

Re: [Mesa-dev] [PATCH 2/2] i965/tiled_memcpy: Protect against wrong alignments

Am 05.04.2016 um 03:04 schrieb Jason Ekstrand: > It's possible, when doing an x-tiled copy, to end up with a case where the > bytes parameter is equal to 16 but the pointer is not actually aligned. > This causes asserts in debug mode and segfaults in release builds due to > doing an aligned operati

Re: [Mesa-dev] [PATCH 2/2] i965/tiled_memcpy: Protect against wrong alignments

Am 05.04.2016 um 19:19 schrieb Jason Ekstrand: > > > On Tue, Apr 5, 2016 at 10:12 AM, Roland Scheidegger <mailto:srol...@vmware.com>> wrote: > > Am 05.04.2016 um 03:04 schrieb Jason Ekstrand: > > It's possible, when doing an x-tiled copy, to

Re: [Mesa-dev] [PATCH 2/2] i965/tiled_memcpy: Protect against wrong alignments

Am 06.04.2016 um 01:50 schrieb Jason Ekstrand: > On Tue, Apr 5, 2016 at 4:26 PM, Chad Versace > wrote: > > On 04/04/2016 06:04 PM, Jason Ekstrand wrote: > > It's possible, when doing an x-tiled copy, to end up with a case > where the > > bytes parame

Re: [Mesa-dev] [PATCH 4/7] gallium: raise PIPE_MAX_SAMPLERS to 32

rnal */ > +#define PIPE_MAX_SAMPLERS 32 > #define PIPE_MAX_SHADER_INPUTS80 /* 32 GENERIC + 32 PATCH + 16 others */ > #define PIPE_MAX_SHADER_OUTPUTS 80 /* 32 GENERIC + 32 PATCH + 16 others */ > #define PIPE_MAX_SHADER_SAMPLER_VIEWS 32 > Looks reasonable to me. For

Re: [Mesa-dev] [PATCH 1/2] gallium: add pipe_depth_state::disable_occlusion_queries

Where's the doc bits... But aside from that, this doesn't look quite right to me. Doesn't really feel like depth state (more like context one to suspend queries), and more importantly it should most likely apply to all queries, not just occlusion ones (making it definitely no longer dsa state). R

Re: [Mesa-dev] [PATCH 1/2] gallium: add pipe_depth_state::disable_occlusion_queries

Am 07.04.2016 um 10:37 schrieb Marek Olšák: > On Thu, Apr 7, 2016 at 3:22 AM, Roland Scheidegger wrote: >> Where's the doc bits... >> >> But aside from that, this doesn't look quite right to me. Doesn't really >> feel like depth state (more like co

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

pdate_state(ctx); > st_validate_state(st, ST_PIPELINE_RENDER); > } > } > Looks ok to me, though it looks bugs come and go in that area. But not sure if the mechanism could be made more robust... 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 2/2] gallium: pause queries for all meta ops

nes 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] i965/tiled_memoyp: Get rid of the direction parameter to get_memcpy

WNLOAD > -}; > - > bool intel_get_memcpy(mesa_format tiledFormat, GLenum format, > - GLenum type, mem_copy_fn *mem_copy, uint32_t *cpp, > - enum intel_memcpy_direction direction); > + GLenum type, mem_copy_fn *mem_

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

mage support, so I'm not convinced exposing this just because we can is worth it. But OTOH why not... 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 0/5] R600, GCN: Guard Band support

Am 11.04.2016 um 00:34 schrieb Marek Olšák: > Hi, > > This patch series adds Guard Band support into r600g and radeonsi. > > It first implements the Guard Band in radeonsi, then it moves all radeonsi > scissor & viewport code into gallium/radeon, and then r600g is switched to it > and its origi

Re: [Mesa-dev] [PATCH 03/10] mesa/st: add endian_format field to struct pipe_resource

Am 11.04.2016 um 16:34 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 ei

Re: [Mesa-dev] [PATCH 0/5] R600, GCN: Guard Band support

Am 11.04.2016 um 15:58 schrieb Marek Olšák: > On Mon, Apr 11, 2016 at 2:41 PM, Roland Scheidegger > wrote: >> Am 11.04.2016 um 00:34 schrieb Marek Olšák: >>> Hi, >>> >>> This patch series adds Guard Band support into r600g and radeonsi. >>> &g

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