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

For 1-4/7, 6/7: Reviewed-by: Roland Scheidegger srol...@vmware.com 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

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 srol...@vmware.com wrote: For 1-4/7, 6/7: Reviewed-by: Roland Scheidegger srol...@vmware.com I think though using two exclusive booleans is really ugly. Probably should just use

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

and a separate patch) BR, -R On Wed, Jun 10, 2015 at 2:55 PM, Roland Scheidegger srol...@vmware.com wrote: My biggest problem with that is the initial case I saw as a problem: draw is going to modify these shaders in some cases (aaline stage for example), adding its own sampler

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

...@gmail.com wrote: On Tue, Jun 9, 2015 at 9:32 AM, Roland Scheidegger srol...@vmware.com wrote: Am 09.06.2015 um 15:00 schrieb Rob Clark: On Tue, Jun 9, 2015 at 5:01 AM, Jose Fonseca jfons...@vmware.com wrote: On 09/06/15 04:03, Rob Clark wrote: On Mon, Jun 8, 2015 at 10:50 PM, Roland

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

long line... } static void close_prog(struct program *p) Reviewed-by: Roland Scheidegger srol...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

that is unrelated and a separate patch) BR, -R On Wed, Jun 10, 2015 at 2:55 PM, Roland Scheidegger srol...@vmware.com wrote: My biggest problem with that is the initial case I saw as a problem: draw is going to modify these shaders in some cases (aaline stage for example), adding its own sampler

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

. Reviewed-by: Roland Scheidegger srol...@vmware.com 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 problems, as it won't fit into its

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

, 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, On Wed, Jun 17, 2015 at 1:51 PM, Roland

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 robdcl...@gmail.com wrote: On Thu, Jun 11, 2015 at 8:36 PM, Roland Scheidegger srol...@vmware.com wrote: Am 12.06.2015 um 02:02 schrieb Rob Clark: On Thu, Jun 11, 2015 at 5:47 PM, Brian Paul bri

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 bri...@vmware.com wrote: On 06/11/2015 02:38 PM, Rob Clark wrote: From: Rob Clark robcl...@freedesktop.org Some hardware needs to know the sampler type. Update the blit related shaders to include SVIEW

Re: [Mesa-dev] [PATCH 1/7] draw/tgsi: implement geom shader invocation support.

); + total_verts_per_buffer * shader-num_invocations); This can't get very large, right? Otherwise, Reviewed-by: Roland Scheidegger srol...@vmware.com debug_assert(output_verts-verts); #if 0 @@ -592,7 +598,7 @@ int draw_geometry_shader_run(struct draw_geometry_shader

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

(mach, inst, offsets); Reviewed-by: Roland Scheidegger srol...@vmware.com I think though there's a lot more required to make it work in softpipe... Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman

Re: [Mesa-dev] [PATCH] gallivm: Use the LLVM's C disassembly interface.

Looks ok, it's massively simpler and shouldn't break as often. Reviewed-by: Roland Scheidegger srol...@vmware.com Am 28.05.2015 um 17:57 schrieb Jose Fonseca: It doesn't do everything we want. In particular it doesn't allow to detect jumps or return opcodes. Currently we detect the x86's RET

Re: [Mesa-dev] [PATCH] softpipe: fix offset wrapping calculations (v2)

simplified these things in llvmpipe at some point but never did for softpipe (which is mostly why the actual arithmetic is different for the llvmpipe soa sampling path vs. softpipe). I might tackle it one day... Thanks! Reviewed-by: Roland Scheidegger srol...@vmware.com Also fix the gather lod calculation

Re: [Mesa-dev] [PATCH 1/7] draw/tgsi: implement geom shader invocation support.

Am 27.05.2015 um 13:47 schrieb Ilia Mirkin: On Wed, May 27, 2015 at 7:42 AM, Roland Scheidegger srol...@vmware.com wrote: Am 27.05.2015 um 09:45 schrieb Dave Airlie: From: Dave Airlie airl...@redhat.com This is just for softpipe, llvmpipe won't work without some changes. Signed-off

Re: [Mesa-dev] [PATCH 02/11] tgsi/scan: get more information about arrays and handle arrays correctly

Yes, that looks better to me. It may be a bit inconsistent to only do that for inputs/outputs and not for temp but at least this way there's no additional limit on the number of arrays. Roland Am 26.05.2015 um 13:04 schrieb Marek Olšák: From: Marek Olšák marek.ol...@amd.com v2: use less

