Re: [Mesa-dev] [PATCH 1/2] tgsi: texture types

und samplers.. but I guess that is unrelated and a separate patch) > > BR, > -R > > On Wed, Jun 10, 2015 at 2:55 PM, Roland Scheidegger > wrote: >> My biggest problem with that is the initial case I saw as a problem: >> draw is going to modify these shaders in some cas

Re: [Mesa-dev] [PATCH 1/2] tgsi: texture types

but I don't see that happening for OpenGL anyway. >>>> >>>> Marek >>>> >>>> On Wed, Jun 10, 2015 at 8:59 PM, Rob Clark wrote: >>>>> >>>>> So, afaiu, everything that might insert a sampler is using >>>>&g

Re: [Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls

For 1-4/7, 6/7: Reviewed-by: Roland Scheidegger I think though using two exclusive booleans is really ugly. Probably should just use a tgsi_return_type enum instead indeed, and treat the unorm/snorm cases as float. I'm not entirely sure what the unorm/snorm types are for neither, this is a

Re: [Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls

Am 11.06.2015 um 17:33 schrieb Rob Clark: > On Thu, Jun 11, 2015 at 10:53 AM, Roland Scheidegger > wrote: >> For 1-4/7, 6/7: >> Reviewed-by: Roland Scheidegger >> >> I think though using two exclusive booleans is really ugly. Probably >> should just use a

Re: [Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls

tgsi_tex); > + unsigned tgsi_tex, > + enum tgsi_return_type stype); > > > extern void * > @@ -136,13 +138,13 @@ util_make_fs_blit_msaa_stencil(struct pipe_context > *pipe, > void * > util_make_fs_msaa_resolve(struct pipe_context *p

Re: [Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls

Am 12.06.2015 um 02:02 schrieb Rob Clark: > On Thu, Jun 11, 2015 at 5:47 PM, Brian Paul wrote: >> On 06/11/2015 02:38 PM, Rob Clark wrote: >>> >>> From: Rob Clark >>> >>> Some hardware needs to know the sampler type. Update the blit related >>> shaders to include SVIEW decl. >>> >>> Signed-off-b

Re: [Mesa-dev] [PATCH 5/7] util/blitter (and friends): generate appropriate SVIEW decls

Am 12.06.2015 um 22:38 schrieb Rob Clark: > On Fri, Jun 12, 2015 at 9:47 AM, Rob Clark wrote: >> On Thu, Jun 11, 2015 at 8:36 PM, Roland Scheidegger >> wrote: >>> Am 12.06.2015 um 02:02 schrieb Rob Clark: >>>> On Thu, Jun 11, 2015 at 5:47 PM, Brian Paul wrot

Re: [Mesa-dev] [PATCH] glsl: Fail linkage when UBO exceeds GL_MAX_UNIFORM_BLOCK_SIZE.

ect ones at all) in the shader. Reviewed-by: Roland Scheidegger Am 16.06.2015 um 12:29 schrieb Jose Fonseca: > It's not totally clear whether other Mesa drivers can safely cope with > over-sized UBOs, but at least for llvmpipe receiving a UBO larger than > its limit causes problem

Re: [Mesa-dev] [PATCHES] Tessellation is here

No. And as far as I know noone is working on it for llvmpipe. If I'd write a to do list for llvmpipe, that would probably be on page 50 or so :-). But patches always welcome... Roland Am 17.06.2015 um 14:21 schrieb Ilyes Gouta: > Hi, > > On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov

Re: [Mesa-dev] [PATCHES] Tessellation is here

de bakes in the texture format, and with dynamic indexing this isn't known at compile time as it can differ for each texture bound), but everything GL4 is not even really on a to do list... Feel free to work on it though... Roland Am 17.06.2015 um 15:00 schrieb Ilyes Gouta: > Hi, >

Re: [Mesa-dev] [PATCH] llvmpipe: Truncate the binned constants to max const buffer size.

IZE); > const ubyte *current_data = NULL; > int num_constants; > > + STATIC_ASSERT(DATA_BLOCK_SIZE >= LP_MAX_TGSI_CONST_BUFFER_SIZE); > + > if (buffer) { > /* resource buffer */ > current_data = (ubyte *) llvmpipe_resource_data(buffer); > 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] tgsi: handle indirect sampler arrays. (v2)

Should there be some clamping somewhere to prevent crashes due to out-of-bound unit index? In any case, Reviewed-by: Roland Scheidegger Am 22.06.2015 um 05:18 schrieb Dave Airlie: > This is required for ARB_gpu_shader5 support in softpipe. > > v2: add support to txd/txf/txq paths. &g

Re: [Mesa-dev] [PATCH 2/2] draw/gallivm: add invocation ID support for llvmpipe.

For the series: Reviewed-by: Roland Scheidegger Am 22.06.2015 um 06:01 schrieb Dave Airlie: > From: Dave Airlie > > This extends the draw code to add support for invocations. > > Signed-off-by: Dave Airlie > --- > src/gallium/auxiliary/draw/draw_gs.c|

Re: [Mesa-dev] [PATCH] tgsi: handle indirect sampler arrays. (v2)

Am 23.06.2015 um 07:53 schrieb Dave Airlie: > On 22 June 2015 at 21:20, Roland Scheidegger wrote: >> Should there be some clamping somewhere to prevent crashes due to >> out-of-bound unit index? > > The spec says its undefined, I'm never sure if that means explo

Re: [Mesa-dev] [PATCH 13/14] st/mesa: set default tessellation levels

Another option would be to provide (no-op) implementations for all drivers. But I think generally we indeed check if the function is available in the state tracker before calling it for such things. Roland Am 23.06.2015 um 06:11 schrieb Ilia Mirkin: > This needs to be guarded on availability of t

Re: [Mesa-dev] [PATCH] softpipe, llvmpipe: fix PIPE_SHADER_CAP_MAX_INPUTS value

Reviewed-by: Roland Scheidegger And probably reference the other two too (91100,91101) if it fixes them. Roland Am 25.06.2015 um 01:09 schrieb Brian Paul: > Reviewed-by: Brian Paul > > Want to reference bug 91099 in the commit msg? > > > On 06/24/2015 04:59 PM, Marek Ol

Re: [Mesa-dev] [RFC] gallium/hud: fix issue w/ tgsi_to_nir

I thought this was needed by something in the gl state tracker. relative addressing with ARB_vp maybe, can't remember... I dunno if all places where this is used are fixed up it can go. Roland Am 25.06.2015 um 01:31 schrieb Rob Clark: > tgsi.rst currently says: > > > If no ArrayID is speci

Re: [Mesa-dev] [PATCH 2/3] gallivm: add fp64 support.

Don't worry about the AoS stuff. Only meant to do simple things. Looks good overall, I guess it makes sense to not split execution too (so you'd have native hw vector size there), llvm should handle that pretty well these days (the sse intrinsics won't get used that way probably (though there's a

Re: [Mesa-dev] [PATCH 2/3] gallivm: add fp64 support.

Am 29.06.2015 um 22:18 schrieb Dave Airlie: > On 30 June 2015 at 00:58, Roland Scheidegger wrote: >> Don't worry about the AoS stuff. Only meant to do simple things. >> >> Looks good overall, I guess it makes sense to not split execution too >> (so you'd ha

Re: [Mesa-dev] [PATCH 2/3] gallivm: add fp64 support.

Am 30.06.2015 um 03:42 schrieb Dave Airlie: > On 30 June 2015 at 09:36, Roland Scheidegger wrote: >> Am 29.06.2015 um 22:18 schrieb Dave Airlie: >>> On 30 June 2015 at 00:58, Roland Scheidegger wrote: >>>> Don't worry about the AoS stuff. Only meant to do

Re: [Mesa-dev] [PATCH] gallivm: add fp64 support. (v2)

chan_ptr); Actually I think it would be nicer to keep the ordinary float path out of this function (the name also implies storing doubles) and handle that one-liner in the caller(s). Might also make sense to actually get the chan_ptrs in this function itself, it sort of feels unnatural to pass 2 of them

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

Am 05.07.2015 um 15:47 schrieb Ilia Mirkin: > On Sun, Jul 5, 2015 at 9:25 AM, Marek Olšák wrote: >> From: Marek Olšák >> >> Other approaches are being considered: >> >> 1) Don't use resource wrappers (views) and pass all view parameters >>(format, layer range, level) to set_shader_images just

