Re: [Mesa-dev] [PATCH 11/11] vbo: reindent vbo_attrib.h to use 3 spaces

For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 17.01.2018 um 06:18 schrieb Brian Paul: > --- > src/mesa/vbo/vbo_attrib.h | 100 > +++--- > 1 file changed, 50 insertions(+), 50 deletions(-) > > d

Re: [Mesa-dev] [PATCH] draw: fix vsplit code when the (post-bias) index value is -1

Am 16.01.2018 um 16:49 schrieb Brian Paul: > On 01/15/2018 07:18 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> vsplit_add_cache uses the post-bias index for hashing, but the >> vsplit_add_cache_uint/ushort/ubyte ones used

Re: [Mesa-dev] [PATCH 04/21] r600/sb: add tess/compute initial state registers.

t; + sh->add_input(1, 1, 0x0F); For compute, won't you never get here because the !pshader clause above will catch it? By the looks of it, !pshader clause would catch both fetch and compute shaders, and add add 2 preloaded regs, albeit for fetch shader I have no idea why it would reserve 2

Re: [Mesa-dev] [PATCH 05/21] r600/sb: start adding GDS support

the rest of the series looks great to me (with the exception of the last 2), but I'm not really qualified to review (just learning a bit about r600 code for fun...) so 5-19 are Acked-By: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing li

Re: [Mesa-dev] [PATCH 04/21] r600/sb: add tess/compute initial state registers.

Am 11.01.2018 um 03:28 schrieb Dave Airlie: > On 11 January 2018 at 12:19, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 10.01.2018 um 07:48 schrieb Dave Airlie: >>> From: Dave Airlie <airl...@redhat.com> >>> >>> This stops them being optimis

Re: [Mesa-dev] [PATCH 05/10] llvmpipe: implement user constant buffers

Am 11.01.2018 um 00:27 schrieb Marek Olšák: > On Thu, Jan 11, 2018 at 12:12 AM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 10.01.2018 um 20:49 schrieb Marek Olšák: >>> From: Marek Olšák <marek.ol...@amd.com> >>> >>> --- >>>

Re: [Mesa-dev] [PATCH 05/10] llvmpipe: implement user constant buffers

Am 10.01.2018 um 20:49 schrieb Marek Olšák: > From: Marek Olšák > > --- > src/gallium/drivers/llvmpipe/lp_screen.c | 2 +- > src/gallium/drivers/llvmpipe/lp_state_fs.c | 18 +- > 2 files changed, 18 insertions(+), 2 deletions(-) > > diff --git

Re: [Mesa-dev] [PATCH] radeonsi: don't expose 8xMSAA on slowest APUs

Am 05.01.2018 um 02:45 schrieb Marek Olšák: > On Thu, Jan 4, 2018 at 2:46 AM, Roland Scheidegger <srol...@vmware.com> wrote: >> Deos AMD degrade these chips to d3d10.1 on windows? >> Just asking because d3d11 requires 8x msaa ;-). >> >> (But I won't say what I thi

Re: [Mesa-dev] [PATCH] radv: Add support for ETC2 textures.

I thought the reason they are included nowadays in hardware is because they are required by gl 4.3 and of course GLES (I think they were added in GL via ES compatibility). Of course, for proper gles (3.2) you also need astc, but still it looks to me like these formats are here to stay. Roland

Re: [Mesa-dev] [PATCH 6/6] r600: don't emit tes samplers/views when tes isn't active

lamov <hi-an...@yandex.ru> > > On 03.01.2018 05:25, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> Similar to const buffers. The driver must not emit any tes-related >> state if tes >> is disabled, since the hw slots are a

Re: [Mesa-dev] [PATCH] radeonsi: don't expose 8xMSAA on slowest APUs

Deos AMD degrade these chips to d3d10.1 on windows? Just asking because d3d11 requires 8x msaa ;-). (But I won't say what I think about this patch...) Roland Am 04.01.2018 um 01:54 schrieb Marek Olšák: > From: Marek Olšák > > i.e. Kabini, Mullins, Stoney. > > This was

Re: [Mesa-dev] [PATCH 2/3] r600: support 32 vertex attribs for evergreen

I just realized that the state tracker will degrade this to 16 attribs anyway (looks like mesa can only handle 16 generic attribs). So, I suppose it's pretty much untested and not all that helpful... Roland Am 01.01.2018 um 03:11 schrieb srol...@vmware.com: > From: Roland Scheidegger &l

Re: [Mesa-dev] [PATCH 2/2] r600: fix textureSize queries with tbos

Am 28.12.2017 um 02:16 schrieb Alex Deucher: > On Wed, Dec 27, 2017 at 7:51 PM, Dave Airlie <airl...@gmail.com> wrote: >> On 23 December 2017 at 17:19, <srol...@vmware.com> wrote: >>> From: Roland Scheidegger <srol...@vmware.com> >>> >>> pigl

Re: [Mesa-dev] [PATCH 06/22] gallium: add semaphore_server_signal()

Am 22.12.2017 um 01:41 schrieb Andres Rodriguez: > Calling this function will emit a semaphore signal operation into the > GPU's command stream. > > Signed-off-by: Andres Rodriguez > --- > src/gallium/docs/source/context.rst | 31 +++ >

Re: [Mesa-dev] [PATCH] gallium/docs: document behavior of set_sample_mask()

as I know, radeons don't and it would have to be emulated (I suppose the dx10 drivers do), so probably can't really make this gallium behavior (sample mask is pretty awkward with just one sample in the first place, and I doubt used in practice). Reviewed-by: Roland Scheidegger <srol...@vmware.co

Re: [Mesa-dev] [PATCH] cso: add point rasterization sanity check assertion

smooth). Albeit in another paragraph, the docs also state it's an error for mismatches in these states, so I suppose it's ok, but probably a doc clarification would be nice. Either way, Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-de

