Re: [Mesa-dev] [PATCH] gallium: replace pipe_type enum with tgsi_return_type enum

Reviewed-by: Roland Scheidegger Roland Am 22.09.2014 21:36, schrieb Brian Paul: > The only place the enum pipe_type was used is for the TGSI sampler > view return type. So make it a TGSI type. Note: it appears this > part of TGSI isn't used by anyone so it may be removed

Re: [Mesa-dev] [PATCH] gallivm: fix idiv

> Sent: 23 September 2014 18:30 > To: Jose Fonseca; mesa-dev@lists.freedesktop.org > Cc: Roland Scheidegger; 10.2 10.3 > Subject: [PATCH] gallivm: fix idiv > > From: Roland Scheidegger > > ffeb77c7b0552a8624e46e65d6347240ac5ae84d had a typo which turned all signed > i

Re: [Mesa-dev] [PATCH] mesa: Move register_allocate.c to util.

This change seems to cause compile failure with scons: Compiling src/util/register_allocate.c ... src/util/register_allocate.c:76:26: fatal error: main/imports.h: No such file or directory #include "main/imports.h" Looks like it could be fixed by patching up the CPPPATH in the SConscript file

Re: [Mesa-dev] [PATCH] mesa: Move register_allocate.c to util.

dency too though. > > -Brian > > On 09/23/2014 04:26 PM, Roland Scheidegger wrote: >> This change seems to cause compile failure with scons: >> >>Compiling src/util/register_allocate.c ... >> src/util/register_allocate.c:76:26: fatal error: main/imports

Re: [Mesa-dev] [PATCH] mesa: Move register_allocate.c to util.

Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these to util code. That plus the things I already mentioned should be all needed I think. But I strongly believe either this needs to be done or we should revert it. Roland Am 24.09.2014 00:44, schrieb Roland Scheidegger

Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures

Yes cubemaps should have array_size == 6 always in gallium. You just have to be careful whenever translating things from mesa to gallium as things like that won't be true in core mesa of course (similar to 1d array textures having height and so on) due to OpenGL weirdness for historical reasons. R

Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures

7;d like > to push this out tonight, pending a full piglit run. > > On Wed, Sep 24, 2014 at 1:35 PM, Roland Scheidegger > wrote: >> Yes cubemaps should have array_size == 6 always in gallium. You just >> have to be careful whenever translating things from mesa to gallium as

Re: [Mesa-dev] [PATCH] mesa: Move register_allocate.c to util.

Am 24.09.2014 21:52, schrieb Eric Anholt: > Roland Scheidegger writes: > >> Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these >> to util code. That plus the things I already mentioned should be all >> needed I think. But I strongly believe either

Re: [Mesa-dev] [PATCH] mesa/st: NumLayers is only valid for array textures

Am 24.09.2014 23:23, schrieb Ilia Mirkin: > On Wed, Sep 24, 2014 at 5:17 PM, Roland Scheidegger > wrote: >> I don't really qualified to review, IIRC I mentioned it was tricky to >> see if it's right when you pushed it first, and this has not changed. >> Some co

Re: [Mesa-dev] [PATCH] llvmpipe: move lp_jit_screen_init() call after allocation of screen object

g_get_flags_option("LP_DEBUG", lp_debug_flags, 0 ); > #endif > @@ -570,6 +567,11 @@ llvmpipe_create_screen(struct sw_winsys *winsys) > if (!screen) >return NULL; > > + if (!lp_jit_screen_init(screen)) { > + FREE(screen); > + return NULL; > +

Re: [Mesa-dev] [PATCH 02/13] tgsi: simplify shader properties in tgsi_shader_info

Am 30.09.2014 18:46, schrieb Marek Olšák: > From: Marek Olšák > > Use an array of properties indexed by TGSI_PROPERTY_* definitions. > --- > src/gallium/auxiliary/draw/draw_gs.c | 23 - > src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 15 +++--- > src/gallium/auxiliary/tg

Re: [Mesa-dev] [PATCH] gallivm: fix build for LLVM 3.2

n before but with a more descriptive commit message)? > > Greetings > Mathias > Looks good to me too. 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] util: add u_lowering

Am 30.09.2014 23:38, schrieb Rob Clark: > From: Rob Clark > > TGSI->TGSI pass, extracted from freedreno. Currently provides the > following lower support, to help drivers emulate unsupported opcodes > or features: > > Individual opcodes: > DST, XPD, SCS, LRP, FRC, POW, LIT, EXP, LOG, DP4, DP3

Re: [Mesa-dev] [PATCH] gallivm: force sse instructions for llvm 3.5+

Am 01.10.2014 16:56, schrieb Maarten Lankhorst: > This fixes a crash when llvmpipe tries to use sse instructions, > but llvm detects a cpu that doesn't support them. > > Fixes for example piglit/bin/amd_seamless_cubemap_per_texture -fbo -auto > on i386 when run inside "qemu -cpu qemu32", which wou

Re: [Mesa-dev] [PATCH] gallivm: force sse instructions for llvm 3.5+