Re: [Mesa-dev] [PATCH] softpipe: fix offset wrapping calculations

Thanks for addressing this, some minor issues. Am 27.05.2015 um 03:14 schrieb Dave Airlie: Roland pointed out my previous attempt was lacking, so I enhanced the texwrap piglit test, and tested them. This fixes the offset calculations in a number of areas by adding the offset first, it also

Re: [Mesa-dev] [PATCH 4/7] softpipe: add support for indexed queries.

Am 27.05.2015 um 09:45 schrieb Dave Airlie: We need indexed queries to retrieve the geom shader info. Signed-off-by: Dave Airlie airl...@redhat.com --- src/gallium/drivers/softpipe/sp_context.h | 2 +- src/gallium/drivers/softpipe/sp_prim_vbuf.c | 4 ++--

Re: [Mesa-dev] [PATCH 5/7] draw: add support to tgsi paths for geometry streams.

probably inherent to how multiple streams work. So, other than the things I mentioned, for the series: Reviewed-by: Roland Scheidegger srol...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo

Re: [Mesa-dev] [PATCH] gallivm: Do not use NoFramePointerElim with LLVM 3.7

I use this sometimes for debugging things in llvmpipe, so I don't think that's a good option. Without it getting the actual assembly of the shaders would be quite annoying. It is unfortunately true that (due to the heavy use of the unstable C++ API) it breaks very often, but as long as it isn't

Re: [Mesa-dev] [PATCH] gallivm: Disable frame pointer omission on LLVM 3.7.

, true); + LLVMAddTargetDependentFunctionAttr(func, no-frame-pointer-elim-non-leaf, true); +#endif + LLVMRunFunctionPassManager(gallivm-passmgr, func); func = LLVMGetNextFunction(func); } Reviewed-by: Roland Scheidegger srol...@vmware.com

Re: [Mesa-dev] [PATCH] gallivm: Do not use NoFramePointerElim with LLVM 3.7

/05/15 12:56, Roland Scheidegger wrote: I use this sometimes for debugging things in llvmpipe, so I don't think that's a good option. Without it getting the actual assembly of the shaders would be quite annoying. It is unfortunately true that (due to the heavy use of the unstable C++ API

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] [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 mar...@gmail.com wrote: From: Marek Olšák marek.ol...@amd.com Other approaches are being considered: 1) Don't use resource wrappers (views) and pass all view parameters (format, layer range, level) to

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 *sure* that

Re: [Mesa-dev] [PATCH 01/11] gallium: define the maximum number of shader arrays

Do we really need this? I think ideally we wouldn't really need any limit on this, as it is already limited by the max number of the temps (though obviously that number is higher). d3d10 doesn't seem to have any such limit neither. If some driver can't do it, I think it's not unreasonable to

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

, Apr 4, 2015 at 10:50 AM, srol...@vmware.com wrote: From: Roland Scheidegger srol...@vmware.com llvm goes crazy when doing that, using way more memory and time, though there's probably more to it - this points to a very much similar issue as fixed in 8a9f5ecdb116d0449d63f7b94efbfa8b205d826f

Re: [Mesa-dev] [PATCH 09/11] gallium: add support for arb_cull_distance

This doesn't really do what the commit message claims - it just adds a cap bit, not actual support for arb_cull_distance (which was already there), so the log should be changed accordingly. Apart from what was already mentioned (that is, the cap bit isn't used by st/mesa which instead mistakenly

Re: [Mesa-dev] [PATCH 00/11] TGSI support for input and output array declarations

Overall, this looks like a good idea to me. Probably needs some changes in our internal code but the idea is quite sane. Roland Am 24.05.2015 um 13:19 schrieb Marek Olšák: Hi, The reason I add this is that TGSI doesn't allow indirect indexing of inputs and outputs. Consider this: MOV

Re: [Mesa-dev] [PATCH 02/11] tgsi/scan: get more information about arrays and handle arrays correctly

Am 24.05.2015 um 13:19 schrieb Marek Olšák: From: Marek Olšák marek.ol...@amd.com --- src/gallium/auxiliary/tgsi/tgsi_scan.c | 11 +-- src/gallium/auxiliary/tgsi/tgsi_scan.h | 2 ++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git