Re: [Mesa-dev] [PATCH] gallivm: fix texture wrapping for texture gather for mirror modes

ion mode according to ARB_texture_filter_minmax or the corresponding d3d functionality they are actually even required to be ignored, so this case may not be a problem.) Roland > > Some cosmetic remarks inline. > > On 10/12/17 04:49, srol...@vmware.com wrote: >> From: Roland Scheide

Re: [Mesa-dev] [PATCH 2/2] gallium/util: don't pass a pipe_resource to util_resource_is_array_texture()

For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 07.12.2017 um 23:25 schrieb Brian Paul: > No need to pass a pipe_resource when we can just pass the target. > This makes the function potentially more usable. Rename it too. > --- > src/gallium/auxiliary

Re: [Mesa-dev] [PATCH] mesa: Document ati_fragment_shader::cur_pass

Looks alright to me too. And it's shorter :-). Roland Am 28.11.2017 um 11:17 schrieb Miklós Máté: > Hi, > > I've already prepared a patch that documents this, I was going to post > it with the v2 of this series. My version looks like this: > > diff --git a/src/mesa/main/mtypes.h

Re: [Mesa-dev] [Mesa-stable] [PATCH 2/5] r600: use DX10_CLAMP bit in shader setup

e in the series (aab0bfc648bf1be50b81a25224970015f1dc78b8) probably would make sense too for stable, the rest maybe less so. Roland > >> all the stable queues. >> >> What do you think? >> >> On Thu, 2017-11-09 at 20:00 +0100, srol...@vmware.com wrote: >>> From: Roland Schei

Re: [Mesa-dev] [PATCH] mesa: Document ati_fragment_shader::cur_pass

I really don't think you wanted to remove the cur_pass variable there :-). With that fixed, Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 28.11.2017 um 04:10 schrieb Ian Romanick: > From: Ian Romanick <ian.d.roman...@intel.com> > > Signed-off-by: Ian Romanick <

Re: [Mesa-dev] [PATCH 2/4] mesa: fix crash when an ATI_fs pass begins with an alpha inst

Am 27.11.2017 um 21:29 schrieb Ian Romanick: > On 11/20/2017 06:04 PM, Roland Scheidegger wrote: >> Am 21.11.2017 um 01:40 schrieb Ian Romanick: >>> On 11/20/2017 04:07 PM, Miklós Máté wrote: >>>> This fixes crash when: >>>> - first pass begins with al

Re: [Mesa-dev] [PATCH v2 2/2] i965/cnl: Correctly sample from fast-cleared sRGB textures