Am 02.10.2014 um 09:31 schrieb Maarten Lankhorst: > Op 02-10-14 om 09:10 schreef Maarten Lankhorst: >> Hey, >> >> Op 02-10-14 om 04:22 schreef Roland Scheidegger: >>> Am 01.10.2014 16:56, schrieb Maarten Lankhorst: >>>> This fixes a crash when llvmpipe tr

Re: [Mesa-dev] [PATCH] gallivm: force sse instructions for llvm 3.5+

Am 02.10.2014 um 17:36 schrieb Jose Fonseca: > On 02/10/14 15:04, Roland Scheidegger wrote: >> Am 02.10.2014 um 09:31 schrieb Maarten Lankhorst: >>> Op 02-10-14 om 09:10 schreef Maarten Lankhorst: >>>> Hey, >>>> >>>> Op 02-10-14 om 04:22

Re: [Mesa-dev] [PATCH] gallivm: force sse instructions for llvm 3.5+

Am 02.10.2014 um 18:11 schrieb Ilia Mirkin: > On Thu, Oct 2, 2014 at 11:34 AM, Jose Fonseca wrote: >> On 02/10/14 03:09, Ilia Mirkin wrote: >>> >>> On Wed, Oct 1, 2014 at 10:56 AM, Maarten Lankhorst >>> wrote: This fixes a crash when llvmpipe tries to use sse instructions, but llvm

Re: [Mesa-dev] [PATCH] tgsi: change tgsi_shader_info::properties to a one-dimensional array