Re: [Mesa-dev] Omission? mesa-10.5.6

This case wasn't dealing with floats, though. That said I guess it's a pointless discussion. If the compiler doesn't think it's a good idea I'll just add the parentheses just to shut it up... Roland Am 25.05.2015 um 21:19 schrieb Axel Davy: If one side is NaN, then !(x == y) is true, whereas x

Re: [Mesa-dev] Omission? mesa-10.5.6

I can't see what's wrong with the code. I thought not using parantheses there is quite common, is that some new warning from some super duper new compiler version? Roland Am 25.05.2015 um 02:46 schrieb Roger Brown: From mesa-10.5.6 compilation. Is this an oversight ? lp_query.c:

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

should probably be *4*4... oops. Yeah that works much better :) Thanks for the hint! On Mon, May 25, 2015 at 1:42 PM, Roland Scheidegger srol...@vmware.com wrote: The only thing I can think of is an illegal setup of the constant buffer, because the index was not verified before for direct

Re: [Mesa-dev] [PATCH 8/9] drisw: Enable flush control for llvmpipe and softpipe

On 05/19/2015 04:46 PM, Adam Jackson wrote: On Tue, 2015-05-12 at 23:34 +0200, Roland Scheidegger wrote: I like faster! I don't really understand though where the wins come from. softpipe can't have much pending work in the first place (maybe tile cache?), llvmpipe potentially has

Re: [Mesa-dev] [PATCH 5/7] util: Use SSE intrinsics in _mesa_lroundeven{f, }.