Re: [Mesa-dev] Fwd: GPU-CPU sync during radeonQueryGetResult

Am 06.07.2015 um 19:54 schrieb Ilia Mirkin: > That's right. Except really what might have happend was > > occl query; > write X; > more drawing; > write X+1; > > and then on the CPU, you see X+1. So the tests are always for >= X. > And if you have more than 2^32 submits, you cry, because I'm *sur

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 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. >>> >>> But ove

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 > > I'm not sure if we shouldn't enable this everywhere > and rip out the API checks, > > discuss, > > Signed-off-by: Dave Airlie > --- > src/mesa/state_tracker/st_exte

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

tions... Reviewed-by: Roland Scheidegger 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 > --- > src/mesa/drivers/dri/r200/r200_context.c

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. >> >> Signe

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 im

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

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 > wrote: >> Am 10.07.2015 um 19:41 schrieb Emil Velikov: >>> On 10 July 2015 at 13:18, Roland Scheidegger wrote: >>>> Am 10.07.2015 um 05:44 schrieb Michel Dänzer

Re: [Mesa-dev] Disagreement between ChooseTextureFormat and QuerySamplesForFormat

Am 12.07.2015 um 19:30 schrieb Ilia Mirkin: > I asked this on IRC, but figured I'd get wider distribution for the > question. The situation is that nv50 doesn't support RGBA32 MS8 > textures. However QuerySamplesForFormat will try its hardest to find > supported sample counts, which means it'll go