_FS_COLOR0_WRITES_ALL_CBUFS][0]; > + > softpipe->fs_variant->info.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS]; > > for (cbuf = 0; cbuf < softpipe->framebuffer.nr_cbufs; cbuf++) { >if (softpipe->framebuffer.cbufs[cbuf]) { > diff --git a/src/gallium/drivers/softpipe/sp_setup.c > b/src/gallium/drivers/softpipe/sp_setup.c > index 989ed9c..6704015 100644 > --- a/src/gallium/drivers/softpipe/sp_setup.c > +++ b/src/gallium/drivers/softpipe/sp_setup.c > @@ -563,9 +563,9 @@ setup_fragcoord_coeff(struct setup_context *setup, uint > slot) > { > const struct tgsi_shader_info *fsInfo = > &setup->softpipe->fs_variant->info; > boolean origin_lower_left = > - fsInfo->properties[TGSI_PROPERTY_FS_COORD_ORIGIN][0]; > + fsInfo->properties[TGSI_PROPERTY_FS_COORD_ORIGIN]; > boolean pixel_center_integer = > - fsInfo->properties[TGSI_PROPERTY_FS_COORD_PIXEL_CENTER][0]; > + fsInfo->properties[TGSI_PROPERTY_FS_COORD_PIXEL_CENTER]; > > /*X*/ > setup->coef[slot].a0[0] = pixel_center_integer ? 0.0f : 0.5f; > 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] mesa/main: Fix unpack_R5G6B5_UNORM.

Am 08.10.2014 um 07:11 schrieb Jason Ekstrand: > > On Oct 8, 2014 6:36 AM, "Iago Toral" > wrote: >> >> El 2014-10-07 21:46, Jason Ekstrand escribió: >> >>> On Oct 7, 2014 12:04 PM, "Iago Toral Quiroga" > >>> wrote: There is a comme

Re: [Mesa-dev] [PATCH 05/13] gallium/docs: refactoring opcode RCC

Am 08.10.2014 um 13:40 schrieb Alexander Troosh: > --- > src/gallium/docs/source/tgsi.rst |5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/src/gallium/docs/source/tgsi.rst > b/src/gallium/docs/source/tgsi.rst > index 12c675e..b1be923 100644 > --- a/src/gallium/do

Re: [Mesa-dev] [PATCH] gallium: add basevertex and vertexid_zerobase semantics

VERTEX. VERTEXID can be implemented trivially using the two. I don't think we need any cap bits, because this is required by OpenGL. In the worst case, drivers will have to store BASEVERTEX in a constant buffer. Marek On Mon, Oct 13, 2014 at 9:45 AM, wrote: From: Roland Scheidegger Just

Re: [Mesa-dev] [PATCH] gallium: add basevertex and vertexid_zerobase semantics

CPRYNIgQnp1SHc%3D%0A&s=bc5bf989d990de1e6ac853b06376d27362b58a2ac347ca34352d9211423578fa On Mon, Oct 13, 2014 at 2:44 PM, Roland Scheidegger wrote: Oh I actually thought that BASEVERTEX was available as an vs input in some gl extension. Looks like that's not the case. Still, I guess we'd need

Re: [Mesa-dev] Assertion `key->nr_vertex_elements <= llvm->draw->pt.nr_vertex_elements' failed.

On 10/14/2014 01:14 PM, Thomas Sondergaard wrote: using llvmpipe I'm hitting the following assertion in some old code that use glEdgeFlag(). src/gallium/auxiliary/draw/draw_llvm.c:1824:draw_llvm_make_variant_key: Assertion `key->nr_vertex_elements <= llvm->draw->pt.nr_vertex_elements' failed. I

Re: [Mesa-dev] [Bug 84566] Unify the format conversion code

On 10/16/2014 08:33 AM, bugzilla-dae...@freedesktop.org wrote: *Comment # 25 I thought we killed color indexing with fire a while back. Did we miss some? You can't kill glBitmap (in a non-core context, anyway). Strictly speaking these aren't color indexed textures, but still hit all the same

Re: [Mesa-dev] [PATCH 1/4] gallium: add PIPE_SHADER_CAP_MAX_OUTPUTS and use it in st/mesa

On 10/16/2014 08:33 AM, Marek Olšák wrote: From: Marek Olšák With 5 shader stages and various combinations of enabled and disabled shaders, the maximum number of outputs in one shader doesn't have to be equal to the maximum number of inputs in the following shader. --- src/gallium/auxiliary/g

Re: [Mesa-dev] [PATCH 3/4] glsl_to_tgsi: fix the value of gl_FrontFacing with native integers

Looks correct to me. I agree a boolean face var would be nice. Last time looking at it it seemed a bit non trivial (because the face var isn't just used in glsl fragment shaders). Roland On 10/16/2014 08:33 AM, Marek Olšák wrote: From: Marek Olšák We must convert it to boolean from the DX9

Re: [Mesa-dev] [PATCH 1/4] gallium: add PIPE_SHADER_CAP_MAX_OUTPUTS and use it in st/mesa

On 10/16/2014 12:55 PM, Marek Olšák wrote: On Thu, Oct 16, 2014 at 8:40 PM, Roland Scheidegger wrote: On 10/16/2014 08:33 AM, Marek Olšák wrote: From: Marek Olšák With 5 shader stages and various combinations of enabled and disabled shaders, the maximum number of outputs in one shader

Re: [Mesa-dev] [PATCH 06/16] gallium: add blending to pipe blit

Hmm shouldn't there be a cap bit for this unless you fix all drivers to actually honor it? (Though I'm unsure if it makes all that much sense in general, pipe blit is already quite a can-do-everything call.) Roland On 10/18/2014 01:54 PM, David Heidelberger wrote: From: Christoph Bumiller S

Re: [Mesa-dev] [PATCH 10/16] gallium/auxiliary: prefer intrinsic

On 10/18/2014 01:55 PM, David Heidelberger wrote: From: Christoph Bumiller Signed-off-by: David Heidelberger --- src/gallium/auxiliary/util/u_atomic.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/util/u_atomic.h b/src/gallium/auxiliary/util/

Re: [Mesa-dev] [PATCH] Prefer intrinsics to handrolled atomic ops for Linux (v2)

Am 19.10.2014 um 18:32 schrieb David Heidelberger: > v2: prefer intrinsics only on Linux to avoid compilation problems on other > platforms [1]. > > Is posible that other OS could also benefit from intrinsic. > > We need this patch, because Gallium Nine use directly intrinsics. > Otherwise build

Re: [Mesa-dev] [PATCH 09/14] gallium/auxiliary: add inc and dec alternative with return

Am 20.10.2014 um 14:37 schrieb David Heidelberger: > From: Christoph Bumiller > > They're useful for Gallium Nine. > > Signed-off-by: David Heidelberger > --- > src/gallium/auxiliary/util/u_atomic.h | 26 ++ > 1 file changed, 26 insertions(+) > > diff --git a/src/galli

Re: [Mesa-dev] [PATCH 4/4] gallium: Enable ARB_clip_control for gallium drivers.

Am 22.10.2014 um 07:31 schrieb mathias.froehl...@gmx.net: > From: Mathias Fröhlich > > Gallium should be prepared fine for ARB_clip_control. > So enable this and mention it in the release notes. > > Signed-off-by: Mathias Froehlich > --- > docs/GL3.txt| 2 +- >

Re: [Mesa-dev] [PATCH 3/3] gallivm: Properly update for removal of JITMemoryManager in LLVM 3.6.

Am 22.10.2014 um 21:11 schrieb jfons...@vmware.com: > From: José Fonseca > > JITMemoryManager was removed in LLVM 3.6, and replaced by its base > class RTDyldMemoryManager. > > This change fixes our JIT memory managers specializations to derive > from RTDyldMemoryManager in LLVM 3.6 instead of J

Re: [Mesa-dev] [PATCH 4/5] gallium: introduce PIPE_CAP_CLIP_HALFZ.

Am 23.10.2014 um 22:56 schrieb Mathias Fröhlich: > > Hi Michel, > > On Thursday, October 23, 2014 11:47:32 Michel Dänzer wrote: >> Does softpipe really handle it though? Have you tested that? > I have just rechecked, both softpipe and llvmpipe gallium drivers > pass the piglit test. > > I though

Re: [Mesa-dev] [PATCH 2/2] llvmpipe: Ensure the packed input of the lp_test_format is aligned.

For the series: Reviewed-by: Roland Scheidegger Am 24.10.2014 um 21:34 schrieb jfons...@vmware.com: > From: José Fonseca > > https://bugs.freedesktop.org/show_bug.cgi?id=85377 > http://llvm.org/bugs/show_bug.cgi?id=21365 > --- > src/gallium/drivers/llvmpipe/lp_

Re: [Mesa-dev] [PATCH V2] mesa: add SSE optimisation for glDrawElements

Am 24.10.2014 um 23:06 schrieb Ian Romanick: > On 10/24/2014 05:47 AM, Timothy Arceri wrote: >> Makes use of SSE to speed up compute of min and max elements >> >> Callgrind cpu usage results from pts benchmarks: >> >> Openarena 0.8.8: 3.67% -> 1.03% >> UrbanTerror: 2.36% -> 0.81% >> >> Signed-off-b

Re: [Mesa-dev] [PATCH 1/2] util: Move ffs, _mesa_bitcount, and friends to the util folder

I like the idea of the series, however gallium still uses its own definitions (by the looks of it supporting more compilers for native definitions but in some cases with worse code for the fallback) sometimes with different names (fls/util_last_bit) and sometimes with the same even (ffs and util_bi

Re: [Mesa-dev] [PATCH][RFC] mesa/main: Clamp rgba with streamed sse

Am 31.10.2014 um 18:17 schrieb Matt Turner: > On Fri, Oct 31, 2014 at 3:13 AM, Juha-Pekka Heikkila > wrote: >> Signed-off-by: Juha-Pekka Heikkila >> --- >> src/mesa/main/colormac.h | 20 +++ >> src/mesa/main/pixeltransfer.c | 59 >> --- >>

Re: [Mesa-dev] [PATCH] draw: allow LLVM use on non-SSE2 X86 cpus

---- > 1 file changed, 1 insertion(+), 14 deletions(-) > Reviewed-by: Roland Scheidegger Though at this point I'll have to wonder why you'd actually want to use it with a non-sse2 capable cpu... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Set llvmpipe and softpipe note only for MSAA.

Am 02.11.2014 um 18:35 schrieb Romain Failliot: > Hi! > > Sorry if I'm doing this wrong, first time here. I've tried git > send-mail, but I don't have an SMTP server so it wasn't working. Here is > the simple commit (and the patch attached): > > Set llvmpipe and softpipe note only for MSAA. >

Re: [Mesa-dev] [PATCH 2/3][RFC v2] mesa/main/x86: Add sse2 streaming clamping

Am 04.11.2014 um 13:05 schrieb Juha-Pekka Heikkila: > Signed-off-by: Juha-Pekka Heikkila > --- > src/mesa/Makefile.am | 8 +++ > src/mesa/main/x86/sse2_clamping.c | 103 > ++ > src/mesa/main/x86/sse2_clamping.h | 49 ++ > 3 file

Re: [Mesa-dev] [PATCH 2/3][RFC v2] mesa/main/x86: Add sse2 streaming clamping

Am 05.11.2014 um 10:13 schrieb Juha-Pekka Heikkila: > On 04.11.2014 23:24, Roland Scheidegger wrote: >> Am 04.11.2014 um 13:05 schrieb Juha-Pekka Heikkila: >>> Signed-off-by: Juha-Pekka Heikkila >>> --- >>> src/mesa/Makefile.am | 8 +++ >>

[Mesa-dev] ARB_texture_buffer_range offsets

Trying to fix some bug due to alignment issues in llvmpipe's vertex fetch, I came across some issue with ARB_texture_buffer_range. Namely, it looks like the offsets specified there are always in bytes, regardless the actual format (hence, as long as the TEXTURE_BUFFER_OFFSET_ALIGNMENT is 1, it woul

Re: [Mesa-dev] ARB_texture_buffer_range offsets

gb32), so maybe it's things like that why the offset can be just byte aligned (in other words, I'm not convinced it's just a spec bug, d3d10 doesn't have that problem with alignment). Roland > > Marek > > On Wed, Nov 5, 2014 at 9:08 PM, Roland Scheidegger w

Re: [Mesa-dev] ARB_texture_buffer_range offsets

gned (the 2 lowest bits are > ignored). I guess the cap should be 4 then. > > Marek > > On Thu, Nov 6, 2014 at 4:55 PM, Roland Scheidegger wrote: >> Am 06.11.2014 um 16:15 schrieb Marek Olšák: >>> I'd say it's a spec bug. ARB_texture_buffer_range should

Re: [Mesa-dev] [PATCH] util/format: Generate floating point constants for clamping.

Surprising indeed... Reviewed-by: Roland Scheidegger Am 07.11.2014 um 15:32 schrieb jfons...@vmware.com: > From: José Fonseca > > This commit causes the generated C code to change as > > union util_format_r32g32b32a32_sscaled pixel; > - pixel.chan.r =

Re: [Mesa-dev] [PATCH] util/format: Generate floating point constants for clamping.

this corner cases. > I suspect llvmpipe's LLVM IR generation suffers from similar issues . > > To starters we need to add test cases for these... I think we mostly get lucky because a lot of possible conversions are things which aren't hit in practice. > Jose > >

Re: [Mesa-dev] [PATCH] llvmpipe: Avoid deadlock when unloading opengl32.dll

Reviewed-by: Roland Scheidegger Am 07.11.2014 um 17:52 schrieb jfons...@vmware.com: > From: José Fonseca > > On Windows, DllMain calls and thread creation/destruction are > serialized, so when llvmpipe is destroyed from DllMain waiting for the > rasterizer threads to finis

Re: [Mesa-dev] [PATCH] util/format: Fix clamping to 32bit integers.

.0f) val = 2147483647) Reviewed-by: Roland Scheidegger Am 07.11.2014 um 22:25 schrieb jfons...@vmware.com: > From: José Fonseca > > Use clamping constants that guarantee no integer overflows. > > As spotted by Chris Forbes. > > This causes the code to change as: > > -