Am 01.08.2015 um 01:26 schrieb Matt Turner: gcc actually generates this for us now that we use -fno-math-errno (which is weird, since lrintf()/lrint() don't set errno) but clang still does not. Presumably helps MSVC as well. Reduced .text size by 8.5k with gcc before -fno-math-errno.

Re: [Mesa-dev] [PATCH 5/7] util: Use SSE intrinsics in _mesa_lroundeven{f, }.

Am 01.08.2015 um 02:44 schrieb Matt Turner: On Fri, Jul 31, 2015 at 4:41 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Fri, Jul 31, 2015 at 7:26 PM, Matt Turner matts...@gmail.com wrote: gcc actually generates this for us now that we use -fno-math-errno (which is weird, since lrintf()/lrint()

Re: [Mesa-dev] [PATCH 3/7] mesa: Replace F_TO_I() with _mesa_lroundevenf().

(double x) Is there any need for this one? In any case, Reviewed-by: Roland Scheidegger srol...@vmware.com +{ + return lrint(x); +} + +#endif ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo

Re: [Mesa-dev] [PATCH 5/7] util: Use SSE intrinsics in _mesa_lroundeven{f, }.

Am 01.08.2015 um 03:02 schrieb Matt Turner: On Fri, Jul 31, 2015 at 5:50 PM, Roland Scheidegger srol...@vmware.com wrote: Am 01.08.2015 um 01:26 schrieb Matt Turner: gcc actually generates this for us now that we use -fno-math-errno (which is weird, since lrintf()/lrint() don't set errno

Re: [Mesa-dev] [PATCH 7/7] mesa: Replace uses of IROUND{, 64} with libm functions.

I have some doubts of this. Given that IROUND was just plain incorrect, I think we should just use _mesa_lroundevenf() and see what happens. lroundf() is quite the shocker, my libm's implementation is totalling 40 instructions (!) for it (not counting the last return, vs 1 for lrintf). Now it's

Re: [Mesa-dev] [PATCH] gallium: add support for GLES texture float extensions

FWIW d3d10 has the same requirements, the any filter needs to be supported for half float formats, but is optional for float formats (d3d10.1 made it required for floats). https://msdn.microsoft.com/en-us/library/windows/desktop/cc627090%28v=vs.85%29.aspx So there might well be some more hw where

Re: [Mesa-dev] [PATCH] st/mesa: Map packed gallium formats to packed mesa formats.

Am 08.08.2015 um 22:45 schrieb Jason Ekstrand: Mesa formats and gallium formats are defined a bit differently. In mesa there are packed formats which are based on byte-order within a 8, 16, or 32-bit word and there are array formats which are simply an array of 8, 16, or 32-bit values. In

Re: [Mesa-dev] [PATCH] st/mesa: Map packed gallium formats to packed mesa formats.

Am 08.08.2015 um 23:26 schrieb Jason Ekstrand: On Sat, Aug 8, 2015 at 2:14 PM, Roland Scheidegger srol...@vmware.com wrote: Am 08.08.2015 um 22:45 schrieb Jason Ekstrand: Mesa formats and gallium formats are defined a bit differently. In mesa there are packed formats which are based on byte

Re: [Mesa-dev] [PATCH] gallium: add support for GLES texture float extensions (v2)

Makes sense. Reviewed-by: Roland Scheidegger srol...@vmware.com Am 12.08.2015 um 12:45 schrieb Marek Olšák: From: Marek Olšák marek.ol...@amd.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74329 v2: add a CAP for half floats drivers should not expose the CAPs

Re: [Mesa-dev] [PATCH 2/2] gallium/auxiliary: optimize rgb9e5 helper some more

Ping? Am 09.08.2015 um 17:28 schrieb srol...@vmware.com: From: Roland Scheidegger srol...@vmware.com I used this as some testing ground for investigating some compiler bits initially (e.g. lrint calls etc.), figured I could do much better in the end just for fun... This is mathematically

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

; + dbl_type.width *= 2; + lp_build_context_init(bld.bld_base.dbl_bld, gallivm, dbl_type); + } bld.mask = mask; bld.inputs = inputs; bld.outputs = outputs; Looks good to me. I'm not entirely happy with the build_gather, but it is fixable later, your choice. Reviewed-by: Roland

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 srol...@vmware.com wrote: Am 29.06.2015 um 22:18 schrieb Dave Airlie: On 30 June 2015 at 00:58, Roland Scheidegger srol...@vmware.com wrote: Don't worry about the AoS stuff. Only meant to do simple things

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 srol...@vmware.com 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 have native hw vector size

[Mesa-dev] IROUND, math errors, etc. (was: Re: proposed patch optimized F_TO_I for powerpc platforms)

CC mesa-dev. This looks good to me. I am starting to wonder though why we don't just use lrintf() and let the compiler sort it out (for x86 too). Though actually some quick experiments show that: - llvm's clang will always use libm lrintf call. Which then will do (x86_64) cvtss2si %xmm0,%rax as

Re: [Mesa-dev] [PATCH 5/7] util: Use SSE intrinsics in _mesa_lroundeven{f, }.

+#else return lrint(x); +#endif } #endif Reviewed-by: Roland Scheidegger srol...@vmware.com I'm wondering though if this is really exactly implementing lrintf why we're using a different name and not just something like _mesa_lrintf(). Though arguably _mesa_roundeven is the same

Re: [Mesa-dev] [PATCH] st/mesa: don't try to clear depth and stencil together in glClear fallback

I don't think that's quite true in general. For gpus which have combined ds buffers I can'see why you'd wanted to do separate clears for depth and stencil in this case (i.e. doing pipe-clear for depth, then draw a quad for clearing stencil). At least for simple hw like llvmpipe which don't have

Re: [Mesa-dev] [PATCH] st/mesa: don't try to clear depth and stencil together in glClear fallback

Actually, since the code says it can only happen with a non-full stencil mask, isn't clearing depth/stencil with a non-full stencil mask incredibly rare? Roland Am 31.07.2015 um 18:51 schrieb Roland Scheidegger: I don't think that's quite true in general. For gpus which have combined ds

Re: [Mesa-dev] [PATCH] st/mesa: don't try to clear depth and stencil together in glClear fallback

On Fri, Jul 31, 2015 at 7:44 PM, Roland Scheidegger srol...@vmware.com wrote: Actually, since the code says it can only happen with a non-full stencil mask, isn't clearing depth/stencil with a non-full stencil mask incredibly rare? Roland Am 31.07.2015 um 18:51 schrieb Roland Scheidegger: I

Re: [Mesa-dev] [PATCH] st/mesa: don't try to clear depth and stencil together in glClear fallback

thought this was hit more often, but apparently not. Nevermind. Marek On Fri, Jul 31, 2015 at 7:44 PM, Roland Scheidegger srol...@vmware.com wrote: Actually, since the code says it can only happen with a non-full stencil mask, isn't clearing depth/stencil with a non-full stencil mask

Re: [Mesa-dev] IROUND, math errors, etc.

Am 31.07.2015 um 18:44 schrieb Matt Turner: On Fri, Jul 31, 2015 at 7:13 AM, Roland Scheidegger srol...@vmware.com wrote: CC mesa-dev. This looks good to me. I am starting to wonder though why we don't just use lrintf() and let the compiler sort it out (for x86 too). Though actually some

Re: [Mesa-dev] [PATCH 2/7] mesa: Add -fno-trapping-math to CFLAGS.

# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 I'm wondering if we should add that to the scons build as well (both of these, of course). Reviewed-by: Roland Scheidegger srol...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http

Re: [Mesa-dev] [PATCH 1/2] mesa/formats: add some formats from GL3.3

Hmm I guess we can't convert it to something else when we don't have a matching MESA_FORMAT? Roland Am 30.07.2015 um 03:48 schrieb Dave Airlie: From: Dave Airlie airl...@redhat.com GL3.3 added GL_ARB_texture_rgb10_a2ui, which specifies a lot more things than just rgb10/a2ui. While

Re: [Mesa-dev] [PATCH 1/4] gallium: add an interface for EXT_depth_bounds_test

I guess the question is if those depth bounds floats should be in the dsa state or set separately. That would mostly depend on if you expect frequent changes to the values or not, at least that's the pattern usually followed. Either way though looks ok to me. Reviewed-by: Roland Scheidegger srol

Re: [Mesa-dev] [PATCH] mesa/format_utils: Add src_bits == dst_bits cases to [us]norm functions

- 1, dst_bits - 1); - else + else if (src_bits dst_bits) return x (src_bits - dst_bits); + else + return x; } static inline unsigned Reviewed-by: Roland Scheidegger srol...@vmware.com (I don't care either way for the snorm case). Roland

Re: [Mesa-dev] [PATCH 3/3] util: Use SSE rounding on all platforms that support it.

Am 09.08.2015 um 18:47 schrieb Matt Turner: On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca jfons...@vmware.com wrote: As currently only GCC x86_64 builds where using it. --- src/util/rounding.h | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git

Re: [Mesa-dev] [PATCH 1/3] util: Cope with LONG_BIT not being defined on Windows.

LONG_BIT #endif #else return lrint(x); For the series: Reviewed-by: Roland Scheidegger srol...@vmware.co ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] util: Use SSE rounding on all platforms that support it.

Forgot to mention, strictly speaking only __SSE__ is necessary for _mesa_lroundevenf, so it would work on these shiny Pentium 3 and Athlon XP... The double version (though it's unused) however requires __SSE2__. Roland Am 09.08.2015 um 19:23 schrieb Roland Scheidegger: Am 09.08.2015 um 18:47

Re: [Mesa-dev] [PATCH] util: Use LONG_MAX instead of LONG_BIT.

Looks good to me. Would have been much less trouble if we'd just returned an int, to hell with lrintf's long return type no callers will care about the long returned anyway... Reviewed-by: Roland Scheidegger srol...@vmware.com Am 09.08.2015 um 23:40 schrieb Jose Fonseca: More portable. Based

Re: [Mesa-dev] [PATCH 1/3] util: Cope with LONG_BIT not being defined on Windows.

Am 09.08.2015 um 20:08 schrieb Jose Fonseca: On 09/08/15 17:47, Matt Turner wrote: On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca jfons...@vmware.com wrote: Neither MSVC nor MinGW defines LONG_BIT. For MSVC this was not a problem as it doesn't define __x86_64__ macro (it's GCC specific.)

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

I guess though you'd need these bits when implementing things like ARB_fragment_shader_ordering? (Thus stuff actually looks useful but I don't know if anybody wants to implement it in the near term.) Roland Am 14.08.2015 um 18:27 schrieb Francisco Jerez: The hardware documentation relating to