Re: [Mesa-dev] [PATCH 03/13] gallium/auxiliary: Use exp2(x) instead of pow(2.0, x).

Did you replace 2 of them by exp2f but one by exp2f on purpose? I don't think we can use exp2/exp2f in gallium. This requires msvc 2013 (all of exp2, exp2f, powf are c99, powf is supported by older msvc but the others are not). I guess though could throw some wrappers into c99_math.h. Roland Am

Re: [Mesa-dev] [PATCH 06/13] gallium/auxiliary: Avoid double promotion.

gallium is already using fabsf in lots of other places. Supported by older msvc versions. Roland Am 14.07.2015 um 11:50 schrieb Iago Toral: > This one will need wrapping for fabsf. > > Reviewed-by: Iago Toral Quiroga > > On Mon, 2015-07-13 at 16:22 -0700, Matt Turner wrote: >> --- >> src/gall

Re: [Mesa-dev] [PATCH 03/13] gallium/auxiliary: Use exp2(x) instead of pow(2.0, x).

Am 14.07.2015 um 04:03 schrieb Matt Turner: > On Mon, Jul 13, 2015 at 5:13 PM, Roland Scheidegger > wrote: >> Did you replace 2 of them by exp2f but one by exp2f on purpose? > > Yes, two of them are converting their results to floats so they were > converted to exp2f().

Re: [Mesa-dev] [PATCH 03/13] gallium/auxiliary: Use exp2(x) instead of pow(2.0, x).

Am 15.07.2015 um 21:44 schrieb Matt Turner: > On Mon, Jul 13, 2015 at 5:13 PM, Roland Scheidegger > wrote: >> Did you replace 2 of them by exp2f but one by exp2f on purpose? >> >> I don't think we can use exp2/exp2f in gallium. This requires msvc 2013 >> (all

Re: [Mesa-dev] [PATCH 03/13] gallium/auxiliary: Use exp2(x) instead of pow(2.0, x).

Am 15.07.2015 um 21:58 schrieb Matt Turner: > On Wed, Jul 15, 2015 at 12:44 PM, Matt Turner wrote: >> On Mon, Jul 13, 2015 at 5:13 PM, Roland Scheidegger >> wrote: >>> Did you replace 2 of them by exp2f but one by exp2f on purpose? >>> >>> I don'