Re: [Mesa-dev] Removing unused opcodes (TGSI, Mesa IR)

It looks like ARR is mildly useful though as hw often can implement it natively and it benefits at least one state tracker (not that and optimizing backend couldn't recognize round+arl but llvmpipe wouldn't at least right now). So, maybe it would be better to keep it for now. Roland Am 13.11.2014

Re: [Mesa-dev] Removing unused opcodes (TGSI, Mesa IR)

FWIW opencl explicit conversion instructions have optional rounding mode modifiers. Roland Am 13.11.2014 um 21:19 schrieb Jose Fonseca: > I've eliminated our internal dependency on TGSI_OPCODE_CND (by replacing > SUB+CMP). So you can commit the change to remove it as far as I'm concerned. > >

Re: [Mesa-dev] Suboptimal code generation

Am 14.11.2014 um 19:38 schrieb Henri Verbeet: > On 14 November 2014 18:50, Ilia Mirkin wrote: >> I can't speak for the radeon guys, but I know I sure would love to see >> any reports of poor code being generated by nouveau in response to >> legitimate-seeming TGSI (or GLSL). In some cases, a simpl

Re: [Mesa-dev] Move mesa version scheme to a more common style ?

Am 14.11.2014 um 15:39 schrieb Emil Velikov: > Hello all, > > This is an old question that I had laying around - why doesn't mesa use > a more conventional numbering for the development/rc releases ? > > Eg. > mesa 10.4.0-rc1 -> 10.3.99.901 > mesa 10.4.0-rc2 -> 10.3.99.902 > ... > mesa 10.4.0

