Re: [Mesa-dev] [PATCH] RFC: llvmpipe map scene buffers outside thread. (v2)

Am 09.11.2015 um 05:19 schrieb Dave Airlie: > From: Dave Airlie > > There might be a reason we do this inside the thread, but I'm not aware of it > yet, move stuff around and see if this jogs anyone's memory. > > Doing this outside the thread at least with front buffer

Re: [Mesa-dev] soft/llvmpipe front buffer access and piglit regressions

Am 09.11.2015 um 04:44 schrieb Dave Airlie: > So it appears my patch to enable front buffer access on soft/llvmpipe > causes some piglit regressions. However these are due to piglit having > undefined behaviour where it doesn't create a window but has tests > requiring a front buffer. The new code

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

Am 10.11.2015 um 15:41 schrieb Rob Clark: > On Tue, Nov 10, 2015 at 7:24 AM, Marek Olšák wrote: >>> +/** >>> + * The 'ir' parameter identifies whether the shader state contains TGSI >>> + * tokens, etc. If the driver returns 'PIPE_SHADER_IR_TGSI' for the >>> + *

Re: [Mesa-dev] Introducing OpenSWR: High performance software rasterizer

Am 10.11.2015 um 20:36 schrieb Rowley, Timothy O: > >> On Oct 22, 2015, at 4:17 PM, Jose Fonseca wrote: >> >> They do share a lot already, Mesa, gallium statetracker, and gallivm. If >> further development in openswr is planned, it might require to jump through >> a few

Re: [Mesa-dev] [Mesa-stable] New stable-branch 11.0 candidate pushed

I don't have anything against including it in stable (it is pretty harmless), albeit I didn't tag it because I didn't think it was important enough. While technically it makes things more accurate, it doesn't fix anything known except a couple of piglit tests. Roland Am 08.11.2015 um 12:39

Re: [Mesa-dev] [PATCH 0/3] gallium: add ARB_clear_texture infrastructure

Am 09.11.2015 um 19:40 schrieb Ilia Mirkin: > This is basically a resend of a series I wrote over a year ago. I > don't remember what we hated about it last time, but I'm tempted not > to look. This seems pretty reasonably to me now. I guess I wasn't entirely happy with yet another clear method...

Re: [Mesa-dev] [PATCH 0/3] gallium: add ARB_clear_texture infrastructure

Am 09.11.2015 um 21:12 schrieb Ilia Mirkin: > On Mon, Nov 9, 2015 at 3:07 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 09.11.2015 um 19:40 schrieb Ilia Mirkin: >>> This is basically a resend of a series I wrote over a year ago. I >>> don't remember

Re: [Mesa-dev] [PATCH] mesa: fix MSVC build break in extensions.h

> + > +extern const struct mesa_extension _mesa_extension_table[]; > > > /* Generate enums for the functions below */ > Ahh that was it, I guess that's the simplest possible fix :-). Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___

Re: [Mesa-dev] [PATCH] llvmpipe: disable vsx in ppc due to LLVM PPC bug

Am 17.11.2015 um 15:19 schrieb Oded Gabbay: > This patch makes sure that if we use altivec (VMX) instructions, we don't > use VSX instructions as well, as this cause piglit tests to fail > > For more details, see: https://llvm.org/bugs/show_bug.cgi?id=25503#c7 > > With this patch, ppc64le

Re: [Mesa-dev] RFC: buffer support in TGSI for SSBO/atomic

I don't know much about ssbo, but since it looks like in glsl the coherent etc. bits are on the variables, not the ops, it seems unnatural to mark the op bits instead. So I'd guess it would be better if the variables could be marked instead. If this isn't expressible in tgsi maybe this needs to be

Re: [Mesa-dev] [PATCH 1/2] util: update util_resource_copy_region() for GL_ARB_copy_image

Am 31.10.2015 um 14:37 schrieb Brian Paul: > This primarily means added support for copying between compressed > and uncompressed formats. > --- > src/gallium/auxiliary/util/u_surface.c | 106 > +++-- > 1 file changed, 88 insertions(+), 18 deletions(-) > > diff --git

Re: [Mesa-dev] [PATCH 2/2] llvmpipe: enable PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS

Am 31.10.2015 um 14:37 schrieb Brian Paul: > We disable all 3-channel array formats since we don't support 3-channel > UNORM8 formats. > > Recall that if a 3-channel format is requested by the user, we might > actually wind up using a 4-channel format instead. In fact, llvmpipe > does this

Re: [Mesa-dev] RFC: buffer support in TGSI for SSBO/atomic

seems to be a lot easier to just feed the data to load and forget > about it. That's how it's all encoded in the GLSL IR as well. > > -ilia > > > On Mon, Nov 2, 2015 at 1:56 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> I don't know much about ssbo, but si