Re: [Mesa-dev] [PATCH 3/4] radeon: fix some potential big endian issues

Am 13.07.2015 um 17:58 schrieb Emil Velikov: > On 11 July 2015 at 19:39, wrote: > >> @@ -186,17 +172,24 @@ static inline void emit_cb_setup(struct r100_context >> *r100, >> >> /* XXX others? BE/LE? */ > Drop the BE/LE part of the comment ? > >> switch (mesa_format) { >> +/* le *

Re: [Mesa-dev] [PATCH 11/14] mesa: add API dispatch for GL_ARB_get_texture_sub_image

Am 16.07.2015 um 02:18 schrieb Ilia Mirkin: > On Wed, Jul 15, 2015 at 7:40 PM, Brian Paul wrote: >> This adds the new glGetTextureSubImage() and >> glGetCompressedTextureSubImage() functions. Also update the >> dispatch sanity test program. >> >> v2: remove stray brace, move xi:include line in gl

Re: [Mesa-dev] [PATCH] mesa: fix up some texture error checks

Am 17.07.2015 um 16:18 schrieb Brian Paul: > On 07/16/2015 03:15 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> In particular, we were incorrectly accepting s3tc (and lots of others) >> for CompressedTexSubImage3D (but not CompressedTexImage3D) calls

Re: [Mesa-dev] [PATCH] mesa: fix up some texture error checks

Am 17.07.2015 um 16:18 schrieb Brian Paul: > On 07/16/2015 03:15 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> In particular, we were incorrectly accepting s3tc (and lots of others) >> for CompressedTexSubImage3D (but not CompressedTexImage3D) calls

Re: [Mesa-dev] [PATCH 3/3] gallivm: Initialize LLVM Modules's DataLayout to an empty string.

solution. The correct solution will require > creating a TargetMachine during gallivm initialization and pulling the > DataLayout from there. This will be a somewhat invasive change, and it > will need to be validatated on multiple LLVM versions. Reviewed-by: Roland Scheidegger > -

Re: [Mesa-dev] ARB_copy_image support in Gallium

Theoretically resource_copy_region should be the right function for that. Both ARB_copy_image and d3d10 ResourceCopyRegion define this as essentially the equivalent of memcpy. I guess the difficulty is that GL's view classes are a bit different compared to d3d10 typeless groups - d3d10 doesn't allo

Re: [Mesa-dev] ARB_copy_image support in Gallium

Am 20.07.2015 um 22:46 schrieb Ilia Mirkin: > On Mon, Jul 20, 2015 at 3:53 PM, Brian Paul wrote: >> On 07/20/2015 01:19 PM, Ilia Mirkin wrote: >> >>> On Mon, Jul 20, 2015 at 2:44 PM, Ilia Mirkin wrote: Hi Brian, You marked off ARB_copy_image (and ARB_clear_texture) as in-progr

Re: [Mesa-dev] ARB_copy_image support in Gallium

Am 21.07.2015 um 02:10 schrieb Ilia Mirkin: > On Mon, Jul 20, 2015 at 7:53 PM, Roland Scheidegger > wrote: >> Am 20.07.2015 um 22:46 schrieb Ilia Mirkin: >>> On Mon, Jul 20, 2015 at 3:53 PM, Brian Paul wrote: >>>> On 07/20/2015 01:19 PM, Ilia Mirkin wrote: >

Re: [Mesa-dev] ARB_copy_image support in Gallium

ortant and either would work in a lot of cases. Drivers > that prefer resource_copy_region over blit should use > util_try_blit_via_copy_region in their blit implementation. The only > case where resource_copy_region must be used is copying compressed > textures. > > Marek > > > On Mon, J

Re: [Mesa-dev] [PATCH] mesa: allow GL_TEXTURE_CUBE_MAP_ARRAY case for glCompressedTexSubImage3D()

Could mention this is actually a gl spec bug in the commit message, but either way: Reviewed-by: Roland Scheidegger Am 21.07.2015 um 22:55 schrieb Brian Paul: > Since s3tc works for cube maps and 2D arrays, it should also work for > cube arrays. NVIDIA's driver supports this too.

Re: [Mesa-dev] [PATCH 3/3] mesa: do more thorough target checking in compressed_subtexture_target_check()

not > + * mentioned by core spec. > + */ > switch (format) { > /* These are the only 3D compression formats supported at this time > */ > case GL_COMPRESSED_RGBA_BPTC_UNORM: > @@ -4610,6 +4622,9 @@ compressed_subtexture_target_c

Re: [Mesa-dev] Using the right context in st_texture_release_all_sampler_views()

Well they are not sharable by definition (per-context entities), it is not meant to work. So, it definitely should be fixed one way or another. Roland Am 23.07.2015 um 17:44 schrieb Marek Olšák: > Hi Brian, > > Like the commit message says, I have no idea how Firefox does it. My > commit only ch

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 insertions(+) > > diff --git a/s

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 version

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

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

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 > 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 fine to me. >> But

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

Reviewed-by: Roland Scheidegger Am 12.10.2015 um 07:55 schrieb Dave Airlie: > From: Dave Airlie > > This fixes the fetching of fp64 inputs to the geometry shader, > > this fixes the recently posted piglit's > arb_gpu_shader_fp64/execution/gs-fs-vs-d

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: >> +/** >> + * Convert a 2-byte half float to a 4-byte float. >> + *

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] 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] [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 wrote: >>> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark wrote: >>>> On Mon, Oct 12, 2015 at 12:47 A

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 >> ma

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

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 > 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] [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 > wrote: >> Am 12.10.2015 um 22:37 schrieb Rob Clark: >>> On Mon, Oct 12, 2015 at 3:41 PM, Roland Scheidegger >>> wrote: >>>> Am 12.10.2015 um 20:33 schrie

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

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. > --- > src/mesa/state_tracker/st_cb_

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 >> >> The previous ver

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, bu

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] 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: R

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

Reviewed-by: Roland Scheidegger 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 to that effect, but > le

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), bu

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), bu

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 the right list..) > > Sti

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] [PATCH 2/4] gallium: add new properties for clip and cull distance usage

ader to tell how many clip > distances are used. > > On Mon, Oct 19, 2015 at 5:02 PM, Roland Scheidegger > 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 >>

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 > 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 >> just using t

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 > wrote: >> Am 19.10.2015 um 23:44 schrieb Marek Olšák: >>> On Mon, Oct 19, 2015 at 11:31 PM, Roland Scheidegger >>> wrote: >>>> Yes, but I sti

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 > 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 >> just using t

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 > wrote: >> Am 19.10.2015 um 23:44 schrieb Marek Olšák: >>> On Mon, Oct 19, 2015 at 11:31 PM, Roland Scheidegger >>> wrote: >>>> Yes, but I sti

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 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 each > section was be

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] gallivm: Translate all util_cpu_caps bits to LLVM attributes.

Thanks for fixing this up. Reviewed-by: Roland Scheidegger Am 21.10.2015 um 18:25 schrieb Jose Fonseca: > This should prevent disparity between features Mesa and LLVM > believe are supported by the CPU. > > http://lists.freedesktop.org/archives/mesa-dev/2015-October/threa

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

Am 22.10.2015 um 00:41 schrieb Rowley, Timothy O: > >> On Oct 20, 2015, at 2:03 PM, Roland Scheidegger wrote: >> >> Certainly looks interesting... >> From a high level point of view, seems quite similar to llvmpipe (both >> tile based, using llvm for jitting

Re: [Mesa-dev] [PATCH 4/4] st/mesa: use _mesa_RasterPos() when possible

Ahhh legacy functionality from hell... For the series: Reviewed-by: Roland Scheidegger I'm wondering if it would be possible to omit the rasterPos execution completely, by incorporating it into drawPixels etc. at least in the hopefully common case there's no state changes affecting t

Re: [Mesa-dev] [PATCH] gallivm: Translate all util_cpu_caps bits to LLVM attributes.

Oh and it probably should go to stable. Roland Am 21.10.2015 um 18:55 schrieb Roland Scheidegger: > Thanks for fixing this up. > > Reviewed-by: Roland Scheidegger > > Am 21.10.2015 um 18:25 schrieb Jose Fonseca: >> This should prevent disparity between features Mesa an

Re: [Mesa-dev] [PATCH] radeon/uvd: don't expose HEVC on old UVD hw

Am 22.10.2015 um 18:27 schrieb Alex Deucher: > The section for UVD 2 and older was not updated > when HEVC support was added. Reported by Kano > on irc. > > Signed-off-by: Alex Deucher > Cc: mesa-sta...@lists.freedesktop.org > --- > src/gallium/drivers/radeon/radeon_video.c | 3 ++- > 1 file cha

Re: [Mesa-dev] [PATCH] gallivm: disable f16c when not using AVX

Am 26.10.2015 um 10:02 schrieb Jose Fonseca: > On 23/10/15 22:26, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> f16c intrinsic can only be emitted when AVX is used. So when we >> disable AVX >> due to forcing 128bit vectors we must not use this i

Re: [Mesa-dev] [PATCH] gallivm: disable f16c when not using AVX

Am 26.10.2015 um 16:33 schrieb Jose Fonseca: > On 26/10/15 14:58, Roland Scheidegger wrote: >> Am 26.10.2015 um 10:02 schrieb Jose Fonseca: >>> On 23/10/15 22:26, srol...@vmware.com wrote: >>>> From: Roland Scheidegger >>>> >>>> f16c intr

Re: [Mesa-dev] [PATCH v6 2/2] mesa/teximage: accept ASTC formats for 3D texture specification

Am 26.10.2015 um 19:31 schrieb Ilia Mirkin: > On Mon, Oct 26, 2015 at 2:15 PM, Neil Roberts wrote: >> Nanley Chery writes: >> >>> + /* Throw an INVALID_OPERATION error if the target is >>> + * TEXTURE_CUBE_MAP_ARRAY and the format is not ASTC. >>> + */ >>> + if (target_can_b

Re: [Mesa-dev] [PATCH] mesa/teximage: Fix ASTC-caused S3TC regression

Am 28.10.2015 um 20:48 schrieb Ian Romanick: > On 10/28/2015 09:52 AM, Nanley Chery wrote: >> From: Nanley Chery >> >> The ASTC spec forbids other compressed formats from being used against >> the targets: TEXTURE_CUBE_MAP_ARRAY and TEXTURE_3D. Because other > > I apologize for not paying very mu

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

Am 29.10.2015 um 12:27 schrieb Oded Gabbay: > Hi Roland, Jose > > I wanted to bring a problem I found to your attention, and discuss > about it and ways to solve it. > > I'm working on regressions of piglit gpu.py between x86-64 and > ppc64le, when running with llvmpipe. > > One of the regressio

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

Am 29.10.2015 um 20:10 schrieb Oded Gabbay: > On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin wrote: >> On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay wrote: >>> However, I would hate to keep the situation as is, meaning the test >>> passes on x86-64 and fails on ppc64le. >> >> Sounds like it'd actual

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

Am 29.10.2015 um 19:44 schrieb Oded Gabbay: > On Thu, Oct 29, 2015 at 5:31 PM, Roland Scheidegger > wrote: >> Am 29.10.2015 um 12:27 schrieb Oded Gabbay: >>> Hi Roland, Jose >>> >>> I wanted to bring a problem I found to your attention, and discuss >>

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

Am 29.10.2015 um 20:33 schrieb Oded Gabbay: > On Thu, Oct 29, 2015 at 9:25 PM, Roland Scheidegger > wrote: >> Am 29.10.2015 um 20:10 schrieb Oded Gabbay: >>> On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin wrote: >>>> On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay w

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 > wrote: >> Am 29.10.2015 um 19:44 schrieb Oded Gabbay: >>> On Thu, Oct 29, 2015 at 5:31 PM, Roland Scheidegger >>> wrote: >>>> Am 29.10.2015 um 12:27

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 freque

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] 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 > constant

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

that > in TGSI. I could invent stuff for all of these situations, but it > 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, Rolan

  1   2   3   4   5   6   7   8   9   10   >