Re: [Mesa-dev] [PATCH] st/mesa: add a fallback for clear_with_quad when no vs_layer

Am 17.11.2014 um 16:21 schrieb Jose Fonseca: > > On 17/11/14 13:32, Ilia Mirkin wrote: >> Well, nvidia hw (pre-GM204; it seems like it's supported there now) >> doesn't support setting gl_Layer from VS, so it's just not an option >> there. However I do believe that the HW has enough support to han

Re: [Mesa-dev] [PATCH] nv50/ir: saturate FRC result to avoid completely bogus values

Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: > For values above integer accuracy in floats, val - floor(val) might > actually produce a value greater than 1. For such large floats, it's > reasonable to be imprecise, but it's unreasonable for FRC to return a > value that is not between 0 and 1. > >

Re: [Mesa-dev] [PATCH] nv50/ir: saturate FRC result to avoid completely bogus values

Am 18.11.2014 um 15:05 schrieb Ilia Mirkin: > On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger > wrote: >> Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: >>> For values above integer accuracy in floats, val - floor(val) might >>> actually produce a value greater

Re: [Mesa-dev] [PATCH] rtasm,translate: Re-enable SSE on Mingw64.

Reviewed-by: Roland Scheidegger Do you know if that's due to MinGW changes or something else why it no longer causes crashes? Roland Am 19.11.2014 um 13:10 schrieb jfons...@vmware.com: > From: José Fonseca > > This reverts f4dd0991719ef3e2606920c5100b372181c60899. > > T

Re: [Mesa-dev] [PATCH 3/3] wgl: Ensure PIXELFORMATDESCRIPTOR members are zeroed.

Some small nitpick below, but otherwise the series is: Reviewed-by: Roland Scheidegger Am 19.11.2014 um 19:23 schrieb jfons...@vmware.com: > From: José Fonseca > > I suddenly started seeing many simple GL apps, including wglinfo, > choosing Microsoft GDI OpenGL implementation,

Re: [Mesa-dev] [PATCH] rtasm,translate: Re-enable SSE on Mingw64.

Am 19.11.2014 um 18:21 schrieb Jon TURNEY: > On 19/11/2014 15:25, Jose Fonseca wrote: >> No idea. But the impression I generally have is MinGW has come a long >> way since then (3 years ago.) > > I think there was at least one bug in mesa which prevented this from > working, see commit cedfd79b A

Re: [Mesa-dev] [PATCH 3/4] r600/radeonsi: implement new float comparison instructions

racy / non-normal number treatment from one which does not have to (at least older GL versions allowed just about everything wrt float math). Roland > > Marek > > On Tue, Aug 13, 2013 at 7:04 PM, wrote: >> From: Roland Scheidegger >> >> Also use ordered compar

Re: [Mesa-dev] [PATCH 3/9] scons: Disable MSVC signed/unsigned mismatch warnings.

Am 26.11.2014 um 19:47 schrieb jfons...@vmware.com: > From: José Fonseca > > Unfortunately gcc completely ignores the issue, and as result code that > mixes signed/unsigned is so widespread through the code base end up > being little more than noise, potentially obscuring more pertinent > warning

Re: [Mesa-dev] [PATCH 4/9] draw, gallivm, llvmpipe: Avoid implicit casts of 32-bit shifts to 64-bits.

I guess we could do explicit cast after the shift but we probably don't care enough about the slight performance hit on 32bit platforms (though actually some compilers might be smart enough to figure out a 32bit shift is really all that's needed). In any case, for the series: Reviewed-