Re: [Mesa-dev] [PATCH] gallivm: exit emit_fetch_constat() when no constants

Am 02.11.2015 um 15:56 schrieb Oded Gabbay: > If we don't have any constants, just exit emit_fetch_constat() and don't > call LLVM functions. > > This also prevents a crash that happens when we emit the prologue of the > fragment shader when DEBUG_EXECUTION is set to 1 and we don't have >

Re: [Mesa-dev] [PATCH] llvmpipe: use simple coeffs calc for 128bit vectors

Ok I'm convinced enough it's not worth bothering about the (mostly minimal) performance impact and pushed this (a slightly altered version). Thanks! Roland Am 03.11.2015 um 09:36 schrieb Oded Gabbay: > There are currently two methods in llvmpipe code to calculate coeffs to > be used as inputs

Re: [Mesa-dev] Problems with accuracy of coeffs_init + attribs_update

Am 02.11.2015 um 14:46 schrieb Oded Gabbay: > On Thu, Oct 29, 2015 at 9:37 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 29.10.2015 um 19:44 schrieb Oded Gabbay: >>> On Thu, Oct 29, 2015 at 5:31 PM, Roland Scheidegger <srol...@vmware.com> >&

Re: [Mesa-dev] RFC: buffer support in TGSI for SSBO/atomic

eed the now free bits should be ok. Roland > > -ilia > > On Mon, Nov 2, 2015 at 2:49 PM, Roland Scheidegger <srol...@vmware.com> wrote: >> Ok, I guess if it's really flagged on the instructions in hw, it seems >> reasonable to do it on the instructions in tgsi as well.

Re: [Mesa-dev] RFC: buffer support in TGSI for SSBO/atomic

Am 02.11.2015 um 22:39 schrieb Dave Airlie: > On 3 November 2015 at 07:31, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 02.11.2015 um 20:55 schrieb Ilia Mirkin: >>> FTR these are the various operators on nvidia hw: >>> >>> https

Re: [Mesa-dev] [PATCH] draw: fix splitting of line loops