Re: [Mesa-dev] [PATCH] scons: Always define __STDC_LIMIT_MACROS.

I'm hardly a build expert, but looks good to me. Reviewed-by: Roland Scheidegger srol...@vmware.com Am 15.08.2015 um 00:22 schrieb Vinson Lee: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91591 Signed-off-by: Vinson Lee v...@freedesktop.org --- scons/gallium.py | 1 + 1 file

Re: [Mesa-dev] [PATCH] st/mesa: Map packed gallium formats to packed mesa formats.

Am 09.08.2015 um 12:11 schrieb Oded Gabbay: On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand ja...@jlekstrand.net wrote: On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay oded.gab...@gmail.com wrote: On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand ja...@jlekstrand.net wrote: If I understand your

Re: [Mesa-dev] [PATCH] st/mesa: Map packed gallium formats to packed mesa formats.

Am 10.08.2015 um 07:00 schrieb Jason Ekstrand: On Sun, Aug 9, 2015 at 6:46 AM, Roland Scheidegger srol...@vmware.com wrote: Am 09.08.2015 um 12:11 schrieb Oded Gabbay: On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand ja...@jlekstrand.net wrote: On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay

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 srol...@vmware.com 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

Re: [Mesa-dev] ARB_copy_image support in Gallium

implementation. The only case where resource_copy_region must be used is copying compressed textures. Marek On Mon, Jul 20, 2015 at 9:56 PM, Roland Scheidegger srol...@vmware.com wrote: Theoretically resource_copy_region should be the right function for that. Both ARB_copy_image

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