Re: [Mesa-dev] [PATCH] Set llvmpipe and softpipe note only for MSAA.

;t merged yet (it's been more than 20 > days). > I can wait, but I just want to be sure I'm not waiting for nothing :D > > Thanks! > > 2014-11-03 6:02 GMT-05:00 Roland Scheidegger : >> >> Am 02.11.2014 um 18:35 schrieb Romain Failliot: >>> Hi! >&

Re: [Mesa-dev] sampler types in tgsi

Am 29.11.2014 um 06:12 schrieb Ilia Mirkin: > Hello, > > It appears that the A3XX ISA (freedreno) requires the texture > instruction to properly specify its output type (or at least f32 vs > u32). Now I could stick this into a driver-local shader key, but it > seems unfortunate since in glsl, it k

Re: [Mesa-dev] [PATCH 1/3] mesa: Replace _mesa_round_to_even() with _mesa_roundeven().

Am 12.03.2015 um 23:53 schrieb Carl Worth: > On Thu, Mar 12 2015, Matt Turner wrote: >> I think you misread. rint() *does* provide the behavior we want >> (round-to-nearest, half to even) when the rounding mode is the default >> round-to-nearest. > > Thanks. I did at least verify that behaviorally

Re: [Mesa-dev] [PATCH 4/4] i965/fs: Don't issue FB writes for bound but unwritten color targets.

I was just wondering, this actually clearly looks like a workaround for a broken app. GLSL and OGL have language such as "The variable gl_FragData is an array. Writing to gl_FragData[n] specifies the fragment data that will be used by the subsequent fixed functionality pipeline for data n. If su

Re: [Mesa-dev] gallium separate depth and stencil

To provide some background why separate attachments aren't supported in gallium: 1) OpenGL always allowed this, however noone seriously expected this to actually be supported. At least gaming hardware pretty much was limited to d24s8. 2) D3D10 also only has one attachment point for both, so there m

Re: [Mesa-dev] [PATCH] gallivm: removes unused 'builder' variable

t;builder; > const struct lp_type type = bld->type; > > assert(lp_check_value(type, a)); > Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Correct behaviour of glDrawPixels and glBitmap when texturing is enabled.

Am 23.03.2015 um 00:50 schrieb Matthew Dawson: > Hi all, > > I've been working fixing the piglit tests around glDrawPixels, and I'm not > sure what the correct behaviour of glDrawPixels is when any texturing units > are enabled (tested with the draw-pixel-with-texture piglit test). After > ask

Re: [Mesa-dev] [PATCH] tgsi: fix out-of-bounds access for cube arrays

si_exec_channel *lod = &ZeroVec; > enum tgsi_sampler_control control = tgsi_sampler_lod_none; > uint chan; > Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] llvmpipe: enable ARB_texture_gather

Right. I actually thought I already pushed this but turns out I didn't... Roland Am 30.03.2015 um 17:46 schrieb Ilia Mirkin: > Perhaps mention that llvmpipe now supports ARB_texture_gather in > GL3.txt and relnotes/10.6.0.html? > > On Sun, Mar 29, 2015 at 8:12 PM, wrote

Re: [Mesa-dev] [PATCH] gallivm: Fix build against LLVM 3.7 SVN r233648

*MII, *MRI, > *STI)); > +#endif > if (!Printer) { >Out << "error: no instruction printer for target " << Triple.c_str() > << "\n"; >Out.flush(); > Does it actually work? I re

Re: [Mesa-dev] ETC2 support with llvmpipe

FWIW this works by emulation of these formats - mesa will uncompress them when specified to some uncompressed format. This means though there's zero benefit in using them over uncompressed formats (same memory requirements and performance when texturing, just increased overhead when specifying the

Re: [Mesa-dev] [PATCH 4/4] RFC: nir: add lowering for idiv/udiv/umod

Am 01.04.2015 um 00:57 schrieb Rob Clark: > From: Rob Clark > > Based on the algo from NV50LegalizeSSA::handleDIV() and handleMOD(). > See also trans_idiv() in freedreno/ir3/ir3_compiler.c (which was an > adaptation of the nv50 code from Ilia). > > Just sending as an rfc right now, since I'm not

Re: [Mesa-dev] [PATCH] gallivm: Fix build against LLVM 3.7 SVN r233648

Am 01.04.2015 um 04:57 schrieb Michel Dänzer: > On 01.04.2015 00:36, Roland Scheidegger wrote: >> Am 31.03.2015 um 08:33 schrieb Michel Dänzer: >>> From: Michel Dänzer >>> >>> Signed-off-by: Michel Dänzer >>> --- >>> src/gallium/auxiliary/

Re: [Mesa-dev] [PATCH 4/4] RFC: nir: add lowering for idiv/udiv/umod