If you use a float input color, does it mean it isn't quantized? I'm just wondering if you actually get (slightly) different values with sampling from fast-cleared surfaces than you'd get when you'd have cleared the surface normally. In any case, patch 1/2 of this series looks alright (I was just

Re: [Mesa-dev] [PATCH 1/3] util: Fix SHA1 implementation on big endian

Am 26.11.2017 um 01:46 schrieb Matt Turner: >>> Sigh. Was supposed to be #warning. Strangely vim even syntax >>> highlights #warn. Committed a brown bag fix. >> >> As Jon was commenting, #warning is neither portable to MSVC  >> >> AppVeyor error: >>

Re: [Mesa-dev] [PATCH 1/3] util: Fix SHA1 implementation on big endian

Am 25.11.2017 um 22:58 schrieb Jon Turney: > On 25/11/2017 04:24, Matt Turner wrote: >> diff --git a/src/util/u_endian.h b/src/util/u_endian.h >> index 7bbd7dc215..3d5c006f35 100644 >> --- a/src/util/u_endian.h >> +++ b/src/util/u_endian.h >> @@ -67,4 +67,7 @@ >> >>   #endif >> >> +#warn Unknown

Re: [Mesa-dev] [PATCH 1/3] util: Fix SHA1 implementation on big endian

Am 25.11.2017 um 05:24 schrieb Matt Turner: > On Fri, Nov 24, 2017 at 2:25 AM, Eric Engestrom > wrote: >> On Thursday, 2017-11-23 11:08:04 -0800, Matt Turner wrote: >>> The code defines a macro blk0(i) based on the preprocessor condition >>> BYTE_ORDER == LITTLE_ENDIAN.

Re: [Mesa-dev] [RFC] gallium/u_blitter: support blitting PIPE_BUFFERs

2ui, but then your offsets and sizes need to be aligned, and you can't communicate the format to the blitter code.) If you want to support large buffers, you probably need to wrap them in a fake (untiled) 2d resource. Roland > BR, > -R > > On Wed, Nov 22, 2017 at 10:14 AM, Roland S

Re: [Mesa-dev] [RFC] gallium/u_blitter: support blitting PIPE_BUFFERs

I don't think this is a good idea. 1D and buffer resources are fundamentally incompatible, it is highly illegal to use targets in views which are incompatible, so I'd rather not see such atrocities in shared code. I think you really want to fix up your resource_copy_region implementation one way

Re: [Mesa-dev] [PATCH 2/4] mesa: fix crash when an ATI_fs pass begins with an alpha inst

Am 21.11.2017 um 01:40 schrieb Ian Romanick: > On 11/20/2017 04:07 PM, Miklós Máté wrote: >> This fixes crash when: >> - first pass begins with alpha inst >> - first pass ends with color inst, second pass begins with alpha inst >> >> Also, use the symbolic name instead of a number. >> Piglit:

Re: [Mesa-dev] [PATCH] llvmpipe: fix snorm blending

Am 20.11.2017 um 14:58 schrieb Jose Fonseca: > On 18/11/17 05:34, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> The blend math gets a bit funky due to inverse blend factors being >> in range [0,2] rather than [-1,1], our norm

Re: [Mesa-dev] [PATCH] tgsi: s/uint/enum pipe_shader_type/

Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 17.11.2017 um 23:15 schrieb Brian Paul: > --- > src/gallium/auxiliary/tgsi/tgsi_info.c | 2 +- > src/gallium/auxiliary/tgsi/tgsi_info.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sr

Re: [Mesa-dev] [PATCH] llvmpipe: fix snorm blending

Am 17.11.2017 um 14:20 schrieb Emil Velikov: > Hi Roland, > > Just a small fly-by idea: > > On 17 November 2017 at 07:00, wrote: > >> - if(bld->type.norm) { >> + if(type.norm) { >>const char *intrinsic = NULL; >> >> - if(a == bld->one || b == bld->one) >>

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

failed > <https://ci.appveyor.com/project/mesa3d/mesa/build/6163> > > Commit 65123ee62c by Roland Scheidegger <mailto:srol...@vmware.com> on > 11/9/2017 6:53 PM: > r600: set the number type correctly for float rts in cb setup\n\nFloat > rts were always set

Re: [Mesa-dev] [PATCH] r600: fix cubemap arrays

Makes sense. Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 14.11.2017 um 23:28 schrieb Dave Airlie: > From: Dave Airlie <airl...@redhat.com> > > A lot of cubemap array piglits fail, port the texture type > picking code from radeonsi which seems to fix most of

Re: [Mesa-dev] [PATCH 5/5] r600: set the number type correctly for float rts in cb setup

Ping (for the series)? Roland Am 09.11.2017 um 20:00 schrieb srol...@vmware.com: > From: Roland Scheidegger <srol...@vmware.com> > > Float rts were always set as unorm instead of float. > Not sure of the consequences, but at least it looks like the blend clamp > would hav

Re: [Mesa-dev] [PATCH] util/u_thread: fix compilation on Mac OS

Yes, I guess it's a limitation of not-quite-posix mac os :-). Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 10.11.2017 um 12:38 schrieb Nicolai Hähnle: > From: Nicolai Hähnle <nicolai.haeh...@amd.com> > > Apparently, it doesn't have pthread barriers. &

Re: [Mesa-dev] [PATCH] threads: fix MinGW build breakage

FWIW it looks like this series also broke compilation on mac os (I suppose that was f0d3a4de75fdb865c058aba8614f0fe6ba5f0969 though): [...truncated 173 lines...] pthread_barrier_destroy(barrier); ^~~

Re: [Mesa-dev] [PATCH] threads: fix MinGW build breakage

Looks alright to me. Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 09.11.2017 um 17:46 schrieb Brian Paul: > Fixes: f1a364878431c8 ("threads: update for late C11 changes") > --- > include/c11/threads_win32.h | 5 - > 1 file changed, 4 insertions(+), 1

Re: [Mesa-dev] [PATCH 3/4] r600: use ieee version of rcp

Am 09.11.2017 um 18:58 schrieb Roland Scheidegger: > Am 09.11.2017 um 18:27 schrieb Jan Vesely: >> On Thu, 2017-11-09 at 03:58 +0100, srol...@vmware.com wrote: >>> From: Roland Scheidegger <srol...@vmware.com> >>> >>> r600 used the clamped version

Re: [Mesa-dev] [PATCH 3/4] r600: use ieee version of rcp

Am 09.11.2017 um 18:27 schrieb Jan Vesely: > On Thu, 2017-11-09 at 03:58 +0100, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> r600 used the clamped version for rcp, whereas both evergreen and cayman >> used the ieee version.

Re: [Mesa-dev] [PATCH 1/4] r600: use min_dx10/max_dx10 instead of min/max

Am 09.11.2017 um 18:43 schrieb Jan Vesely: > On Thu, 2017-11-09 at 18:39 +0100, Nicolai Hähnle wrote: >> On 09.11.2017 18:26, Roland Scheidegger wrote: >>> Am 09.11.2017 um 18:19 schrieb Jan Vesely: >>>> On Thu, 2017-11-09 at 03:58 +0100, srol...@vmware.com wrote:

Re: [Mesa-dev] [PATCH 1/4] r600: use min_dx10/max_dx10 instead of min/max

Am 09.11.2017 um 18:19 schrieb Jan Vesely: > On Thu, 2017-11-09 at 03:58 +0100, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> I believe this is the safe thing to do, especially ever since the driver >> actually generates N

Re: [Mesa-dev] [PATCH] r600/query: drop rest of vi workaround code.

Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 09.11.2017 um 06:54 schrieb Dave Airlie: > From: Dave Airlie <airl...@redhat.com> > > This isn't needed in r600 anymore. > > Signed-off-by: Dave Airlie <airl...@redhat.com> > --- > src

Re: [Mesa-dev] [PATCH 2/4] r600: use mysterious DX10_CLAMP bit in pixel shader setup

FWIW I'd really appreciate it if someone could shed some light on that mystery bit there... Roland Am 09.11.2017 um 03:58 schrieb srol...@vmware.com: > From: Roland Scheidegger <srol...@vmware.com> > > I don't know what this bit really does. The docs are somewhere between > mi

Re: [Mesa-dev] [PATCH 2/2] r600: use the clamped versions of rcp/rsq for eg/cayman.

th nvc0 and nv50. >> >> On Tue, Nov 7, 2017 at 11:01 PM, <srol...@vmware.com> wrote: >>> From: Roland Scheidegger <srol...@vmware.com> >>> >>> r600 already used the clamped versions, but for some reason t

Re: [Mesa-dev] [PATCH 2/2] r600: use the clamped versions of rcp/rsq for eg/cayman.

dheres to strict ieee rules (or rather, strict dx10 rules for this, but they are mostly identical, with min/max returning the non-nan, which I'd nearly bet nvc0/nv50 do too). Roland > > On Tue, Nov 7, 2017 at 11:01 PM, <srol...@vmware.com> wrote: >> From: Roland Scheidegger

Re: [Mesa-dev] [PATCH] st/mesa: use enum types instead of int/unsigned (v2)

Am 07.11.2017 um 20:52 schrieb Brian Paul: > On 11/07/2017 11:09 AM, Roland Scheidegger wrote: >> Am 07.11.2017 um 18:57 schrieb Brian Paul: >>> On 11/07/2017 09:07 AM, Roland Scheidegger wrote: >>>> Am 07.11.2017 um 16:12 schrieb Brian Paul: >>>>> Us

Re: [Mesa-dev] [PATCH] st/mesa: use enum types instead of int/unsigned (v2)

Am 07.11.2017 um 18:57 schrieb Brian Paul: > On 11/07/2017 09:07 AM, Roland Scheidegger wrote: >> Am 07.11.2017 um 16:12 schrieb Brian Paul: >>> Use the proper enum types for various variables.  Makes life in gdb >>> a little nicer.  Note that the size of enum bitfield

Re: [Mesa-dev] [PATCH] st/mesa: use enum types instead of int/unsigned (v2)

f assignment somewhere were guarded by a ASSERT(x.image_format == image_format) afterwards at least. (Unfortunately I don't see a way to easily make a nice static assertion, you'd have to use something like STATIC_ASSERT(PIPE_FORMAT_COUNT < 1 << (10-1)) which isn't tied directly to th

Re: [Mesa-dev] [PATCH] util/tgsi: add static assertion to catch opcode overflowing bitfield

*/ > + STATIC_ASSERT(TGSI_OPCODE_LAST <= 255); I think technically this could be 256 as we're never assigning this "last" opcode? Either way though, Reviewed-by: Roland Scheidegger <srol...@vmware.com> (And yes we have been very close to the limit for a while now - I think so far the

Re: [Mesa-dev] [PATCH] docs: Fix GL_MESA_program_debug enums

Am 07.11.2017 um 11:42 schrieb Eric Engestrom: > On Tuesday, 2017-11-07 01:44:49 +0100, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> 13b303ff9265b89bdd9100e32f905e9cdadfad81 added the actual enums but >> didn't remove the alre

Re: [Mesa-dev] [PATCH 2/2] r600g: use SIMPLE_FLOAT for blending to avoid NaNs in RTs

The patch doesn't help at all, but looks like a sensible thing to do anyway. Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 06.11.2017 um 05:22 schrieb Ilia Mirkin: > Radeonsi also sets this flag. > > Bugzilla: > https://urldefense.proofpoint.

Re: [Mesa-dev] [PATCH] gallivm: allow arch rounding with avx512

Looks good to me. Albeit I think there's quite a few more places which probably should handle avx512... Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 01.11.2017 um 20:17 schrieb Tim Rowley: > Fixes piglit vs-roundeven-{float,vec[234]} with simd16 VS. > --- > src/ga

Re: [Mesa-dev] [PATCH] gallium: increase pipe_sampler_view::target bitfield size for MSVC

. Not sure if that would be preferable, there's really no good solution, but in any case Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 01.11.2017 um 15:45 schrieb Brian Paul: > MSVC treats enums as being signed. The 4-bit target field isn't large > enough to correctly store

Re: [Mesa-dev] [PATCH] scons: fix OSMesa driver build

Looks alright too. Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 28.10.2017 um 00:35 schrieb Brian Paul: > Fixes: ea53d9a8eb5d4b2 "glapi: include generated headers without path" > --- > src/mesa/drivers/osmesa/SConscript | 1 + > 1 file changed, 1 insert

Re: [Mesa-dev] [PATCH] scons: fix scons build to find generated glapitable.h

i build path > ]) > > Makes sense to me. 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] gallium; s/unsigned/enum pipe_prim_type/

Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 27.10.2017 um 23:16 schrieb Brian Paul: > In the vbuf_render::set_primitive() functions. > --- > src/gallium/auxiliary/draw/draw_vbuf.h | 3 ++- > src/gallium/drivers/i915/i915_prim_vbuf.c| 2 +- > src/gal

Re: [Mesa-dev] [PATCH 3/3] gallium/u_vbuf: use signed vertex buffers offsets for optimal uploads

Am 27.10.2017 um 04:50 schrieb Marek Olšák: > On Fri, Oct 27, 2017 at 1:44 AM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 26.10.2017 um 17:31 schrieb Marek Olšák: >>> From: Marek Olšák <marek.ol...@amd.com> >>> >>> Uploaded data must

Re: [Mesa-dev] [PATCH 3/3] gallium/u_vbuf: use signed vertex buffers offsets for optimal uploads

Am 26.10.2017 um 17:31 schrieb Marek Olšák: > From: Marek Olšák > > Uploaded data must start at (stride * start), because we can't modify > start in all cases. I'm probably missing something here, but why not actually? Roland If it's the first allocation, it's also the

Re: [Mesa-dev] Build mesa-dev on Windows with AVX instruction set problem

Am 26.10.2017 um 00:26 schrieb Ilia Mirkin: > On Wed, Oct 25, 2017 at 6:15 PM, Fabrício Ceolin > > > wrote: > > Hi, > > Thanks. I recompiled everything (on Windows) using this real machine: > > #under msys2 >

Re: [Mesa-dev] [PATCH] gallium/util: remove some block alignment assertions

Am 25.10.2017 um 16:57 schrieb Roland Scheidegger: > Am 25.10.2017 um 16:29 schrieb Brian Paul: >> On 10/24/2017 07:06 PM, srol...@vmware.com wrote: >>> From: Roland Scheidegger <srol...@vmware.com> >>> >>> These assertions were revisited a couple of tim

Re: [Mesa-dev] [PATCH] gallium/util: remove some block alignment assertions

Am 25.10.2017 um 16:29 schrieb Brian Paul: > On 10/24/2017 07:06 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> These assertions were revisited a couple of times in the past, and they >> still weren't quite right. >> Th

Re: [Mesa-dev] Build mesa-dev on Windows with AVX instruction set problem

Am 24.10.2017 um 18:26 schrieb Fabrício Ceolin: > Hi, > > I am trying to build mesa-dev on windows. > > I am learning how to do it, through the > project https://github.com/pal1000/mesa-dist-win/tree/master/buildscript > > > I

Re: [Mesa-dev] [PATCH] gallium: add more exceptions to tgsi_util_get_inst_usage_mask

Reviewed-by: Roland Scheidegger <srol...@vmware.com> Albeit the way those masks are derived looks quite error-prone in general (especially for new opcodes). Am 19.10.2017 um 18:40 schrieb Tim Rowley: > A number of double/int64 operations don't have matching > read and write usage

Re: [Mesa-dev] [PATCH 1/2] gallium: allow 512-bit vectors

This looks alright to me. There's quite a few places where this will increase the memory requirements a bit but there's no way around it (well unless deciding at runtime alignments/allocations, but it's probably not worth the trouble). Reviewed-by: Roland Scheidegger <srol...@vmware.com&g

Re: [Mesa-dev] [PATCH 2/2] mesa: move _mesa_half_is_negative() to half_float.h

For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> (I don't have any preference for !! or != albeit I do think doing it explicit either way makes it more obvious indeed.) Roland Am 10.10.2017 um 04:29 schrieb Brian Paul: > v2: use !! in the function to be explicit a

Re: [Mesa-dev] [PATCH 1/3] mesa: move _mesa_exec_malloc/free() prototypes to their own header

644 > index 000..bc51a8c > --- /dev/null > +++ b/src/mesa/main/execmem.h > @@ -0,0 +1,37 @@ > +/* > + * Mesa 3-D graphics library > + * > + * Copyright (C) 1999-2005 Brian Paul All Rights Reserved. Should probably update the year here, but either way Reviewed-by: Roland Scheidegger

Re: [Mesa-dev] [PATCH 2/3] mesa: move _mesa_half_is_negative() to half_float.h

Am 09.10.2017 um 23:33 schrieb Brian Paul: > On 10/09/2017 03:24 PM, Ilia Mirkin wrote: >> On Mon, Oct 9, 2017 at 5:07 PM, Roland Scheidegger >> <srol...@vmware.com> wrote: >>> Am 09.10.2017 um 22:56 schrieb Brian Paul: >>>> --- >>>>

Re: [Mesa-dev] [PATCH 2/3] mesa: move _mesa_half_is_negative() to half_float.h

Am 09.10.2017 um 22:56 schrieb Brian Paul: > --- > src/mesa/main/imports.h | 6 -- > src/util/half_float.h | 8 > 2 files changed, 8 insertions(+), 6 deletions(-) > > diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h > index a4964a3..51fa72c 100644 > ---

Re: [Mesa-dev] [PATCH 0/6] st/mesa: add locking around lazy texture/sampler updates

Am 07.10.2017 um 01:01 schrieb Nicolai Hähnle: > On 07.10.2017 00:36, Roland Scheidegger wrote: >> I can't help but think that there'd be none of those problems if those >> views were actually used as specced by gallium initially: all sampler >> views (and surf

Re: [Mesa-dev] [PATCH 0/6] st/mesa: add locking around lazy texture/sampler updates

I can't help but think that there'd be none of those problems if those views were actually used as specced by gallium initially: all sampler views (and surfaces) are per context, and they simply cannot be used in another context. Roland Am 06.10.2017 um 22:38 schrieb Nicolai Hähnle: > Hi all, >

Re: [Mesa-dev] [PATCH] ac/nir: use llvm fma intrinsic if nir instruction is exact.

Am 06.10.2017 um 11:29 schrieb Alex Smith: > On 6 October 2017 at 03:39, Dave Airlie > wrote: > > On 6 October 2017 at 12:31, Marek Olšák > wrote: > > On Fri, Oct 6, 2017 at 4:10 AM, Connor

Re: [Mesa-dev] [PATCH] gallium: remove TGSI_OPCODE_KILL

Am 06.10.2017 um 00:34 schrieb Marek Olšák: > On Thu, Oct 5, 2017 at 8:00 PM, Ilia Mirkin wrote: >> On Thu, Oct 5, 2017 at 1:45 PM, Marek Olšák wrote: >>> On Thu, Oct 5, 2017 at 4:45 PM, Ilia Mirkin wrote: Like Roland, I don't

Re: [Mesa-dev] [PATCH] gallium: remove TGSI_OPCODE_KILL

I didn't like this when it was proposed a couple weeks ago, and unsurprisingly I still don't like it now. The reason is that KILL is a simple opcode which even maps to what both glsl and d3d10 actually need, whereas KILL_IF is a complicated mess including combined per-channel comparisons. I

Re: [Mesa-dev] [PATCH 5/6] freedreno: context priority support

Am 04.10.2017 um 17:44 schrieb Rob Clark: > For devices (and kernels) which support different priority ringbuffers, > expose context priority support. > > Signed-off-by: Rob Clark > --- > src/gallium/drivers/freedreno/freedreno_context.c | 9 - >

Re: [Mesa-dev] [PATCH 1/6] gallium: plumb context priority through to driver

OUBLES: > diff --git a/src/gallium/drivers/radeonsi/si_pipe.c > b/src/gallium/drivers/radeonsi/si_pipe.c > index 33f5adbd3ad..2881bd8f9fb 100644 > --- a/src/gallium/drivers/radeonsi/si_pipe.c > +++ b/src/gallium/drivers/radeonsi/si_pipe.c > @@ -488,6 +488,7 @@ static int si_get_param(st

Re: [Mesa-dev] [PATCH] radv: lower ffma in nir.

Am 03.10.2017 um 22:58 schrieb Dave Airlie: > From: Dave Airlie > > So it appears the Vulkan SPIR-V fma opcode can be equivalent to a > mad operation, and the fma hw opcode on AMD hw is issued like a double > opcode so is slower. Also the radeonsi stack does this. > > This

Re: [Mesa-dev] [PATCH 10/15] gallium: Remove util_format_s3tc_enabled

Am 02.10.2017 um 19:36 schrieb Emil Velikov: > On 2 October 2017 at 18:15, Matt Turner wrote: >> On Mon, Oct 2, 2017 at 6:17 AM, Emil Velikov >> wrote: >>> On 2 October 2017 at 07:59, Matt Turner wrote: >>> +#include

Re: [Mesa-dev] [PATCH 00/11] Gallium/RadeonSI: Allow any 1D register as a TGSI address operand

I think it's kind of a pity that there's no "intermediate" step here - I think just about every modern driver doesn't want to see UARL / address reg, but I'd assume not everybody can use _any_ 1d reg for addressing. d3d10 only supports temp registers as addressing operands which looks quite

Re: [Mesa-dev] [PATCH 1/4] gallivm: fix typo in debug_printf message

debug_printf("Invoke as \"llc %s%s -o - %s\"\n", > - (HAVE_LLVM >= 0x0305) ? "[-mcpu=<-mcpu option] " : "", > + (HAVE_LLVM >= 0x0305) ? "[-mcpu=<-m

Re: [Mesa-dev] [PATCH] gallium: add new LOD opcode

Am 28.09.2017 um 15:43 schrieb Jose Fonseca: > On 28/09/17 02:46, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> The operation performed is all the same as LODQ, but with the usual >> differences between dx10 and GL texture opco

Re: [Mesa-dev] [PATCH] gallium: do not automatically enable clip planes when a vertex shader writes to gl_ClipDistance

Am 28.09.2017 um 18:19 schrieb Jose Fonseca: > On 28/09/17 17:16, Roland Scheidegger wrote: >> Am 28.09.2017 um 17:53 schrieb Jose Fonseca: >>> On 28/09/17 16:29, Roland Scheidegger wrote: >>>> Am 28.09.2017 um 16:12 schrieb Jose Fonseca: >>>>>

Re: [Mesa-dev] [PATCH] gallium: do not automatically enable clip planes when a vertex shader writes to gl_ClipDistance

Am 28.09.2017 um 17:53 schrieb Jose Fonseca: > On 28/09/17 16:29, Roland Scheidegger wrote: >> Am 28.09.2017 um 16:12 schrieb Jose Fonseca: >>> On 27/09/17 15:07, Roland Scheidegger wrote: >>>> Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger: >>>>&

Re: [Mesa-dev] [PATCH] gallium: do not automatically enable clip planes when a vertex shader writes to gl_ClipDistance

Am 28.09.2017 um 16:12 schrieb Jose Fonseca: > On 27/09/17 15:07, Roland Scheidegger wrote: >> Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger: >>> Software rasterizer and LLVM contain code to enable clipping as soon as >>> a vertex shader writes to gl_ClipDistance

Re: [Mesa-dev] [PATCH] gallium: do not automatically enable clip planes when a vertex shader writes to gl_ClipDistance

Am 27.09.2017 um 09:13 schrieb Olivier Lauffenburger: > Software rasterizer and LLVM contain code to enable clipping as soon as > a vertex shader writes to gl_ClipDistance, even if the corresponding > clip planes are disabled. > GLSL specification states that "Values written into gl_ClipDistance

Re: [Mesa-dev] [PATCH] svga: add missing PIPE_SHADER_CAP_INT64_ATOMICS switch cases

S: > case PIPE_SHADER_CAP_LOWER_IF_THRESHOLD: > case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS: > + case PIPE_SHADER_CAP_INT64_ATOMICS: >return 0; > case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT: >return 32; > Reviewed-by: Roland Scheidegger <srol...@vmware

Re: [Mesa-dev] [PATCH 0/3] tgsi, radeonsi: add CANON opcode for float canonicalization

Am 18.09.2017 um 19:11 schrieb Roland Scheidegger: > Am 18.09.2017 um 17:36 schrieb Nicolai Hähnle: >> On 18.09.2017 17:02, Roland Scheidegger wrote: >>> This looks like a horrendous solution which will break the world - well >>> for us :-). Because integers simply

Re: [Mesa-dev] [PATCH 0/3] tgsi, radeonsi: add CANON opcode for float canonicalization

Am 18.09.2017 um 17:36 schrieb Nicolai Hähnle: > On 18.09.2017 17:02, Roland Scheidegger wrote: >> This looks like a horrendous solution which will break the world - well >> for us :-). Because integers simply will cease to work, always flushed >> to zero (bye bye loop count

Re: [Mesa-dev] [PATCH 0/3] tgsi, radeonsi: add CANON opcode for float canonicalization

This looks like a horrendous solution which will break the world - well for us :-). Because integers simply will cease to work, always flushed to zero (bye bye loop counter...). The reason is that when you translate from something with a untyped register file to something typed, the obvious

Re: [Mesa-dev] [PATCH 1/2] gallium: Add PIPE_CAP_HALFS

Am 02.09.2017 um 02:55 schrieb Jan Vesely: > Denotes native half precision float operations capability > > Signed-off-by: Jan Vesely > --- > I can change the spelling to HALVES, but simplified english sounded more > appropriate. My spelling of choice would be "FP16"...

Re: [Mesa-dev] [PATCH] st/mesa: fix view template initialization in try_pbo_readpixels

Am 01.09.2017 um 02:32 schrieb Brian Paul: > On 08/31/2017 05:53 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> I think this is what the code was meant to do, albeit as far as I can >> tell >> the redundant initializati

Re: [Mesa-dev] [PATCH] llvmpipe: initialize llvmpipe->dirty with LP_NEW_SCISSOR

Am 30.08.2017 um 16:46 schrieb Brian Paul: > On 08/30/2017 02:43 AM, Roland Scheidegger wrote: >> Am 30.08.2017 um 04:49 schrieb Brian Paul: >>> On 08/29/2017 06:17 PM, Roland Scheidegger wrote: >>>> Looks good to me, thanks. >>>> >>>&g

Re: [Mesa-dev] [PATCH] llvmpipe: initialize llvmpipe->dirty with LP_NEW_SCISSOR

Am 30.08.2017 um 04:49 schrieb Brian Paul: > On 08/29/2017 06:17 PM, Roland Scheidegger wrote: >> Looks good to me, thanks. >> >> Reviewed-by: Roland Scheidegger <srol...@vmware.com> >> >> Albeit I'm not quite sure why it is never set here? > > Thi

Re: [Mesa-dev] [PATCH] llvmpipe: initialize llvmpipe->dirty with LP_NEW_SCISSOR

Looks good to me, thanks. Reviewed-by: Roland Scheidegger <srol...@vmware.com> Albeit I'm not quite sure why it is never set here? This bug looks similar in nature to the uninitialized fb (see 8bfe451ed30918244618608871423b2a72cf9767) and I thought that was impossible to hit with gl

Re: [Mesa-dev] [Mesa-stable] [PATCH v2 1/2] gallivm: correct channel shift logic on big endian

Am 29.08.2017 um 18:51 schrieb Emil Velikov: > On 23 August 2017 at 21:32, Ben Crocker wrote: >> From: Ray Strode >> >> lp_build_fetch_rgba_soa fetches a texel from a texture. >> Part of that process involves first gathering the element >> together from

Re: [Mesa-dev] [PATCH 1/2] mesa: Implement GL_ARB_texture_filter_anisotropic

Am 24.08.2017 um 20:40 schrieb Adam Jackson: > The only difference from the EXT version is bumping the minmax to 16, so > just hit all the drivers at once. > > v2: Fix driver names, add to 17.3 release notes (Ilia Mirkin) > > Reviewed-by: Ilia Mirkin > Signed-off-by: Adam

Re: [Mesa-dev] [PATCH 00/10] gallium: normalize CONST file accesses to 2D

We'll definitely have to adjust some code too, but looks alright to me. For the series: Acked-by: Roland Scheidegger <srol...@vmware.com> Am 23.08.2017 um 18:41 schrieb Nicolai Hähnle: > Hi all, > > Following the discussion on Timothy's std430 packing series, here's > a quic

Re: [Mesa-dev] [PATCH v2 2/2] llvmpipe: lp_build_gather_elem_vec BE fix for 3x16 load

Series looks alright to me. Long term I still think doing the 3x16 fixup in gather is rather confusing, and it probably might break again, but if it works... For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 23.08.2017 um 22:32 schrieb Ben Crocker: > Fix loading

Re: [Mesa-dev] [PATCH 7/8] gallium: remove TGSI opcode SCS

Am 22.08.2017 um 16:38 schrieb Roland Scheidegger: > Am 22.08.2017 um 15:17 schrieb Jose Fonseca: >> On 22/08/17 12:28, Marek Olšák wrote: >>> On Tue, Aug 22, 2017 at 1:10 PM, Jose Fonseca <jfons...@vmware.com> >>> wrote: >>>> On 20/08/17 01:49, Mar

Re: [Mesa-dev] [PATCH 1/7] gallium: add CONSTBUF type to tgsi_file_type

Am 23.08.2017 um 17:03 schrieb Nicolai Hähnle: > On 23.08.2017 16:03, Roland Scheidegger wrote: >> Am 23.08.2017 um 15:49 schrieb Ilia Mirkin: >>> On Wed, Aug 23, 2017 at 9:20 AM, Nicolai Hähnle <nhaeh...@gmail.com> >>> wrote: >>>> On 22.08.2017 16:56,

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