, and for the rest of the series, Reviewed-by: Roland Scheidegger srol...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 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

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 srol...@vmware.com In particular, we were incorrectly accepting s3tc (and lots of others) for CompressedTexSubImage3D (but not CompressedTexImage3D) calls with 3d targets

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 ito...@igalia.com On Mon, 2015-07-13 at 16:22 -0700, Matt Turner wrote: ---

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, srol...@vmware.com 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) { +/*

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 bri...@vmware.com wrote: This adds the new glGetTextureSubImage() and glGetCompressedTextureSubImage() functions. Also update the dispatch sanity test program. v2: remove stray brace, move xi:include

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 srol...@vmware.com 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(). Upon

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 srol...@vmware.com 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 of exp2, exp2f, powf are c99

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 matts...@gmail.com wrote: On Mon, Jul 13, 2015 at 5:13 PM, Roland Scheidegger srol...@vmware.com wrote: Did you replace 2 of them by exp2f but one by exp2f on purpose? I don't think we can use exp2

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 srol...@vmware.com In particular, we were incorrectly accepting s3tc (and lots of others) for CompressedTexSubImage3D (but not CompressedTexImage3D) calls with 3d targets

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] 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 3/3] gallivm: Initialize LLVM Modules's DataLayout to an empty string.

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 srol...@vmware.com --- src/gallium

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

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 srol...@vmware.com wrote: Am 20.07.2015 um 22:46 schrieb Ilia Mirkin: On Mon, Jul 20, 2015 at 3:53 PM, Brian Paul bri...@vmware.com wrote: On 07/20/2015 01:19 PM, Ilia Mirkin wrote: On Mon, Jul

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 bri...@vmware.com wrote: On 07/20/2015 01:19 PM, Ilia Mirkin wrote: On Mon, Jul 20, 2015 at 2:44 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Hi Brian, You marked off ARB_copy_image (and

Re: [Mesa-dev] [PATCH 7/9] softpipe: don't use 3-component formats

Am 25.08.2015 um 01:08 schrieb Ilia Mirkin: On Mon, Aug 24, 2015 at 7:04 PM, Brian Paul bri...@vmware.com wrote: Mesa and gallium don't have a complete set of matching 3-component texture formats. For example, 8-bit sRGB unorm. To fully support the GL_ARB_copy_image extension we need to have

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

Thanks for fixing this up. Reviewed-by: Roland Scheidegger <srol...@vmware.com> 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/mes

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

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

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 <srol...@vmware.com> > wrote: >> Am 29.10.2015 um 12:27 schrieb Oded Gabbay: >>> Hi Roland, Jose >>> >>> I wanted to bring a problem I found to your

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 <srol...@vmware.com> > wrote: >> Am 29.10.2015 um 20:10 schrieb Oded Gabbay: >>> On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>&

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

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

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 <srol...@vmware.com> >> >> f16c intrinsic can only be emitted when AVX is used. So when we >> disable AVX >> due to forcing 128bit

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 <srol...@vmware.com> >>>>

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 <srol...@vmware.com> 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 c

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 <srol...@vmware.com> wrote: >> >> Certainly looks interesting... >> From a high level point of view, seems quite similar to llvmpipe (both >> til

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 <srol...@vmware.com> > > Am 21.10.2015 um 18:25 schrieb Jose Fonseca: >> This should prevent disp

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

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