Am 01.04.2015 um 03:44 schrieb Rob Clark: > On Tue, Mar 31, 2015 at 9:03 PM, Roland Scheidegger > wrote: >> Am 01.04.2015 um 00:57 schrieb Rob Clark: >>> From: Rob Clark >>> >>> Based on the algo from NV50LegalizeSSA::handleDIV() and handleMOD(). >

Re: [Mesa-dev] [PATCH 4/4] RFC: nir: add lowering for idiv/udiv/umod

Am 01.04.2015 um 15:50 schrieb Ilia Mirkin: > On Wed, Apr 1, 2015 at 7:09 AM, Roland Scheidegger wrote: >> Am 01.04.2015 um 03:44 schrieb Rob Clark: >>> On Tue, Mar 31, 2015 at 9:03 PM, Roland Scheidegger >>> wrote: >>>> Am 01.04.2015 um 00:57 s

Re: [Mesa-dev] [PATCH 4/4] RFC: nir: add lowering for idiv/udiv/umod

Am 01.04.2015 um 20:11 schrieb Matt Turner: > On Tue, Mar 31, 2015 at 6:44 PM, Rob Clark wrote: >> On Tue, Mar 31, 2015 at 9:03 PM, Roland Scheidegger >> wrote: >>> So if this is not enough precision, maybe should state how large the >>> error can be? >>&g

Re: [Mesa-dev] [PATCH 1/4] mesa: Remove pointless USE_EXTERNAL_DXTN_LIB macro.

