Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions

Am 21.09.2018 um 14:55 schrieb Ian Romanick: > On 09/21/2018 05:36 AM, Federico Dossena wrote: >> Do you know of other applications that are affected by the order or >> extensions? This is the first time I encounter this problem. > > Just the idTech2 and idTech3 games. One thing I think we can

Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions

Am 20.09.2018 um 16:10 schrieb Ian Romanick: > On 09/20/2018 07:04 AM, Roland Scheidegger wrote: >> Am 20.09.2018 um 15:09 schrieb Ian Romanick: >>> On 09/19/2018 11:36 PM, Federico Dossena wrote: >>>> As most of you are probably aware of, id2 and id3 games store

Re: [Mesa-dev] [PATCH] utils/u_math: break dependency on gallium/utils

Looks like this broke the windows build, however. Roland Am 09.09.2018 um 08:39 schrieb Dylan Baker: > Currently u_math needs gallium utils for cpu detection. Most of what > u_math uses out of u_cpu_detection is duplicated in src/mesa/x86 > (surprise!), so I've just reworked it as much as

Re: [Mesa-dev] Request to revert commit [3d81e11b49366b5636b8524ba0f8c7076e3fdf34] mesa: remove, unnecessary, 'sort by year' for the GL extensions

Am 20.09.2018 um 15:09 schrieb Ian Romanick: > On 09/19/2018 11:36 PM, Federico Dossena wrote: >> As most of you are probably aware of, id2 and id3 games store GL >> extensions in a buffer that's too small for modern systems. This usually >> leads to a crash when MESA_EXTENSION_MAX_YEAR is not

Re: [Mesa-dev] Bug introduced with Mesa 18.0.0: Star Trek Voyager Elite Force shadow glitches

ames that might suffer from this? The sorting was removed because it was deemed not to really be the right solution and not helping, so if that isn't true I suppose technically it could be reverted. I don't work in that area though... Roland > > > On 2018-09-18 22:13, Roland Scheidegger wrot

Re: [Mesa-dev] Bug introduced with Mesa 18.0.0: Star Trek Voyager Elite Force shadow glitches

pps by mesa by the looks of it. Roland > > > On 2018-09-18 18:37, Roland Scheidegger wrote: >> Am 18.09.2018 um 18:14 schrieb Federico Dossena: >>> Upon further investigation, renaming the game to quake3.exe somehow >>> forces it to load the system opengl32.dll inste

Re: [Mesa-dev] Bug introduced with Mesa 18.0.0: Star Trek Voyager Elite Force shadow glitches

se if you could do a git bisect that would help, a trace would be nice if someone has time to look into it (but I won't have, while I try to look into llvmpipe bugs that doesn't really extend to things which are likely app issues). Roland > > > On 2018-09-18 16:55, Roland Scheidegger wrote:

Re: [Mesa-dev] Bug introduced with Mesa 18.0.0: Star Trek Voyager Elite Force shadow glitches

I don't see any shadows at all with the 17.3.7 video? Whereas the 18.0.0 one look quite bogus to me, but I think shadows are known to be glitchy with id tech 3? It should be possible to tweak shadows via cg_shadow (0-3), r_stencilbits 8 might be necessary for some modes, r_dynamiclights 0 might

Re: [Mesa-dev] [PATCH] r600/sb: use safe math optimizatiosn when TGSI contains precise operations

I suppose ideally it would only affect instruction chains which have a precise modifier somewhere. But it's better than just ignoring it completely. Reviewed-by: Roland Scheidegger Am 14.09.2018 um 16:56 schrieb Gert Wollny: > Fixes: > dEQP

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

Am 12.09.2018 um 23:43 schrieb Roland Scheidegger: > Am 12.09.2018 um 08:31 schrieb Axel Davy: >> On 9/12/18 8:17 AM, Axel Davy wrote: >>> >>> The goal is to catch inf and -inf and replace them by FLT_MAX and >>> -FLT_MAX. >>> >>> Without, the

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