I thought just changing the prim type would cause the loop to not get closed in the end, albeit I looked at it only briefly (I thought the DRAW_SPLIT_AFTER/BEFORE flags were supposed to be able to deal with this but couldn't figure out how). But if this works correctly, Reviewed-by: Roland

Re: [Mesa-dev] [PATCH] svga: fix incorrect round-down arithmetic

Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 19.10.2015 um 16:42 schrieb Brian Paul: > Spotted by Roland. Luckily, this code should never really be hit > since the const buffer size and offset should already be multiples > of 16. I could probably add more assertions

Re: [Mesa-dev] [PATCH] st/fbo: use pipe_surface_release instead of pipe_surface_reference

Am 14.10.2015 um 18:03 schrieb Krzysztof A. Sobiecki: > From: Krzysztof Sobiecki > > pipe_surface_reference have problems with deleted contexts, > so use of pipe_surface_release might be more appropriate. > > Fixes Wasteland 2 Director's Cut crash on start. > --- >

Re: [Mesa-dev] [PATCH 02/10] gallivm: implement the correct version of LRP

Am 15.10.2015 um 16:44 schrieb Marek Olšák: > Any comment or is this okay with people? Given, "(1-t)*a + t*b", the > original code didn't return b for t=1 because it's "floating-point". > > Marek > > On Sun, Oct 11, 2015 at 3:29 AM, Marek Olšák wrote: >> From: Marek Olšák

Re: [Mesa-dev] [PATCH 10/17] st/mesa: make Z/S drawpix shaders independent of variants, don't use Mesa IR

Am 08.10.2015 um 02:02 schrieb Marek Olšák: > Hi Brian, > > This is the commit that broke DrawPixels on llvmpipe, but not radeonsi > and softpipe. It's fixed in v2, which is attached. > > Marek > > On Tue, Oct 6, 2015 at 3:26 AM, Marek Olšák wrote: >> From: Marek Olšák

Re: [Mesa-dev] [PATCH 10/17] st/mesa: make Z/S drawpix shaders independent of variants, don't use Mesa IR

; some reason. > > Marek > > On Oct 8, 2015 5:12 AM, "Roland Scheidegger" <srol...@vmware.com > <mailto:srol...@vmware.com>> wrote: > > Am 08.10.2015 um 02:02 schrieb Marek Olšák: > > Hi Brian, > > > > Thi

Re: [Mesa-dev] [PATCH 10/17] st/mesa: make Z/S drawpix shaders independent of variants, don't use Mesa IR

Am 08.10.2015 um 16:46 schrieb Marek Olšák: > > On Oct 8, 2015 4:03 PM, "Roland Scheidegger" <srol...@vmware.com > <mailto:srol...@vmware.com>> wrote: >> >> Was that because stencil used sampler 1 but sview 0 which looks >> definitely wrong as

Re: [Mesa-dev] [PATCH] r600g: Implement ARB_texture_view

Interesting it doesn't work with llvmpipe, I thought there were tests for this using some other state tracker... My guess is that (for llvmpipe) in prepare_shader_sampling() and lp_setup_set_fragment_sampler_views() we miss adjusting the mip offsets since we only do that if it's an array target,

Re: [Mesa-dev] [PATCH 2/4] gallium: add new properties for clip and cull distance usage

I don't have anything against new properties but why exactly is it needed? As far as I can tell, clip/cull distances aren't declared as arrays but just (up to two each) ordinary outputs, thus using the usage masks should work just fine. Or is this handled differently by some shader stages? Roland

Re: [Mesa-dev] [RFCv0 2/8] gallium: refactor pipe_shader_state to support multiple IR's

Am 19.10.2015 um 21:54 schrieb Rob Clark: > The goal is to allow the pipe driver to request something other than > TGSI, but detect whether what is getting is TGSI vs what it requested. > The pipe drivers will always have to support TGSI (and convert that into > whatever it is that they prefer),

Re: [Mesa-dev] [RFCv0 2/8] gallium: refactor pipe_shader_state to support multiple IR's

Am 19.10.2015 um 21:54 schrieb Rob Clark: > The goal is to allow the pipe driver to request something other than > TGSI, but detect whether what is getting is TGSI vs what it requested. > The pipe drivers will always have to support TGSI (and convert that into > whatever it is that they prefer),

Re: [Mesa-dev] [PATCH 2/4] gallium: add new properties for clip and cull distance usage

> distances are used. > > On Mon, Oct 19, 2015 at 5:02 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> I don't have anything against new properties but why exactly is it >> needed? As far as I can tell, clip/cull distances aren't declared as >> arrays but ju

Re: [Mesa-dev] [RFCv0 0/8] gallium: add support for NIR as alternate IR

The overall idea looks quite sane to me. Albeit obviously as you mentioned you'd really have to support all shader stages and deal with the variants (though there aren't many left). Roland Am 19.10.2015 um 21:54 schrieb Rob Clark: > From: Rob Clark > > (grr, resend to

Re: [Mesa-dev] [PATCH 2/4] gallium: add new properties for clip and cull distance usage

Am 19.10.2015 um 23:44 schrieb Marek Olšák: > On Mon, Oct 19, 2015 at 11:31 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Yes, but I still don't see much change from getting this information >> from the property rather than how tgsi_scan does it now, which is by

Re: [Mesa-dev] [PATCH 2/4] gallium: add new properties for clip and cull distance usage

Am 20.10.2015 um 01:26 schrieb Marek Olšák: > On Tue, Oct 20, 2015 at 12:03 AM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 19.10.2015 um 23:44 schrieb Marek Olšák: >>> On Mon, Oct 19, 2015 at 11:31 PM, Roland Scheidegger <srol...@vmware.com> >>&

Re: [Mesa-dev] [PATCH 2/4] gallium: add new properties for clip and cull distance usage

Am 20.10.2015 um 15:40 schrieb Marek Olšák: > On Tue, Oct 20, 2015 at 3:25 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 19.10.2015 um 23:44 schrieb Marek Olšák: >>> On Mon, Oct 19, 2015 at 11:31 PM, Roland Scheidegger <srol...@vmware.com> >>&

Re: [Mesa-dev] Introducing OpenSWR: High performance software rasterizer

Am 20.10.2015 um 19:11 schrieb Rowley, Timothy O: > Hi. I'd like to introduce the Mesa3D community to a software project > that we hope to upstream. We're a small team at Intel working on > software defined visualization (http://sdvis.org/), and have > opensource projects in both the raytracing

Re: [Mesa-dev] [PATCH] draw: fix splitting of line loops (v2)

Looks good to me - this stuff is tricky... Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 21.10.2015 um 01:21 schrieb Brian Paul: > When the draw module splits long line loops, the sections are emitted > as line strips. But the primitive type wasn't set correctly so ea

Re: [Mesa-dev] [PATCH] svga: add switch case for PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT

reen, > unsigned shader, > case PIPE_SHADER_CAP_TGSI_FMA_SUPPORTED: > case PIPE_SHADER_CAP_TGSI_ANY_INOUT_DECL_RANGE: >return 0; > + case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT: > + return 32; > default: >debug_printf("Unexpected vgpu10 shade

Re: [Mesa-dev] [PATCH 09/10] vbo: fix GL_LINE_LOOP stray line bug

FWIW this probably fixes https://bugs.freedesktop.org/show_bug.cgi?id=49779 and https://bugs.freedesktop.org/show_bug.cgi?id=28130 (in contrast to 81174 which as you noted suffers both from a vbo and draw issue). (I believe the issue in draw is pretty much the same, since things are split with too

Re: [Mesa-dev] [PATCH 2/4] gallium: add new properties for clip and cull distance usage

Am 19.10.2015 um 23:44 schrieb Marek Olšák: > On Mon, Oct 19, 2015 at 11:31 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Yes, but I still don't see much change from getting this information >> from the property rather than how tgsi_scan does it now, which is by

Re: [Mesa-dev] [PATCH 03/10] radeonsi: disable NaNs for LS and HS

FWIW I'm still baffled by this shader bit. NaNs are absolutely required to be generated and handled as NaNs in shaders (albeit conversion to ints will make them 0) by DX10 (there's plenty of tests which actually check for this). And generally, you really want to generate NaNs for newer glsl

Re: [Mesa-dev] [PATCH 01/10] gallivm: supply correct opcode info to emit functions

Am 11.10.2015 um 03:29 schrieb Marek Olšák: > From: Marek Olšák > > This is useful only when emit functions use it. > The new radeonsi min/max opcode implementation requires this. > --- > src/gallium/auxiliary/gallivm/lp_bld_tgsi.c | 5 + > 1 file changed, 5

Re: [Mesa-dev] [PATCH 01/10] gallivm: supply correct opcode info to emit functions

Am 12.10.2015 um 00:55 schrieb Marek Olšák: > On Sun, Oct 11, 2015 at 11:15 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> So why do you need to set the info back after action->emit? If you want >> to set that always so that information can be used, looks fin

Re: [Mesa-dev] [PATCH 01/10] gallivm: supply correct opcode info to emit functions

Am 11.10.2015 um 12:39 schrieb Marek Olšák: > On Sun, Oct 11, 2015 at 4:22 AM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 11.10.2015 um 03:29 schrieb Marek Olšák: >>> From: Marek Olšák <marek.ol...@amd.com> >>> >>> This is useful on

Re: [Mesa-dev] [PATCH 03/10] radeonsi: disable NaNs for LS and HS

Am 11.10.2015 um 12:58 schrieb Marek Olšák: > On Sun, Oct 11, 2015 at 4:29 AM, Roland Scheidegger <srol...@vmware.com> > wrote: >> FWIW I'm still baffled by this shader bit. >> NaNs are absolutely required to be generated and handled as NaNs in >> shaders (albeit con

Re: [Mesa-dev] [PATCH] llvmpipe: fix fp64 inputs to geom shader.

Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 12.10.2015 um 07:55 schrieb Dave Airlie: > From: Dave Airlie <airl...@redhat.com> > > This fixes the fetching of fp64 inputs to the geometry shader, > > this fixes the recently posted piglit's > arb_gpu_

Re: [Mesa-dev] llvmpipe broken on Skylake Pentium (LP_NATIVE_VECTOR_WIDTH=128)

Am 12.10.2015 um 21:27 schrieb Adam Jackson: > I'm having some difficulty getting llvmpipe working on a Skylake > Pentium, which has the charming property of not having AVX support at > all (Skylake Cores have AVX2, and Xeons have AVX512, but Pentium seems > to be the new way of spelling Celeron).

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Am 12.10.2015 um 21:41 schrieb Roland Scheidegger: > Am 12.10.2015 um 20:33 schrieb Rob Clark: >> On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner <matts...@gmail.com> wrote: >>> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark <robdcl...@gmail.com> wrote: >>>&g

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Am 12.10.2015 um 20:33 schrieb Rob Clark: > On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner wrote: >> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark wrote: >>> On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand >>> wrote: >> +/**

Re: [Mesa-dev] llvmpipe broken on Skylake Pentium (LP_NATIVE_VECTOR_WIDTH=128)

Am 12.10.2015 um 21:57 schrieb Roland Scheidegger: > Am 12.10.2015 um 21:27 schrieb Adam Jackson: >> I'm having some difficulty getting llvmpipe working on a Skylake >> Pentium, which has the charming property of not having AVX support at >> all (Skylake Cores have AVX2,

Re: [Mesa-dev] llvmpipe broken on Skylake Pentium (LP_NATIVE_VECTOR_WIDTH=128)

Am 12.10.2015 um 22:47 schrieb Adam Jackson: > On Mon, 2015-10-12 at 21:57 +0200, Roland Scheidegger wrote: > >> Note that the vector width doesn't really control if avx is used or not, >> since that's a decision which llvm does on its own (we do set it >> manually if

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Am 12.10.2015 um 22:37 schrieb Rob Clark: > On Mon, Oct 12, 2015 at 3:41 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 12.10.2015 um 20:33 schrieb Rob Clark: >>> On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner <matts...@gmail.com> wrote: >>>>

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Am 13.10.2015 um 01:01 schrieb Matt Turner: > On Mon, Oct 12, 2015 at 3:07 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> As far as I can tell (and I could easily be wrong here...) intel hw >> doesn't have explicit conversion instruction, you just say it's a f16 &

Re: [Mesa-dev] llvmpipe broken on Skylake Pentium (LP_NATIVE_VECTOR_WIDTH=128)

Am 13.10.2015 um 19:59 schrieb Adam Jackson: > On Mon, 2015-10-12 at 22:55 +0200, Roland Scheidegger wrote: > >> I don't know that looks like a generic string you're getting back. >> x86-64 IIRC implies sse2 in llvm, but not the other sseX flags (and if >> we detected

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Am 13.10.2015 um 00:26 schrieb Rob Clark: > On Mon, Oct 12, 2015 at 6:07 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 12.10.2015 um 22:37 schrieb Rob Clark: >>> On Mon, Oct 12, 2015 at 3:41 PM, Roland Scheidegger <srol...@vmware.com> >>>

Re: [Mesa-dev] [RFC] gallium: add interface for writable shader images

Am 07.07.2015 um 22:35 schrieb Jose Fonseca: On 07/07/15 21:28, Ilia Mirkin wrote: On Tue, Jul 7, 2015 at 4:24 PM, Jose Fonseca jfons...@vmware.com wrote: I'm not experienced with the semantics around resources that can be read/written by shaders, so I can't really make educated comments.

Re: [Mesa-dev] [PATCH 1/4] radeon, r200: remove unused variable texmicrotile

... Reviewed-by: Roland Scheidegger srol...@vmware.com Am 09.07.2015 um 22:13 schrieb Emil Velikov: Dead since at least 2009 with commit ccf7814a315(radeon: major cleanups removing old dead codepaths.) Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/mesa/drivers/dri/r200

Re: [Mesa-dev] [PATCH 3/4] radeon, r200: allow hyperz for radeon DRM module v2

Am 10.07.2015 um 05:44 schrieb Michel Dänzer: On 10.07.2015 05:13, Emil Velikov wrote: The original code only half considered hyperz as an option. As per previous commit major != 2 cannot occur we can simply things, and allow users to set the option if they choose to do so. Signed-off-by:

Re: [Mesa-dev] [PATCH 3/4] radeon, r200: allow hyperz for radeon DRM module v2

Am 11.07.2015 um 11:25 schrieb Marek Olšák: On Fri, Jul 10, 2015 at 11:02 PM, Roland Scheidegger srol...@vmware.com wrote: Am 10.07.2015 um 19:41 schrieb Emil Velikov: On 10 July 2015 at 13:18, Roland Scheidegger srol...@vmware.com wrote: Am 10.07.2015 um 05:44 schrieb Michel Dänzer

Re: [Mesa-dev] [PATCH 19/19] st/mesa: enable shader subroutine

Should expose that only if hw has glsl 130 support? Roland Am 09.07.2015 um 09:17 schrieb Dave Airlie: From: Dave Airlie airl...@redhat.com I'm not sure if we shouldn't enable this everywhere and rip out the API checks, discuss, Signed-off-by: Dave Airlie airl...@redhat.com ---

Re: [Mesa-dev] [PATCH 4/4] gallium: add interface for writable shader buffers

This looks all pretty reasonable, though I can't really figure out if we could translate from d3d11 to that. In particular, it's UAVs for all of buffers and images, and I'm not entirely sure if it's actually possible to figure out which UAV entries are a shader buffer and which ones are a shader

Re: [Mesa-dev] [PATCH 3/4] radeon, r200: allow hyperz for radeon DRM module v2

Am 10.07.2015 um 19:41 schrieb Emil Velikov: On 10 July 2015 at 13:18, Roland Scheidegger srol...@vmware.com wrote: Am 10.07.2015 um 05:44 schrieb Michel Dänzer: On 10.07.2015 05:13, Emil Velikov wrote: The original code only half considered hyperz as an option. As per previous commit major

Re: [Mesa-dev] [PATCH v3] llvmpipe: disable VSX in ppc due to LLVM PPC bug

* Make sure VSX instructions are disabled > +* See LLVM bug https://llvm.org/bugs/show_bug.cgi?id=25503#c7 > +*/ > + if (util_cpu_caps.has_altivec) { > + MAttrs.push_back("-vsx"); > + } > +#endif > #endif > > builder.setMAttrs(MAttrs); > Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 01/18] mesa/extensions: Remove array sentinel

Am 11.11.2015 um 23:13 schrieb Nanley Chery: > > > On Wed, Nov 11, 2015 at 2:07 PM, Chad Versace > wrote: > > On Fri 30 Oct 2015, Nanley Chery wrote: > > From: Nanley Chery

Re: [Mesa-dev] [PATCH v2] llvmpipe: convert double to long long instead of unsigned long long

Oh, that's quite a subtle bug... Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 03.09.2015 um 18:00 schrieb Oded Gabbay: > round(val*dscale) produces a double result, as val and dscale are double. > However, LLVMConstInt receives unsigned long long, so there is an > impl

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

Am 09.09.2015 um 15:04 schrieb Roland Scheidegger: > Am 09.09.2015 um 05:56 schrieb Ian Romanick: >> On 08/15/2015 02:24 AM, Francisco Jerez wrote: >>> Roland Scheidegger <srol...@vmware.com> writes: >>> >>>> I guess though you'd

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

Am 09.09.2015 um 05:56 schrieb Ian Romanick: > On 08/15/2015 02:24 AM, Francisco Jerez wrote: >> Roland Scheidegger <srol...@vmware.com> writes: >> >>> I guess though you'd need these bits when implementing things like >>> ARB_fragment_shader_ordering?

Re: [Mesa-dev] [PATCH v2 00/10] Reroll of textureQueryLod in softpipe

een.c | 2 +- > src/gallium/drivers/softpipe/sp_tex_sample.c | 403 > +-- > src/gallium/drivers/softpipe/sp_tex_sample.h | 23 +- > 7 files changed, 393 insertions(+), 96 deletions(-) > Looks good to me, thanks for

Re: [Mesa-dev] [PATCH 1/5] svga: Ignore pipe_rasterizer_state::line_last_pixel.

For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 14.09.2015 um 13:09 schrieb Jose Fonseca: > Altough SVGA3D_RS_LASTPIXEL renderstate exists, most backends ignore it. > --- > src/gallium/drivers/svga/svga_context.h | 1 - > src/ga

Re: [Mesa-dev] [PATCH] st/mesa: avoid integer overflows with buffers >= 512MB

4GB buffers (I think though for that we're missing way more things). Either way though, Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 16.09.2015 um 01:32 schrieb Ilia Mirkin: > This fixes failures with the newly-submitted max-size texture buffer > piglit test for GPUs expos

Re: [Mesa-dev] [PATCH 1/2] r600g: Support I2D/U2D/D2I/D2U

Just on a very quick glance, seems somewhat odd this function is named "cypress" whereas the other 64bit ones are named "cayman". In any case, saying enabling support for chips which have hative support isn'quite correct, since there's a couple more which should be able to do it (rv670, rv770,

Re: [Mesa-dev] [PATCH 7/7] softpipe: Constify variables

of the faces storage hack. For the series: Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 11.09.2015 um 20:07 schrieb Krzesimir Nowak: > This commit makes a lot of variables constant - this is basically done > by moving the computation to variable definition. Some of them

Re: [Mesa-dev] [PATCH] tgsi, softpipe: capitalize the tgsi_sampler_control enum values

args.gather_only = filt_args->control == TGSI_SAMPLER_GATHER; >if ((unsigned)level0 >= psview->u.tex.last_level) { > if (level0 < 0) > args.level = psview->u.tex.first_level; > @@ -2672,7 +2672,7 @@ sample_compare(struct sp_sampler_view *sp_sview, &g

Re: [Mesa-dev] [PATCH 1/4] tgsi: add a TXQS opcode to retrieve the number of texture samples

+402,7 @@ struct tgsi_property_data { > #define TGSI_OPCODE_ENDLOOP 101 > #define TGSI_OPCODE_ENDSUB 102 > #define TGSI_OPCODE_TXQ_LZ 103 /* TXQ for mipmap level 0 */ > +#define TGSI_OPCODE_TXQS104 > /* gap */ > #define TGSI_OPCODE_NOP 107 > > Reviewed-by: Roland Scheidegger <srol...@vmware.com> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] r600g: Support I2D/U2D/D2I/D2U

Am 11.09.2015 um 05:14 schrieb Dave Airlie: > On 11 September 2015 at 12:37, Roland Scheidegger <srol...@vmware.com> wrote: >> Just on a very quick glance, seems somewhat odd this function is named >> "cypress" whereas the other 64bit ones are named "caym

Re: [Mesa-dev] [PATCH 0/4] gallium: add support for retrieving number of texture samples

Am 11.09.2015 um 05:15 schrieb Ilia Mirkin: > My hope was (as you can see in the last patch) to enable this for all > drivers that support MS textures. I've got nv50/nvc0/r600g covered. > > RadeonSI will have to read the data from the texture descriptor. I'm > totally unfamiliar with LLVM, the

Re: [Mesa-dev] [PATCH 2/2] st/mesa: try PIPE_BIND_RENDER_TARGET when choosing float texture formats

render into) - there was lots of hw which couldn't do that when fbos were new. (Albeit I only glanced over the patches at least that's what I think will happen.) Roland > >> On 09/29/2015 11:46 AM, Roland Scheidegger wrote: >>> >>> If that was due to some rgb vs. rgbx

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

Am 28.09.2015 um 15:51 schrieb Marek Olšák: > On Mon, Sep 28, 2015 at 2:55 PM, Jose Fonseca wrote: >> On 27/09/15 19:14, Marek Olšák wrote: >>> >>> Hi, >>> >>> For some reason, st/mesa assumes that shaders can't be shared by >>> multiple contexts and therefore has a context

Re: [Mesa-dev] [PATCH 1/3] gallium: add per-sample interpolation control into rasterizer state

Can't say I'm a big fan of doing essentially the same thing with different methods, but well it's coming from GL, and if it helps some drivers... Acked-by: Roland Scheidegger <srol...@vmware.com> Am 02.10.2015 um 00:24 schrieb Marek Olšák: > Ping > > On Tue, Sep 29, 2015 at 2:37

Re: [Mesa-dev] [PATCH 1/3] gallium: add per-sample interpolation control into rasterizer state

Am 02.10.2015 um 12:19 schrieb Marek Olšák: > On Fri, Oct 2, 2015 at 3:13 AM, Roland Scheidegger <srol...@vmware.com> wrote: >> Can't say I'm a big fan of doing essentially the same thing with >> different methods, but well it's coming from GL, and if it helps some >

Re: [Mesa-dev] Question: st/mesa and context-shareable shaders

Am 30.09.2015 um 11:41 schrieb Erik Faye-Lund: > On Mon, Sep 28, 2015 at 4:39 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> >> In short, for simplicity, only things were sharable which were really >> required to be shared (pretty much just actual resources

Re: [Mesa-dev] [PATCH 2/2] st/mesa: try PIPE_BIND_RENDER_TARGET when choosing float texture formats

Paul: > I was actually thinking of expanding this change to cover _all_ color > formats but wanted to take a small step first. What do you think? > > -Brian > > On 09/29/2015 11:46 AM, Roland Scheidegger wrote: >> If that was due to some rgb vs. rgbx thing (that is, c

Re: [Mesa-dev] [PATCH 2/2] st/mesa: try PIPE_BIND_RENDER_TARGET when choosing float texture formats

really required) Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 29.09.2015 um 17:39 schrieb Brian Paul: > For 8-bit RGB(A) texture formats we set the PIPE_BIND_RENDER_TARGET flag > to try to get a hardware format which also supports rendering (for FBO > textures). Do

Re: [Mesa-dev] [PATCH 3/9] softpipe: Split compute_lambda_lod into two functions

Just a minor nitpick. Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak: > textureQueryLod returns a vec2 with a mipmap information and a > LOD. The latter needs to be not clamped. > --- > src/gallium/drivers/softpipe/sp_tex_sample.c | 55 > > 1 file changed, 39

Re: [Mesa-dev] [PATCH 7/9] softpipe: Add functions for computing mipmap level

Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak: > These functions will be used by textureQueryLod. > --- > src/gallium/drivers/softpipe/sp_tex_sample.c | 100 > +-- > src/gallium/drivers/softpipe/sp_tex_sample.h | 7 ++ > 2 files changed, 101 insertions(+), 6

Re: [Mesa-dev] [PATCH 5/9] softpipe: Split code getting a filter into separate function

Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak: > This function will be later used by textureQueryLod. The > img_filter_func are optional, because textureQueryLod will not need > them. > --- > src/gallium/drivers/softpipe/sp_tex_sample.c | 53 > +++- > 1 file changed, 37

Re: [Mesa-dev] [PATCH 6/9] softpipe: Split 3D to 2D coords conversion into separate function.

Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak: > This is to avoid tying the conversion to sampling - textureQueryLod > will need to do the conversion too, but it does not do any sampling. > > So instead of a "sample" vfunc, there is a "convert" vfunc. The > drawback of this approach is that a

Re: [Mesa-dev] [PATCH 8/9] tgsi: Add code for handling lodq opcode

Yes, using a new function is definitely the right way to go imho. Apart from the things mentioned by Brian, the series looks good to me. Roland Am 09.09.2015 um 12:35 schrieb Krzesimir Nowak: > This introduces new vfunc in tgsi_sampler just for this opcode. I > decided against extending

Re: [Mesa-dev] [PATCH] mesa: fix mipmap generation for immutable, compressed textures

Ping? Am 20.09.2015 um 04:33 schrieb srol...@vmware.com: > From: Roland Scheidegger <srol...@vmware.com> > > If the immutable compressed texture didn't have the full mip pyramid, > this didn't work, because it tried to generate mip levels for non-existing > levels. _mesa

Re: [Mesa-dev] [RFC] Vendor-neutral dispatch library for OpenGL

FWIW from a high level point of view this makes all sense to me. It is however definitely not my field of expertise, but whatever makes it easier to have multiple drivers installed is imho a good thing... Some more feedback from mesa people which are more familiar with the gl api dispatch stuff

Re: [Mesa-dev] [PATCH] softpipe: implement some support for multiple viewports

So, which tests did it fail? Am 07.12.2015 um 14:31 schrieb Edward O'Callaghan: > Mostly related to making sure the rasterizer can correctly > pick out the correct scissor box for the current viewport. > > Signed-off-by: Edward O'Callaghan > --- >

Re: [Mesa-dev] [PATCH] mesa: fix VIEWPORT_INDEX_PROVOKING_VERTEX and LAYER_PROVOKING_VERTEX queries

Am 01.12.2015 um 20:35 schrieb Brian Paul: > On 12/01/2015 12:07 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> These are implementation-dependent queries, but so far we just >> returned the >> value of whatever the curr

Re: [Mesa-dev] AppVeyor: Build failed: mesa 39

Am 04.12.2015 um 03:58 schrieb AppVeyor: > > Build mesa 39 failed > <https://ci.appveyor.com/project/jrfonseca-fdo/mesa/build/39> > > Commit 51140f452a by Roland Scheidegger <mailto:srol...@vmware.com> on > 12/4/2015 2:42 AM: > draw: fix clipping of layer/

Re: [Mesa-dev] softpipe: V.2 implement some support for multiple viewports

Am 09.12.2015 um 05:16 schrieb Edward O'Callaghan: > This fixes my initial attempt so that piglit now passes 14/14. Thanks > to a couple of tips from Roland in the previous patch I was able to > fix the remaining issue. This should be golden now. > Great that you got it working! Please send the

Re: [Mesa-dev] [RFC 2/3] gallium: Move nv50 clear_texture impl down to util_surface

One problem with this is that clear_render_target and clear_depth_stencil honor render condition, whereas clear_texture does not. nv50 got it wrong, but I care a lot more when that wrongness is moved to util. This could be fixed by making clear_render_target and clear_depth_stencil optionally

Re: [Mesa-dev] [RFC 2/3] gallium: Move nv50 clear_texture impl down to util_surface

Am 03.12.2015 um 23:48 schrieb Ilia Mirkin: > On Thu, Dec 3, 2015 at 4:44 AM, Edward O'Callaghan > wrote: >> ARB_clear_texture is reasonably generic enough that it should >> be moved down to become part of the fallback mechanism of >> pipe->clear_texture. >> >>

[Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

Trying to fix some draw bugs with layer/vp outputs (and clipping), I was wondering if GL actually guarantees sane results if the layer/vp index isn't the same on all vertices. And sure it seems it does, albeit it's implementation-dependent. Specifically (from gl 4.4 core, page 388) "viewport

Re: [Mesa-dev] [PATCH] i965: Increase BRW_MAX_UBO to 15.

That's interesting. Some d3d10 docs list this indeed as 15+1 (and that +1 is really needed too for the immediates, as you can have indirectly addressed immediates which are little more than ordinary uniforms for the hw). So does d3d11:

Re: [Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

EmitVertex() time. > > -ilia > > > > On Tue, Dec 1, 2015 at 12:43 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Trying to fix some draw bugs with layer/vp outputs (and clipping), I was >> wondering if GL actually guarantees sane results if the

Re: [Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

... Roland Am 01.12.2015 um 19:41 schrieb Roland Scheidegger: > I don't think that will work with draw (can't see why it would), and > don't plan on fixing it (at least not now). > In d3d10, this of course would work (at least if you emit the layer per > prim), because it requires th

Re: [Mesa-dev] softpipe: V.2 implement some support for multiple viewports

it actually enables the extension. Roland > Cheers, > Edward. > > On 2015-12-10 02:38, Roland Scheidegger wrote: >> Am 09.12.2015 um 05:16 schrieb Edward O'Callaghan: >>> This fixes my initial attempt so that piglit now passes 14/14. Thanks >>> to a couple of t

<    7   8   9   10   11   12   13   14   15   16   >