_LIB > if (!dxtlibhandle) { >dxtlibhandle = _mesa_dlopen(DXTN_LIBNAME, 0); >if (!dxtlibhandle) { > @@ -117,9 +112,6 @@ _mesa_init_texture_s3tc( struct gl_context *ctx ) > if (dxtlibhandle) { >ctx->Mesa_DXTn = GL_TRUE; > } > -#else > -

Re: [Mesa-dev] [PATCH] u_tile: fix stencil texturing tests under softpipe

Am 07.04.2015 um 02:15 schrieb Dave Airlie: > From: Dave Airlie > > arb_stencil_texturing-draw failed under softpipe because we got a float > back from the texturing function, and then tried to U2F it, stencil > texturing returns ints, so we should fix the tiling to retrieve > the stencil values

Re: [Mesa-dev] [PATCH] indices: fix provoking vertex for quads/quadstrips

It will look different with llvmpipe if you use the right debug variables (GALLIVM_DEBUG=no_brilinear,no_quad_lod,no_rho_approx), though still fail. I think the test may not be really valid. This is because if you use texgrad, the driver/hw probably will (or should) use per-pixel lod. But if you do

Re: [Mesa-dev] [PATCH v2 1/2] primconvert: select pv convention only from flatshade_first

This looks good to me. Note that generally it is not true that this doesn't affect things when flatshading isn't in effect - this is only true if you only have old-style semantics, where color is the only attribute which can be flatshaded (and is done so with the rasterizer setting). But not true i

Re: [Mesa-dev] [PATCH 1/2] gallivm: don't use control flow when doing indirect constant buffer lookups

Am 08.04.2015 um 21:13 schrieb Jose Fonseca: > Series looks good to me. > > Just a few suggestions inline. > > > On 04/04/15 15:50, srol...@vmware.com wrote: >> From: Roland Scheidegger >> >> llvm goes crazy when doing that, using way more memory and time, &

Re: [Mesa-dev] [PATCH] glsl: extend GLSLSkipStrictMaxUniformLimitCheck to uniform block size

FWIW fsexceed crashes badly with llvmpipe (this is because we copy the constants into scene data, and the block size there is 64kB). I've actually wondered if it's the state tracker's job or that of the driver to ensure nothing bad happens. It is however happening due to the actual buffer being lar

Re: [Mesa-dev] llvmpipe support for ARM?

There were reports with varying success of running llvmpipe with arm in the past but I haven't heard anything for a while. In theory it should work (and crashing in the pixel shader is an indication the vertex shader worked or at least didn't crash). But it's not really tested and hence might easil

Re: [Mesa-dev] llvmpipe support for ARM?

4.3 > both are fedora 21 standard packages without modifications. > I haven't tried anything more complex than glxgears > > jan > > On Wed, 2015-04-15 at 16:30 +0200, Roland Scheidegger wrote: >> There were reports with varying success of running llvmpipe with arm in >>

Re: [Mesa-dev] [PATCH] libgl-gdi: Prevent "pure virtual method called" error when.

Makes sense I guess. That teardown all feels so unnatural unfortunately :-(. Roland Am 16.04.2015 um 14:09 schrieb Jose Fonseca: > When running piglit w/ llvmpipe on Windows several tests terminate > abnormally just when the test exits. > > The problem was that LLVMContextDispose was being calle

[Mesa-dev] non-16byte-aligned constant buffers in gallium?

Hi, when looking at a regression (piglit ext_transform_feedback-immediate-reuse-uniform-buffer, bug 90081) I realized that behavior wrt non-size-aligned constant buffers doesn't seem to be all that clear cut. In particular I'm wondering if what the test (or rather the state tracker) does is actual

Re: [Mesa-dev] non-16byte-aligned constant buffers in gallium?

looking for. > I guess the test shouldn't ignore that. The value is 256 for R600 and > 4 for GCN. > > Marek > > On Sat, Apr 18, 2015 at 5:46 AM, Roland Scheidegger > wrote: >> Hi, >> >> when looking at a regression (piglit >> ext_transform_feedback

Re: [Mesa-dev] [PATCH] softpipe: fix stencil write to use an integer value

Reviewed-by: Roland Scheidegger Am 22.04.2015 um 09:41 schrieb Dave Airlie: > From: Dave Airlie > > This fixes a number of regressions since > 61393bdcdc3b63624bf6e9730444f5e9deeedfc8 > u_tile: fix stencil texturing tests under softpipe > > should fix: > http

Re: [Mesa-dev] [PATCH] draw: fix prim ids when there's no gs

Am 23.04.2015 um 02:35 schrieb Matt Turner: > On Wed, Apr 22, 2015 at 4:06 PM, wrote: >> From: Roland Scheidegger >> >> We were resetting the prim id count for each run of the prim assembler, >> hence this only worked when the draw calls were very small (the exac

Re: [Mesa-dev] [PATCH 08/16] st/nine: Change x86 FPU Control word on device creation as on wined3d and windows

Am 25.04.2015 um 09:58 schrieb Axel Davy: > Le 24/04/2015 23:42, Henri Verbeet a écrit : >> On 24 April 2015 at 22:09, Axel Davy wrote: >>> +static void nine_setup_fpu(void) >>> +{ >>> +#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) >>> +WORD cw; >>> +__asm__ volatile

Re: [Mesa-dev] [PATCH 08/16 v2] st/nine: Change x86 FPU Control word on device creation

Am 26.04.2015 um 18:36 schrieb Ilia Mirkin: > On Sun, Apr 26, 2015 at 12:27 PM, Axel Davy wrote: >> From: Tiziano Bacocco >> >> As on wined3d and windows, when D3DCREATE_FPU_PRESERVE is not >> specified, change the fpu control word to all exceptions masked, >> single precision, round to nearest.

Re: [Mesa-dev] [PATCH] mesa: Fix test for big-endian architecture in compiler.h

Am 12.02.2016 um 10:01 schrieb Jochen Rollwagen: > Hi, > > i think i found & fixed a bug in mesa concerning tests for big-endian > machines. The defines tested don't exist or are wrongly defined so the > test (probably) never fires. The gcc defines on my machine concerning > big-endian are > > jo

Re: [Mesa-dev] [PATCH v3 17/19] st/mesa: add compute program dispatch callbacks

Am 10.02.2016 um 19:10 schrieb Samuel Pitoiset: > This state tracker implements DispatchCompute() and DispatchComputeIndirect(). > > Signed-off-by: Samuel Pitoiset > Reviewed-by: Marek Olšák > Reviewed-by: Ilia Mirkin > --- > src/mesa/Makefile.sources | 2 + > src/mesa/state_trac

Re: [Mesa-dev] [PATCH v3 17/19] st/mesa: add compute program dispatch callbacks

Am 13.02.2016 um 16:56 schrieb Samuel Pitoiset: > > > On 02/13/2016 04:52 PM, Roland Scheidegger wrote: >> Am 10.02.2016 um 19:10 schrieb Samuel Pitoiset: >>> This state tracker implements DispatchCompute() and >>> DispatchComputeIndirect(). >>> >&g

Re: [Mesa-dev] [PATCH] st/mesa: fix pipe_grid_info initializer

Reviewed-by: Roland Scheidegger Am 13.02.2016 um 17:02 schrieb Samuel Pitoiset: > Fixes MSVC build error which doesn't allow empty initializers. > > Signed-off-by: Samuel Pitoiset > Cc: Roland Scheidegger > --- > src/mesa/state_tracker/st_cb_compute.c | 2 +- > 1

Re: [Mesa-dev] [PATCH] mesa: move assertion in _mesa_cube_face_target()

e_face_target(GLenum target, unsigned face) > { > - assert(face < 6); > - if (target == GL_TEXTURE_CUBE_MAP) > + if (target == GL_TEXTURE_CUBE_MAP) { > + assert(face < 6); >return GL_TEXTURE_CUBE_MAP_POSITIVE_X + face; > - else > + } > + else { >

Re: [Mesa-dev] [PATCH] Handle removal of LLVMAddTargetData in SVN revision 260919

Am 16.02.2016 um 15:45 schrieb Matthew Dawson: > On Tuesday, February 16, 2016 4:19:49 PM EST Michel Dänzer wrote: >> On 16.02.2016 15:25, Matthew Dawson wrote: >>> LLVM removed LLVMAddTargetData for the 3.9 release in r260919. For the >>> two >>> places in mesa where this is called, only enable t

Re: [Mesa-dev] [PATCH] st/mesa: use cso_set_viewport_dims() in try_pbo_upload_common()

urface->width, surface->height, FALSE); > > /* Blend state */ > cso_set_blend(cso, &st->pbo_upload.blend); > Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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