Am 12.09.2018 um 08:31 schrieb Axel Davy: > On 9/12/18 8:17 AM, Axel Davy wrote: >> >> The goal is to catch inf and -inf and replace them by FLT_MAX and >> -FLT_MAX. >> >> Without, the NaN would appear when doing mul or mad. Ah I somehow completely missed this (but indeed this code will replace

Re: [Mesa-dev] [PATCH 1/5] st/nine: Clamp RCP when 0*inf!=0

Am 09.09.2018 um 21:19 schrieb Axel Davy: > Tests done on several devices of all 3 vendors and > of different generations showed that there are several > ways of handling infs and NaN for d3d9. > > Tests showed Intel on windows does always clamp > RCP, RSQ and LOG (thus preventing inf/nan

Re: [Mesa-dev] [PATCH] Require Visual Studio 2015.

Looks good to me. Reviewed-by: Roland Scheidegger Am 07.09.2018 um 17:59 schrieb Jose Fonseca: > We no longer need or use Visual Studio 2013. > > https://ci.appveyor.com/project/jrfonseca/mesa/build/52 > --- > docs/install.html | 2 +- > include/c11/th

Re: [Mesa-dev] [PATCH 0/8] Gallium & RadeonSI optimization for Ryzen CPUs

Am 06.09.2018 um 22:56 schrieb Axel Davy: > Yeah by pinning to cores, I meant to group of cores. > > I think a reasonable policy would be for the kernel to put all threads > of a given process on the same L3 > as long as the number of threads is lower than the L3 group size. > When there is more

Re: [Mesa-dev] [PATCH 1/2] gallium: New cap PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET.

for stride, at least natively... Might even be common that hw uses the same field width for stride as well as offsets... In any case, Reviewed-by: Roland Scheidegger Am 06.09.2018 um 16:31 schrieb mathias.froehl...@gmx.net: > From: Mathias Fröhlich > > Introduce a new capability for th

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

Looks great to me. Thanks! Reviewed-by: Roland Scheidegger Am 06.09.2018 um 06:10 schrieb Marek Olšák: > From: Marek Olšák > > --- > src/gallium/auxiliary/util/u_screen.c | 3 +++ > src/gallium/docs/source/screen.rst | 2 ++ > src/gallium/drivers/r600/r600_pipe.c |

Re: [Mesa-dev] [PATCH] gallium: Set the default GL_SUBPIXEL_BITS to 4.

I really think it makes no sense to hack some more around this. GLES (even 3.2) doesn't even support non-integer viewports. As I mentioned before, it's incorrect to report more than 0 bits for viewport subpixels if a driver only supports integer viewports. To fix this for real really 2 caps would

Re: [Mesa-dev] [PATCH] gallivm: Detect VSX separately from Altivec

0/2018 02:44 PM, Roland Scheidegger wrote: >> Alright, I guess it's ok then. >> In theory the u_cpu_detect bits could be used in different places, for >> instance the translate code emits its own sse code, and as long as a >> feature was detected properly it may make sense to di

Re: [Mesa-dev] [PATCH] gallium: fix drivers to report something for PIPE_CAP_VIEWPORT_SUBPIXEL_BITS

This is not correct. The problem here is that there's only a viewport subpixel accuracy query, but the state tracker uses this to both set subpixel (which is raterization subpixel accuracy) as well as viewport subpixel bits. The former needs to be at least 4 (dx10 requires 8), whereas the latter

Re: [Mesa-dev] [PATCH] gallivm: don't use saturated unsigned add/sub intrinsics for llvm 8.0

Am 23.08.2018 um 22:13 schrieb Jose Fonseca: > On 23/08/18 18:53, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> These have been removed. Unfortunately auto-upgrade doesn't work for >> jit. (Worse, it seems we don't get a compilation error anymore when >

Re: [Mesa-dev] [PATCH] llvmpipe: add cc clobber to inline asm

but with -O3 -march=haswell it's a bit suboptimal now: mov$0x1,%edx lzcnt %eax,%eax xor$0x1f,%eax shlx %eax,%edx,%eax So optimization is quite funny here, depending on if the cpu can do lzcnt or just bsr. Fun stuff... In any case, Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: Detect VSX separately from Altivec

as others. Reviewed-by: Roland Scheidegger Am 20.08.2018 um 22:15 schrieb Vicki Pfau: > I was mostly following what was done earlier in the file for Altivec. I > can move it but then ideally the Alitvec check should also be moved. > > > Vicki > > > On 08/20/2018 08:53 AM,

Re: [Mesa-dev] [PATCH] appveyor: Set git core.autocrlf setting to true.

Looks good to me. Reviewed-by: Roland Scheidegger Am 20.08.2018 um 13:21 schrieb Jose Fonseca: > The git core.autocrlf setting defaults to true (ie, all text files get > checked out as CRLF on Windows), except on Appveyor where's set to > "input" (ie, all text fi

Re: [Mesa-dev] [PATCH] gallivm: Detect VSX separately from Altivec

u_cpu_detect should detect what's really available, not what is used (though indeed we actually disable u_cpu bits explicitly in gallivm for some sse features, but this is a hack). So I think it would be better if u_cpu_detect sets the has_vsx bit regardless what the env var is and then enable it

Re: [Mesa-dev] [PATCH 09/22] nir/format_convert: Rename pack_r11g11b10f to pack_11f11f10f

Am 17.08.2018 um 22:06 schrieb Jason Ekstrand: > This matches the unpack function. > --- > src/compiler/nir/nir_format_convert.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/compiler/nir/nir_format_convert.h > b/src/compiler/nir/nir_format_convert.h > index

Re: [Mesa-dev] [PATCH 09/21] mesa: remove legacy TCL dri config options

Am 15.08.2018 um 20:47 schrieb Ian Romanick: > On 08/15/2018 04:09 AM, Timothy Arceri wrote: >> On 15/08/18 20:26, Michel Dänzer wrote: >>> On 2018-08-15 12:13 PM, Timothy Arceri wrote: Use enviroment var overrides in legacy drivers instead. >>> >>> This could break existing user

Re: [Mesa-dev] [PATCH] mesa/glspirv: fix compilation with MSVC

Am 13.08.2018 um 16:50 schrieb Alejandro Piñeiro: > From AppVeyor #8582, it seems that MSVC doesn't like uint, so this > patch replaces it with unsigned. Reviewed-by: Roland Scheidegger > --- > > Note that Im not sure if this is the usual solution. As far as I see, > uin

Re: [Mesa-dev] [PATCH v3] Gallium/tgsi: Correct signdness of return value of bit operations

Reviewed-by: Roland Scheidegger Am 10.08.2018 um 15:04 schrieb Gert Wollny: > From: Gert Wollny > > The GLSL operations findLSB, findMSB, and countBits always return > a signed integer type. Let TGSI reflect this. > > v2: Properly set values in infer_(src|dst)_typ

Re: [Mesa-dev] [PATCH v2] Gallium/tgsi: Correct signedness of return value of bit operations

Am 09.08.2018 um 19:28 schrieb Gert Wollny: > From: Gert Wollny > > The GLSL operations findLSB, findMSB, and countBits always return > a signed integer type. Let TGSI reflect this. > > v2: Properly set values in infer_(src|dst)_type (Thanks Roland > Schneideregger for pointing out

Re: [Mesa-dev] [PATCH] Gallium/tgsi: Correct signdness of return value of bit operations

Am 09.08.2018 um 19:09 schrieb Gert Wollny: > Am Donnerstag, den 09.08.2018, 18:52 +0200 schrieb Roland Scheidegger: >> Am 09.08.2018 um 18:18 schrieb Gert Wollny: >>> Am Donnerstag, den 09.08.2018, 17:10 +0200 schrieb Roland >>> Scheidegger: >>>> This is inc

Re: [Mesa-dev] [PATCH] Gallium/tgsi: Correct signdness of return value of bit operations

Am 09.08.2018 um 18:18 schrieb Gert Wollny: > Am Donnerstag, den 09.08.2018, 17:10 +0200 schrieb Roland Scheidegger: >> This is incorrect for umsb. > Hmm, according to the TGSI doc all of those operations including UMSB > are supposed to return -1 if no bits are set [1], for

Re: [Mesa-dev] [PATCH 14/14] radeonsi: increase the maximum UBO size to 2 GB

Am 09.08.2018 um 17:57 schrieb Marek Olšák: > On Thu, Aug 9, 2018 at 1:35 AM, Roland Scheidegger wrote: >> I'm not quite convinced you can really use huge ubos safely? At least >> direct addressing in tgsi can't work (you've only got a 16bit register >> index, and it's signe

Re: [Mesa-dev] [PATCH] Gallium/tgsi: Correct signdness of return value of bit operations

This is incorrect for umsb. If you really want to move so the dst type is signed, you need to add it to infer_src_type so the src args are unsigned. FWIW I'd like to think that all 3 of these always operate on unsigned data (even if they might return signed data), imho they are a lot more easier

Re: [Mesa-dev] [PATCH 14/14] radeonsi: increase the maximum UBO size to 2 GB

I'm not quite convinced you can really use huge ubos safely? At least direct addressing in tgsi can't work (you've only got a 16bit register index, and it's signed too). Roland Am 09.08.2018 um 01:55 schrieb Marek Olšák: > From: Marek Olšák > > Same as the closed driver. > > This causes a

Re: [Mesa-dev] [PATCH 10/14] tgsi/ureg: don't call tgsi_sanity when it's too slow

Am 09.08.2018 um 01:55 schrieb Marek Olšák: > From: Marek Olšák > > --- > src/gallium/auxiliary/tgsi/tgsi_ureg.c | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c > b/src/gallium/auxiliary/tgsi/tgsi_ureg.c > index

Re: [Mesa-dev] [PATCH] [rfc] r600: set vpm bit for loop start clause

Am 05.08.2018 um 11:47 schrieb Gert Wollny: > Am Freitag, den 03.08.2018, 06:02 +0200 schrieb Roland Scheidegger: >> Am 03.08.2018 um 05:10 schrieb Dave Airlie: >>> From: Dave Airlie >>> >>> This fixes some hangs with the arb_shader_image_load_store- >>

Re: [Mesa-dev] [PATCH] [rfc] r600: set vpm bit for loop start clause

Am 03.08.2018 um 07:00 schrieb Dave Airlie: > On 3 August 2018 at 14:02, Roland Scheidegger wrote: >> Am 03.08.2018 um 05:10 schrieb Dave Airlie: >>> From: Dave Airlie >>> >>> This fixes some hangs with the arb_shader_image_load_store-atomicity tests >&

Re: [Mesa-dev] [PATCH] [rfc] r600: set vpm bit for loop start clause

Am 03.08.2018 um 05:10 schrieb Dave Airlie: > From: Dave Airlie > > This fixes some hangs with the arb_shader_image_load_store-atomicity tests > on evergreen/cayman GPUs. > > I'm not 100% sure why (VPM hurts my brain), I'm running some piglit > runs to see if it has any bad side effects. > ---

Re: [Mesa-dev] [PATCH] util: don't use __builtin_clz unconditionally

n = 15 - i; > + break; > + } > + } > +#endif Not sure why you're not just using util_last_bit (I think it's best to keep such bit scan hackery in separate util files), but whatever fixes the compile error, so Reviewed-by: Roland Scheidegger > > /* Shift t

Re: [Mesa-dev] [PATCH 1/7] mesa: add ASTC 2D LDR decoder

Am 24.07.2018 um 01:52 schrieb Marek Olšák: > From: Marek Olšák > > +uint16_t _mesa_uint16_div_64k_to_half(uint16_t v) > +{ > + /* Zero or subnormal. Set the mantissa to (v << 8) and return. */ > + if (v < 4) > + return v << 8; > + > + /* Count the leading 0s in the uint16_t */ > +

Re: [Mesa-dev] [PATCH] r600: Scale integer valued texture border colors to float (v2)

_S8X24_UINT: whitespace. Looks alright to me (though as mentioned, I consider trying to fix up border color a futile attempt on eg :-)). btw I suppose it would apply to pre-eg chips as well? Not that I'd suggest you fix it up there too ;-). Reviewed-by: Roland Scheidegger > +

Re: [Mesa-dev] [PATCH] gallium/tests: Don't ignore S3TC errors.

_unpacked_rgba_8unorm(format_desc, "FAILED: ", unpacked, " > obtained\n"); >print_unpacked_rgba_8unorm(format_desc, "", expected, " > expected\n"); > Looks good to me. Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: surface remove width/height removal comment

Am 18.07.2018 um 19:29 schrieb Marek Olšák: > On Tue, Jul 17, 2018 at 9:44 AM, Roland Scheidegger > wrote: >> Initially, width/height were actually needed because not all >> pipe_surface objects were backed by pipe_resource objects (that was ages >> ago...). Hence the com

Re: [Mesa-dev] [PATCH v5 3/3] r600: Correct evaluation of cube array index and face

r = r600_bytecode_add_alu(ctx->bc, ); > + if (r) > + return r; > + Kind of lame that we have to do shader workarounds for a corner case (who in their right mind relies on negative array indices gettin

Re: [Mesa-dev] [PATCH] gallium: surface remove width/height removal comment

Initially, width/height were actually needed because not all pipe_surface objects were backed by pipe_resource objects (that was ages ago...). Hence the comment when that was fixed, since it was always actually possible to derive this from the resource (but a bit too complex to change all the

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

Am 13.07.2018 um 23:07 schrieb AppVeyor: > > Build mesa 8296 failed > >

Re: [Mesa-dev] [PATCH 2/2] u_blitter: Add an option to draw the triangles using an index buffer.

Am 12.07.2018 um 00:05 schrieb Eric Anholt: > For V3D, the HW will interpolate slightly differently along the shared > edge of the trifan. The conformance tests manage to catch this in the > nearest_consistency_* group. To get interpolation to match, we need the > last vertex of the triangle to

Re: [Mesa-dev] [PATCH] r600: Add spill output to group only if register or target index changes

;bc->chip_class >= R700) > + r600_bytecode_need_wait_ack(ctx->bc, true); > } > - > - r = r600_bytecode_add_pending_output(ctx->bc, ); > - if (r) > - r

Re: [Mesa-dev] [PATCH] scons: Fix CC env quoting.

null', > stderr = 'devnull', > stdout = 'devnull') > Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] verify max vertex attrib stride

Am 09.07.2018 um 09:54 schrieb Erik Faye-Lund: > On 06. juli 2018 18:43, Roland Scheidegger wrote: >> Am 06.07.2018 um 12:03 schrieb Erik Faye-Lund: >>> OpenGL 4.4 and OpenGL ES 3.1 both require the maximum >>> vertex attrib stride to be at least 2048. If this isn't

Re: [Mesa-dev] [PATCH 0/3] verify max vertex attrib stride

Am 09.07.2018 um 11:51 schrieb Gert Wollny: > Am Montag, den 09.07.2018, 09:54 +0200 schrieb Erik Faye-Lund: >> On 06. juli 2018 18:43, Roland Scheidegger wrote: >>> >>> Personally I think it's _much_ better to lie about the supported GL >>> version rather than

Re: [Mesa-dev] [PATCH 0/3] verify max vertex attrib stride

Am 06.07.2018 um 12:03 schrieb Erik Faye-Lund: > OpenGL 4.4 and OpenGL ES 3.1 both require the maximum > vertex attrib stride to be at least 2048. If this isn't > the case, we shouldn't expose these API versions. > > Unfortunately, the r600 driver only supports 2047. To > avoid regressions in the

Re: [Mesa-dev] [PATCH] Util: fix msvc build

tion won't work with your OS > version." > +#pragma message ( "Warning: Per application configuration won't work > with your OS version." ) > #endif > #endif > Reviewed-by: Roland Scheidegger ___ mesa-d

Re: [Mesa-dev] [PATCH] r600: compare structure elements instead of doing a memcmp

there also might be multiple places where it needs to be initialized.) Reviewed-by: Roland Scheidegger Am 01.07.2018 um 10:37 schrieb Gert Wollny: > From: Gert Wollny > > Structures might be padded by the compiler and these padding bytes remain > un-initialized which in turn

Re: [Mesa-dev] [PATCH 1/1] mesa/st: draw_vbo: initialize restart_index too

Reviewed-by: Roland Scheidegger Am 01.07.2018 um 10:05 schrieb Gert Wollny: > From: Gert Wollny > > restart_index is later always used in a comparison, so it should be > initialized properly. > > Fixes valgrind warning: > Conditional jump or move depends on

Re: [Mesa-dev] [PATCH 3/3] r600: Scale interger valued texture border colors to float

Am 01.07.2018 um 19:32 schrieb Gert Wollny: > It seems the hardware always expects floating point border color values > [0,1] for unsigned, and [-1,1] for signed texture component, regardless > of pixel type, but the border colors are passed according to texture > component type. Hence, before

Re: [Mesa-dev] [PATCH 1/3] r600: force LOD range to be only one value when mip.min filter is NONE

erent? That is I'm wondering if this needs special values rather than just max_lod so the hw still selects the right min or mag filter (so, a range of [0, 1/256]) instead of setting min and max lod to the same (max_lod) value. But if this passes piglit, I supp

Re: [Mesa-dev] [PATCH v2 2/2] r600: set rounding mode for texture array layer selection

fset is done in the shader. > + * Also make sure that for other texture types the default is > used. You could also mention this alters all coordinates. So, I'm still really not fond of the idea, since there's no proof it causes any issues rather than venture i

Re: [Mesa-dev] [PATCH v2 1/2] r600: correct texture offset for array index lookup

orrection for GATHER*O (corrects piglit > failures reported by Dave Airlie) > - unconditionally set the texture offset to 1 (=0.5) because the shader > can't set an offset for the array index (Roland Scheidegger) > - Add Fixes comment to commit message > > Sign

Re: [Mesa-dev] [PATCH 0/2] r600: Fix array texture slice index evaluation

Am 26.06.2018 um 09:59 schrieb Gert Wollny: > Am Montag, den 25.06.2018, 23:47 +0200 schrieb Roland Scheidegger: >> >> Alright albeit you have logic to handle incoming z offsets, whereas >> that should always be 0. > I'm preparing for future standards that a

Re: [Mesa-dev] [PATCH 0/2] r600: Fix array texture slice index evaluation

Am 25.06.2018 um 22:13 schrieb Gert Wollny: > Am Montag, den 25.06.2018, 17:36 +0200 schrieb Roland Scheidegger: >> I didn't actually get the original email for some reason, so can't >> comment inline as I'm just looking it up at patchwork... >> But the array offset stuff (t

Re: [Mesa-dev] [PATCH 0/2] r600: Fix array texture slice index evaluation

I didn't actually get the original email for some reason, so can't comment inline as I'm just looking it up at patchwork... But the array offset stuff (the first patch) looks completely bogus to me, array textures do not support offsets for the array index, at least not in any shader language I

Re: [Mesa-dev] [PATCH] i965: Advertise 8 bits subpixel precision for viewport bounds on gen6+

My guess would be 8 because that's what the rasterization subpixel precision is, so precision beyond that doesn't really do much, even if this actually is a float. Plus, with maximum sized fb (16kx16k dimension) you don't actually really get a lot more than 8 fixed points bits anyway (near those

Re: [Mesa-dev] [PATCH] r600: fix copy/paste bug for sampleMaskIn workaround

Am 18.06.2018 um 12:43 schrieb Eric Engestrom: > On Friday, 2018-06-15 23:38:58 +0200, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> The sampleMaskIn workaround (b936f4d1ca0d2ab1e828ff6a6e617f12469687fa) >> tries to figure out if the shader is runn

Re: [Mesa-dev] [PATCH] appveyor: Consume LLVM 5.0.1.

Reviewed-by: Roland Scheidegger Am 16.06.2018 um 11:12 schrieb Jose Fonseca: > https://ci.appveyor.com/project/jrfonseca/mesa/build/47 > --- > appveyor.yml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/appveyor.yml b/appveyor.yml > index bd3

Re: [Mesa-dev] [PATCH 2/2] nir: add lowering for gl_HelperInvocation

Am 12.06.2018 um 01:17 schrieb Rob Clark: > On Mon, Jun 11, 2018 at 6:59 PM, Roland Scheidegger > wrote: >> Am 12.06.2018 um 00:32 schrieb Jason Ekstrand: >>> On Wed, Jun 6, 2018 at 7:43 AM, Rob Clark >> <mailto:robdcl...@gmail.com>> wrote:

Re: [Mesa-dev] [PATCH 2/2] nir: add lowering for gl_HelperInvocation

Am 12.06.2018 um 00:32 schrieb Jason Ekstrand: > On Wed, Jun 6, 2018 at 7:43 AM, Rob Clark > wrote: > > Signed-off-by: Rob Clark > > --- > I can't say for sure that this will work on all drivers, but it is > what the

Re: [Mesa-dev] [PATCH 1/2] gallium: add scalar isa cap

Should probably fill in all drivers... softpipe/llvmpipe are scalar, svga - well that would depend but likely scalar in the end too... Roland Am 07.06.2018 um 21:55 schrieb Ilia Mirkin: > On Thu, Jun 7, 2018 at 3:32 PM, Christian Gmeiner > wrote: >> diff --git

Re: [Mesa-dev] [PATCH] trace: Fix trace_context_transfer_unmap methods.

. Reviewed-by: Roland Scheidegger Am 04.06.2018 um 15:01 schrieb Jose Fonseca: > The emitted buffer_subdata/texture_subdata call didn't match the > respective signatures. > > v2: Actually emit buffer_subdata call. > --- > .../auxiliary/driver_trace/tr_context.c | 60 +++

Re: [Mesa-dev] [PATCH 3/3] scons: Fix MinGW cross compilation with LLVM 5.0.

Looks good to me. Reviewed-by: Roland Scheidegger Am 01.06.2018 um 20:58 schrieb Jose Fonseca: > LLVM 5.0 requires additional Win32 libraries, and MinGW with pthreads. > --- > scons/llvm.py | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/sco

Re: [Mesa-dev] [PATCH 2/3] trace: Fix parsing of recent traces.

That code is really not my area of expertise... But I suppose makes sense (although I'm still really confused by the buffer_subdata issues)... Reviewed-by: Roland Scheidegger Am 01.06.2018 um 20:58 schrieb Jose Fonseca: > --- > src/gallium/tools/trace/dump_state.p

Re: [Mesa-dev] [PATCH 1/3] trace: Fix trace_context_transfer_unmap methods.

I am a bit confused by this, so by the looks of it you only dump things (unchanged) for textures, so did it match there? Also, I don't really understand why it doesn't work for buffers neither, even if some parameters don't make sense there, but if it's a transfer this should still be correct?

Re: [Mesa-dev] [PATCH] llvmpipe: improve rasterization discard logic

Am 22.05.2018 um 05:01 schrieb Brian Paul: > On 05/21/2018 07:34 PM, srol...@vmware.com wrote: >> From: Roland Scheidegger <srol...@vmware.com> >> >> This unifies the explicit rasterization dicard as well as the implicit > > "discard" Right. > >

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for advanced MSAA

I was under the (apparently wrong) impression EQAA always worked like that too. Even AMD's marketing said EQAA has the same number of stencil/depth/color samples as regular MSAA (when the feature was new, HD 6900,

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for advanced MSAA

This looks reasonable to me. Roland Am 18.05.2018 um 06:05 schrieb Marek Olšák: > From: Marek Olšák > > The interface only uses general MSAA terms, so it's "advanced MSAA" and not > something vendor-specific. > > It's a proper subset of EQAA, and a proper superset of

Re: [Mesa-dev] [PATCH] draw: get rid of special logic to not emit null tris

with UH, UV, glmark2, Blender 2.79, FreeCAD 0.17, Gimp 2.10, digikam > 5.9.0, Krita 4.0.3 and some Mesa-demos > > Dieter > > Am 17.05.2018 18:30, schrieb srol...@vmware.com: >> From: Roland Scheidegger <srol...@vmware.com> >> >> I've confirmed after 77554d220d6d74

Re: [Mesa-dev] [PATCH] tgsi: fix incorrect tgsi_shader_info::num_tokens computation

Oh yes, that looks quite wrong. Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 17.05.2018 um 22:06 schrieb Brian Paul: > We were incrementing num_tokens in each loop iteration while parsing > the shader. But each call to tgsi_parse_token() can consume more than > one t

Re: [Mesa-dev] [PATCH v2 1/2] radv: Fix up 2_10_10_10 alpha sign.

Slightly OT (not actually radv related), does someone know if this bug affects pre-gcn gpus and if so which ones? There's a bug filed against r600 (with Barts) which suspiciously looks like it's the exact same issue: https://bugs.freedesktop.org/show_bug.cgi?id=105095 But it works for me

Re: [Mesa-dev] [PATCH] r600: fix constant buffer bounds.

Am 10.05.2018 um 16:47 schrieb Ivan Kalvachev: > On 5/10/18, Roland Scheidegger <srol...@vmware.com> wrote: >> Quite a sneaky little bug, can't hurt to make undefined behavior a bit >> more defined :-). > > Actually, this behavior is completely defined in Direct3D,

Re: [Mesa-dev] [PATCH] r600: fix constant buffer bounds.

Quite a sneaky little bug, can't hurt to make undefined behavior a bit more defined :-). Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 10.05.2018 um 00:20 schrieb Dave Airlie: > From: Dave Airlie <airl...@redhat.com> > > If you have an indirect access to a const

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for EQAA

Am 01.05.2018 um 22:49 schrieb Marek Olšák: > On Tue, May 1, 2018 at 10:48 AM, Roland Scheidegger <srol...@vmware.com > <mailto:srol...@vmware.com>> wrote: > > Am 01.05.2018 um 01:43 schrieb Marek Olšák: > > From: Marek Olšák <marek.ol...@am

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for EQAA

Am 01.05.2018 um 17:18 schrieb Nicolai Hähnle: > On 01.05.2018 16:48, Roland Scheidegger wrote: >>> -**nr_samples** the nr of msaa samples. 0 (or 1) specifies a resource >>> -which isn't multisampled. >>> +**nr_samples**: For Z/S, this is the number of s

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for EQAA

Am 01.05.2018 um 16:51 schrieb Axel Davy: > Hi, > > On 01/05/2018 01:43, Marek Olšák wrote: >> From: Marek Olšák >> >> This is a hypothetical interface for EQAA (a superset of CSAA). CSAA >> could be >> exposed via GL_NV_framebuffer_multisample_coverage. EQAA additionally >>

Re: [Mesa-dev] [RFC PATCH] gallium: add interface for EQAA

Am 01.05.2018 um 01:43 schrieb Marek Olšák: > From: Marek Olšák > > This is a hypothetical interface for EQAA (a superset of CSAA). CSAA could be > exposed via GL_NV_framebuffer_multisample_coverage. EQAA additionally removes > the restriction that the number of samples in

Re: [Mesa-dev] [PATCH v3 00/13] TGSI: improved live range tracking, also including arrays

FWIW I'm not really qualified to review this, but this alleviates the concerns I had some time ago about doing spilling for r600 before sb. So this makes all sense to me. Roland Am 28.04.2018 um 21:30 schrieb Gert Wollny: > this is another update of the series I've sent before. > > v3: > -

Re: [Mesa-dev] [PATCH 09/10] gallium: add PIPE_CAP_TRANSFER_USER_STRIDE_ALIGNMENT

Am 25.04.2018 um 23:16 schrieb Marek Olšák: > From: Marek Olšák > > --- > src/gallium/docs/source/screen.rst | 3 +++ > src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 + > src/gallium/drivers/freedreno/freedreno_screen.c | 1 + >

Re: [Mesa-dev] [PATCH] llvmpipe : Fixed an issue where the display target texture was mapped multiple times.

Am 20.04.2018 um 08:07 schrieb 정성찬: > Dear Roland Scheidegger > > Thank you very much for your time and efforts. > > First, I want to talk about the problem that I encountered. > I am currently developing a display server system using the llvmpipe driver > and the kms-dri

Re: [Mesa-dev] [PATCH] llvmpipe : Fixed an issue where the display target texture was mapped multiple times.

Am 19.04.2018 um 08:04 schrieb Seongchan Jeong: > The lp_setup_set_fragment_sampler_views function can be called > when the texture module is enabled. However, mapping can be > performed several times for one display target texture, but > unmapping does not proceed. So some logic have been added

Re: [Mesa-dev] [PATCH] mesa: remove struct gl_extensions::ATI_separate_stencil

018 at 12:27 PM, Roland Scheidegger <srol...@vmware.com > <mailto:srol...@vmware.com>> wrote: > > Yes, there is indeed plenty hw (all with d3d heritage, d3d10 doesn't > support different ref/masks) which don't actually have full support for > two-sided sten

Re: [Mesa-dev] [PATCH] mesa: remove struct gl_extensions::ATI_separate_stencil

Yes, there is indeed plenty hw (all with d3d heritage, d3d10 doesn't support different ref/masks) which don't actually have full support for two-sided stencil. I think all drivers just cheat and fail though since they really want to expose GL 2 anyway. So I suppose that's ok, albeit I don't really

Re: [Mesa-dev] [PATCH] gallium: add CAP for postprocess filters

Am 04.04.2018 um 05:42 schrieb Timothy Arceri: > On 04/04/18 13:22, Roland Scheidegger wrote: >> Am 04.04.2018 um 05:03 schrieb Timothy Arceri: >>> On 04/04/18 12:44, Roland Scheidegger wrote: >>>> Am 04.04.2018 um 04:32 schrieb Timothy Arceri: >>>>>

Re: [Mesa-dev] [PATCH] gallium: add CAP for postprocess filters

Am 04.04.2018 um 05:03 schrieb Timothy Arceri: > On 04/04/18 12:44, Roland Scheidegger wrote: >> Am 04.04.2018 um 04:32 schrieb Timothy Arceri: >>> On 04/04/18 11:58, Roland Scheidegger wrote: >>>> AFAIK these filters (and I've never looked into them) should be

Re: [Mesa-dev] [PATCH] gallium: add CAP for postprocess filters

Am 04.04.2018 um 04:32 schrieb Timothy Arceri: > On 04/04/18 11:58, Roland Scheidegger wrote: >> AFAIK these filters (and I've never looked into them) should be >> transparent to hw drivers. Hence a cap bit doesn't make sense, and if >> it's broken we shouldn't just paper over

Re: [Mesa-dev] [PATCH] gallium: add CAP for postprocess filters

AFAIK these filters (and I've never looked into them) should be transparent to hw drivers. Hence a cap bit doesn't make sense, and if it's broken we shouldn't just paper over this. Roland Am 03.04.2018 um 13:38 schrieb Timothy Arceri: > For radeonsi these seem to have been somewhat broken for

Re: [Mesa-dev] [PATCH 02/11] gallium: Use _DrawVAO for edgeflag enabled check.

Not a review, but these aren't gallium changes, but rather state tracker ones, so should be st/mesa rather than gallium. (gallium would be changes to the gallium interface.) Roland Am 01.04.2018 um 20:13 schrieb mathias.froehl...@gmx.net: > From: Mathias Fröhlich > >

Re: [Mesa-dev] [PATCH] mesa: fix MSVC bitshift overflow warnings

efine BITFIELD_MASK(b) \ > - ((b) == 32 ? (~(GLbitfield)0) : BITFIELD_BIT(b) - 1) > + ((b) == 32 ? (~(GLbitfield)0) : BITFIELD_BIT((b) % 32) - 1) > /** Set count bits starting from bit b */ > #define BITFIELD_RANGE(b, count) \ > (BITFIELD_MASK((b) + (count)) &am

Re: [Mesa-dev] [PATCH] nir: s/uint/unsigned/ to fix MSVC/MinGW build

Looks good to me, though I wonder what broke it - must have been some include file reshuffling? Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 30.03.2018 um 06:02 schrieb Brian Paul: > --- > src/compiler/glsl/glsl_to_nir.cpp | 2 +- > src/compiler/nir/nir_gather_inf

Re: [Mesa-dev] [PATCH] nir: fix generated nir_intrinsics.c for MSVC

This looks alright to me, though I'm not sure why msvc seemingly didn't like the empty braces in the first place. Acked-by: Roland Scheidegger <srol...@vmware.com> Am 27.03.2018 um 20:59 schrieb Rob Clark: > Apparently it is not happy about things like: .foo = {} > > So skip ov

Re: [Mesa-dev] [PATCH] glsl: remove GCC construct from VECN macro

Am 27.03.2018 um 20:40 schrieb Emil Velikov: > On 27 March 2018 at 00:08, Roland Scheidegger <srol...@vmware.com> wrote: >> Am 27.03.2018 um 00:44 schrieb Rob Clark: >>> On Mon, Mar 26, 2018 at 6:38 PM, Rob Clark <robdcl...@gmail.com> wrote: >>>> On Mon, M

Re: [Mesa-dev] [PATCH] glsl_types: fix build break with intel/msvc compiler

Looks nicer in any case. Reviewed-by: Roland Scheidegger <srol...@vmware.com> Am 27.03.2018 um 00:49 schrieb Rob Clark: > The VECN() macro was taking advantage of a GCC specific feature that is > not available on lesser compilers, mostly for the purposes of avoiding a > mac

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