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 pro

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 > 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) but clang s

Re: [Mesa-dev] [PATCH] r600: Remove assert that not general in some stream instr's

On 1 Aug 2015 10:53 am, "Edward O'Callaghan" wrote: > > Ah, oh! I see, yes I was trying to work out how to polish off GL4 for > r600 too. > > Alright, I guess you have my review on that part then :p is moving > VGT_STRMOUT_BUFFER_CONFIG the only part of those patches that needs to > be fixed up be

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

On Fri, Jul 31, 2015 at 5:50 PM, Roland Scheidegger 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) but clang still >> does not. Presumably helps MSVC as well. >>

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 wrote: >> On Fri, Jul 31, 2015 at 7:26 PM, Matt Turner wrote: >>> 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 st

Re: [Mesa-dev] [PATCH] r600: Remove assert that not general in some stream instr's

Ah, oh! I see, yes I was trying to work out how to polish off GL4 for r600 too. Alright, I guess you have my review on that part then :p is moving VGT_STRMOUT_BUFFER_CONFIG the only part of those patches that needs to be fixed up before they can be merged? Cheers, Edward. -- Edward O'Callagha

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 3/7] mesa: Replace F_TO_I() with _mesa_lroundevenf().

I think that just means "depends on currently set rounding mode". But well if someone calls into mesa code with different set rounding mode we have a lot more problems... Am 01.08.2015 um 01:26 schrieb Matt Turner: > I'm not sure what the true meaning of "The rounding mode may vary." is, > but it

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

On Fri, Jul 31, 2015 at 4:41 PM, Ilia Mirkin wrote: > On Fri, Jul 31, 2015 at 7:26 PM, Matt Turner wrote: >> 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. >

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

Am 01.08.2015 um 01:26 schrieb Matt Turner: > Cuts about 1k of .text size. > >textdata bss dec hex filename > 4983676 197808 26328 5207812 4f7704 i965_dri.so before > 4982522 197800 26328 5206650 4f727a i965_dri.so after > --- > configure.ac | 4 ++-- > 1 file changed,

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

On Fri, Jul 31, 2015 at 7:26 PM, Matt Turner wrote: > 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-er

[Mesa-dev] [PATCH 6/7] glx: Use _mesa_lroundevenf() in glPixelStoref().

Functional change in which way half-way cases are rounded from towards positive-infinity to even. The spec says "the passed value is rounded to the nearest integer". Removes another case of bad half-up rounding. --- src/glx/pixelstore.c | 25 + 1 file changed, 13 insertions

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

Cuts about 1k of .text size. textdata bss dec hex filename 4983676 197808 26328 5207812 4f7704 i965_dri.so before 4982522 197800 26328 5206650 4f727a i965_dri.so after --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac

[Mesa-dev] [PATCH 4/7] mesa: Use _mesa_lroundevenf() in some more places.

--- src/glsl/ir_constant_expression.cpp | 14 -- src/mesa/main/imports.c | 4 ++-- 2 files changed, 6 insertions(+), 12 deletions(-) diff --git a/src/glsl/ir_constant_expression.cpp b/src/glsl/ir_constant_expression.cpp index 2853c16..309b6b7 100644 --- a/src/glsl/ir_con

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

lroundf is the most common replacement. I replaced uses of IROUND() where there was a comment saying "rounded to nearest integer" with _mesa_lroundevenf. IROUND64 is replaced with llroundf. --- src/mesa/main/drawpix.c | 21 +++-- src/mesa/main/eval.c| 14 ++

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

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. text data bss dec hex filename 49

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

I'm not sure what the true meaning of "The rounding mode may vary." is, but it is the case that the IROUND() path rounds differently than the other paths (and does it wrong, at that). Like _mesa_roundeven{f,}(), just add an use _mesa_lroundeven{f,}() that has known semantics. --- src/mesa/main/fo

[Mesa-dev] [PATCH 1/7] mesa: Add -fno-math-errno to CFLAGS.

Cuts about 9k of .text size. textdata bss dec hex filename 4992804 197808 26328 5216940 4f9aac i965_dri.so before 4983676 197808 26328 5207812 4f7704 i965_dri.so after Also, Darwin's libm does not ever set errno, so if we care about those systems we shouldn't rely on er

[Mesa-dev] RadeonSI 10.6 candidates

Hi Emil, I'm nominating the attached patches for 10.6. They are quite big, but they fix a lot of graphical corruption on SI cards, especially in games from Valve (Portal, CS:GO, etc). I've checked with piglit that there are no regressions. There was a comment on Phoronix forums that this might fi

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

Not really. Those two don't use the current framebuffer state, which makes them not nice to drivers. The only difference for us would be that radeonsi wouldn't have to touch and restore some states, and I think the depth could be cleared fast if the scissor was aligned to 8x8. Marek On Fri, Jul

Re: [Mesa-dev] List of unsupported extensions per driver

OK, I believe I've fixed my list up. Note that you may have to shift-reload to get the updates, I think fd.o isn't setting the proper cache headers or something else is messed up. On Wed, Jul 29, 2015 at 5:50 PM, Marek Olšák wrote: > R600/R700 can also do: > - ARB_conditional_render_inverted > -

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

You could use pipe clear_render_target and clear_depth_stencil for that. Roland Am 31.07.2015 um 22:00 schrieb Marek Olšák: > I wouldn't mind moving scissored clears to drivers. u_blitter can do > it in the same way after the support is added and drivers will have > more control over the states a

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

Unless that person sticks it behind a pipe cap :) Which is how *this* person was planning on doing it... nouveau doesn't use u_blitter by the way. -ilia On Fri, Jul 31, 2015 at 4:00 PM, Marek Olšák wrote: > I wouldn't mind moving scissored clears to drivers. u_blitter can do > it in the same w

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

I wouldn't mind moving scissored clears to drivers. u_blitter can do it in the same way after the support is added and drivers will have more control over the states and how they are saved and restored. The catch is the person who will do that will also have to fix it for all drivers. Marek On Fr

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

Though arguably because it should be so rare, it shouldn't really matter much if it is removed neither for these drivers which want that... Roland Am 31.07.2015 um 20:30 schrieb Marek Olšák: > Indeed, it is rare. I thought this was hit more often, but apparently > not. Nevermind. > > Marek > >

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

Don't know the situation on other hardware, but at least nvidia supports both scissors and stencil for its "fast" clear (it's fast at least in terms of the number of commands submitted and lack of state changes, no comment on actual execution speed). I was thinking of adding a few caps for it. On

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

Indeed, it is rare. I thought this was hit more often, but apparently not. Nevermind. Marek On Fri, Jul 31, 2015 at 7:44 PM, Roland Scheidegger 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 > in

Re: [Mesa-dev] [PATCH 4/4] i965/es3.1: Implement glMemoryBarrierByRegion

On Fri, Jul 31, 2015 at 10:25 AM, Ilia Mirkin wrote: > On Fri, Jul 31, 2015 at 8:15 AM, Marta Lofstedt > wrote: >> From: Marta Lofstedt >> >> Signed-off-by: Marta Lofstedt >> --- >> src/mesa/drivers/dri/i965/brw_program.c | 34 >> + >> 1 file changed, 34 insert

[Mesa-dev] [PATCH] i965/cs: Setup push constant data for uniforms

brw_upload_cs_push_constants was based on gen6_upload_push_constants. v2: * Add FINISHME comments about more efficient ways to push uniforms Signed-off-by: Jordan Justen Cc: Ben Widawsky --- Ben, Regarding your v1 feedback: * I looked into the other mechanisms for uploading uniform data onc

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 buffe

Re: [Mesa-dev] [PATCH 4/4] i965/es3.1: Implement glMemoryBarrierByRegion

On Fri, Jul 31, 2015 at 8:15 AM, Marta Lofstedt wrote: > From: Marta Lofstedt > > Signed-off-by: Marta Lofstedt > --- > src/mesa/drivers/dri/i965/brw_program.c | 34 > + > 1 file changed, 34 insertions(+) > > diff --git a/src/mesa/drivers/dri/i965/brw_program.c

Re: [Mesa-dev] [PATCH 1/4] gles/es3.1: Enable dispatch of glMemoryBarrierByRegion

On Fri, Jul 31, 2015 at 9:57 AM, Ilia Mirkin wrote: > Won't this cause a compilation failure in mesa? I thought it'd start > looking for the _mesa_MemoryBarrierByRegion function. Normally this is > added as a stub in the first commit, and then the real impl comes > later. Yeah, that's probably tr

Re: [Mesa-dev] [PATCH 4/4] i965/es3.1: Implement glMemoryBarrierByRegion

On Fri, Jul 31, 2015 at 5:15 AM, Marta Lofstedt wrote: > From: Marta Lofstedt > > Signed-off-by: Marta Lofstedt > --- > src/mesa/drivers/dri/i965/brw_program.c | 34 > + > 1 file changed, 34 insertions(+) > > diff --git a/src/mesa/drivers/dri/i965/brw_program.c

[Mesa-dev] [PATCH 1/2 v1.1] clover: make dispatch matches functions def

--- src/gallium/state_trackers/clover/api/dispatch.hpp | 23 +- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp b/src/gallium/state_trackers/clover/api/dispatch.hpp index ffae1ae..781b54e 100644 --- a/src/galliu

[Mesa-dev] [PATCH 2/5] ra: Delete the conflict lists in ra_set_finalize

They are never used after the set is finalized so there's no reason to keep them around. --- src/util/register_allocate.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c index 129d58d..436e008 100644 --- a/src/util/register_alloc

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

[Mesa-dev] [PATCH 4/5] i965/fs: Use dispatch_width instead of reg_width in alloc_reg_sets

reg_width is kind of an outdated concept. --- src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp index 6a7ed64.

[Mesa-dev] [PATCH 5/5] i965/fs: Don't do redundant RA setup on IVB+

--- src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 9 + 1 file changed, 9 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp index 211f70e..512da22 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocat

[Mesa-dev] [PATCH 2/5] ra: Delete the conflict lists in ra_set_finalize

I'm not 100% sure that this is the right patch. Instead of baking 256 into the allocator, we could allow the user to pass in an initial constant. Since the maximum is statically known, we could also make said constant a hard limit and allocate everything up-front in a single array and save all the

[Mesa-dev] [PATCH 1/5] ra: Refactor ra_set_finalize

All this commit does is change an early return to an if with an else clause. --- src/util/register_allocate.c | 51 ++-- 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c index 95be20f

[Mesa-dev] [PATCH 0/5] Some register allocation improvements

The following 5 patches contain a few register allocation cleanups and performance improvements. Chris Wilson noticed that setting up register sets on i965 calls reralloc an absurd number of times. I did a little hacking and found out that the initial size for the collision lists is way too low.

Re: [Mesa-dev] [PATCH 10/20] i965/fs: Implement image load, store and atomic.

Jason Ekstrand writes: > On Fri, Jul 31, 2015 at 6:15 AM, Francisco Jerez > wrote: >> Jason Ekstrand writes: >> >>> On Thu, Jul 23, 2015 at 4:38 AM, Francisco Jerez >>> wrote: Jason Ekstrand writes: > This all looks correct as far as I can tell. However, I'm very > concer

Re: [Mesa-dev] [PATCH 1/4] gles/es3.1: Enable dispatch of glMemoryBarrierByRegion

Won't this cause a compilation failure in mesa? I thought it'd start looking for the _mesa_MemoryBarrierByRegion function. Normally this is added as a stub in the first commit, and then the real impl comes later. On Fri, Jul 31, 2015 at 8:15 AM, Marta Lofstedt wrote: > From: Marta Lofstedt > > S

Re: [Mesa-dev] [PATCH 0/4] Implementation of glMemoryBarrierByRegion

On Fri, Jul 31, 2015 at 5:15 AM, Marta Lofstedt wrote: > This provides an i965 implementation of the > OpenGL ES 3.1 needed function, glMemoryBarrierByRegion. > > Marta Lofstedt (4): > gles/es3.1: Enable dispatch of glMemoryBarrierByRegion > mesa/es3.1: Add driver interface for glMemoryBarrier

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] IROUND, math errors, etc. (was: Re: proposed patch optimized F_TO_I for powerpc platforms)

On Fri, Jul 31, 2015 at 7:13 AM, Roland Scheidegger 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 quick experiments show that: > - llvm's clang will always use

Re: [Mesa-dev] [PATCH 14/18] util/register_allocate: Compute transitive conflicts using 2-passes

On Fri, Jul 31, 2015 at 9:38 AM, Chris Wilson wrote: > On Fri, Jul 31, 2015 at 09:30:36AM -0700, Jason Ekstrand wrote: >> This patch looks really sketchy to me. First, you fundamentally >> changed some of register_allocate's internal data structures with no >> explanation as to what the change is

Re: [Mesa-dev] [PATCH 14/18] util/register_allocate: Compute transitive conflicts using 2-passes

On Fri, Jul 31, 2015 at 09:30:36AM -0700, Jason Ekstrand wrote: > This patch looks really sketchy to me. First, you fundamentally > changed some of register_allocate's internal data structures with no > explanation as to what the change is and why it still works. Maybe > the difference should be

Re: [Mesa-dev] [PATCH 14/18] util/register_allocate: Compute transitive conflicts using 2-passes

This patch looks really sketchy to me. First, you fundamentally changed some of register_allocate's internal data structures with no explanation as to what the change is and why it still works. Maybe the difference should be obvious to me, but it isn't. Second, it appears that your changes assum

[Mesa-dev] [PATCH] gallium/radeon: always use the llvm. prefix in intrinsic names

From: Marek Olšák --- .../drivers/radeon/radeon_setup_tgsi_llvm.c| 24 +++--- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c index 5c08cf5..ac645b7 1

[Mesa-dev] [PATCH] glx: Fix __glXWireToEvent for BufferSwapComplete

In the DRI2 path this event is magically synthesized from the corresponding DRI2 event, but with Present, the server sends us the event itself. The DRI2 path fills in the serial number, send_event, and display fields of the XEvent struct that the app sees, but the Present path did not. This is lik

Re: [Mesa-dev] [PATCH 08/18] radeonsi: don't use llvm.AMDIL.fraction for FRC and DFRAC

On Fri, Jul 31, 2015 at 5:13 PM, Tom Stellard wrote: > On Fri, Jul 31, 2015 at 04:59:19PM +0200, Marek Olšák wrote: >> On Fri, Jul 31, 2015 at 4:18 PM, Tom Stellard wrote: >> > On Tue, Jul 28, 2015 at 12:05:43PM +0200, Marek Olšák wrote: >> >> From: Marek Olšák >> >> >> >> There are 2 reasons fo

[Mesa-dev] [PATCH 2/2] radeon/winsys: increase the IB size for VM

From: Marek Olšák Luckily, there is a kernel query, so use the size from that. It currently returns 256KB. It can be increased in the kernel. --- src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 8 +++- src/gallium/winsys/radeon/drm/radeon_drm_cs.h | 2 +- src/gallium/winsys/radeon/

[Mesa-dev] [PATCH 1/2] gallium/radeon: allow the winsys to choose the IB size

From: Marek Olšák Picked from the amdgpu branch. Reviewed-by: Alex Deucher --- src/gallium/drivers/r300/r300_blit.c | 2 +- src/gallium/drivers/r300/r300_cs.h| 2 +- src/gallium/drivers/r300/r300_render.c| 2 +- src/gallium/drivers/r600/r600_hw_context.c| 2 +-

[Mesa-dev] [PATCH] gallium/radeon: suspend timer queries between IBs

From: Marek Olšák When we are measuring the time spent in a draw call, an unexpected flush can distort the result. --- src/gallium/drivers/r600/r600_hw_context.c| 3 +- src/gallium/drivers/radeon/r600_pipe_common.c | 8 ++-- src/gallium/drivers/radeon/r600_pipe_common.h | 9 +++- src/gall

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

From: Marek Olšák A lot of GPUs allocate separate depth and stencil buffers, so clearing them together doesn't make much sense. If some GPUs don't allocate separate depth & stencil, it's still beneficial to clear the HiZ / HiS information for only one of the two. --- src/mesa/state_tracker/st_cb

Re: [Mesa-dev] [PATCH 08/18] radeonsi: don't use llvm.AMDIL.fraction for FRC and DFRAC

On Fri, Jul 31, 2015 at 04:59:19PM +0200, Marek Olšák wrote: > On Fri, Jul 31, 2015 at 4:18 PM, Tom Stellard wrote: > > On Tue, Jul 28, 2015 at 12:05:43PM +0200, Marek Olšák wrote: > >> From: Marek Olšák > >> > >> There are 2 reasons for this: > >> - LLVM optimization passes can work with floor >

Re: [Mesa-dev] [PATCH 08/18] radeonsi: don't use llvm.AMDIL.fraction for FRC and DFRAC

On Fri, Jul 31, 2015 at 4:18 PM, Tom Stellard wrote: > On Tue, Jul 28, 2015 at 12:05:43PM +0200, Marek Olšák wrote: >> From: Marek Olšák >> >> There are 2 reasons for this: >> - LLVM optimization passes can work with floor >> - there are patterns to select v_fract from floor anyway >> >> There is

Re: [Mesa-dev] [PATCH 10/20] i965/fs: Implement image load, store and atomic.

On Fri, Jul 31, 2015 at 6:15 AM, Francisco Jerez wrote: > Jason Ekstrand writes: > >> On Thu, Jul 23, 2015 at 4:38 AM, Francisco Jerez >> wrote: >>> Jason Ekstrand writes: >>> This all looks correct as far as I can tell. However, I'm very concerned about the number of checks such as

Re: [Mesa-dev] [PATCH 08/18] radeonsi: don't use llvm.AMDIL.fraction for FRC and DFRAC

On Tue, Jul 28, 2015 at 12:05:43PM +0200, Marek Olšák wrote: > From: Marek Olšák > > There are 2 reasons for this: > - LLVM optimization passes can work with floor > - there are patterns to select v_fract from floor anyway > > There is no change in the generated code. > --- > src/gallium/driver

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

Re: [Mesa-dev] [PATCH] clover: handle setKernelArg errors

Zoltán Gilián writes: > Could you please commit this? I don't have permissions. > Sure, I'll put them into my queue. > On Fri, Jul 31, 2015 at 3:55 PM, Francisco Jerez > wrote: >> Zoltan Gilian writes: >> >>> --- >>> src/gallium/state_trackers/clover/core/kernel.cpp | 15 +++ >>>

Re: [Mesa-dev] [PATCH 1/2] clover: make dispatch matches functions def

EdB writes: > --- > src/gallium/state_trackers/clover/api/dispatch.hpp | 23 > +- > 1 file changed, 18 insertions(+), 5 deletions(-) > > diff --git a/src/gallium/state_trackers/clover/api/dispatch.hpp > b/src/gallium/state_trackers/clover/api/dispatch.hpp > index ffae1ae..7

Re: [Mesa-dev] [PATCH 2/2] clover: pass image attributes to the kernel

Could you please commit this? On Mon, Jul 27, 2015 at 1:28 PM, Francisco Jerez wrote: > Zoltan Gilian writes: > >> Read-only and write-only image arguments are recognized and >> distinguished. >> Attributes of the image arguments are passed to the kernel as implicit >> arguments. >> --- >> src/

Re: [Mesa-dev] [PATCH 1/2] clover: move find_kernels to functions

Could you please commit this? On Mon, Jul 27, 2015 at 1:20 PM, Francisco Jerez wrote: > Zoltan Gilian writes: > >> --- >> .../state_trackers/clover/llvm/invocation.cpp | 28 >> -- >> 1 file changed, 15 insertions(+), 13 deletions(-) >> >> diff --git a/src/gallium/state

Re: [Mesa-dev] [PATCH] clover: handle setKernelArg errors

Could you please commit this? I don't have permissions. On Fri, Jul 31, 2015 at 3:55 PM, Francisco Jerez wrote: > Zoltan Gilian writes: > >> --- >> src/gallium/state_trackers/clover/core/kernel.cpp | 15 +++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/src/gallium/state_tr

Re: [Mesa-dev] [PATCH] clover: handle setKernelArg errors

Zoltan Gilian writes: > --- > src/gallium/state_trackers/clover/core/kernel.cpp | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp > b/src/gallium/state_trackers/clover/core/kernel.cpp > index a23cd2b..820a80a 100644 > ---

Re: [Mesa-dev] [PATCH] i965/fs: Fix regression with SIMD8 VS since b5f1a48e234d47b24df38cb562cffb8941d43795.

"Lofstedt, Marta" writes: > Well, I could try, but I don't believe I have enough cred yet, to make any > difference. > > Reviewed-by: "Lofstedt, Marta" > It's a fine R-b, and this seems important enough that we wouldn't want to delay the fix any further, I'll push it shortly. :) >> -Origin

Re: [Mesa-dev] [Mesa-dev, 1/9] mesa/es3.1: Allow binding GL_DRAW_INDIRECT_BUFFER with gles 3.1

Thanks Tapani, However, For patch 9 there is a V3 for which I can't see any new objections: http://patchwork.freedesktop.org/patch/51879/ If you have any new ones could you please clarify. My interpretation of the comments on patch 6, is that it was OK as it is. Please clarify if you don't ag

Re: [Mesa-dev] [PATCH 10/20] i965/fs: Implement image load, store and atomic.

Jason Ekstrand writes: > On Thu, Jul 23, 2015 at 4:38 AM, Francisco Jerez > wrote: >> Jason Ekstrand writes: >> >>> This all looks correct as far as I can tell. However, I'm very >>> concerned about the number of checks such as >>> has_matching_typed_format() that are built-in to the compiler

Re: [Mesa-dev] [PATCH 1/3] egl/x11: fix use of EGL_BAD_NATIVE_WINDOW

On 31/07/15 12:53, Emil Velikov wrote: > On 31 July 2015 at 11:02, Frank Binns wrote: >> Commit 4ed23fd590 introduced some calls to _eglError inappropriately >> passing it EGL_BAD_NATIVE_WINDOW. This was actually harmless in two of the >> cases as _eglError gets called later on with a more appro

Re: [Mesa-dev] [PATCH] i965/fs: Fix regression with SIMD8 VS since b5f1a48e234d47b24df38cb562cffb8941d43795.

Well, I could try, but I don't believe I have enough cred yet, to make any difference. Reviewed-by: "Lofstedt, Marta" > -Original Message- > From: Francisco Jerez [mailto:curroje...@riseup.net] > Sent: Friday, July 31, 2015 2:07 PM > To: Lofstedt, Marta; mesa-dev@lists.freedesktop.org >

Re: [Mesa-dev] i965 implementation of the ARB_shader_image_load_store built-ins. (v4)

Jason Ekstrand writes: > Curro, > What are we still wainting on for the image_load_store extension? I > think I've given you R-B's on all but one or two of the compiler > patches. Is the state setup stuff reviewed? Is there anything else > that needs review? I've made a list of the patches st

[Mesa-dev] [PATCH 0/4] Implementation of glMemoryBarrierByRegion

This provides an i965 implementation of the OpenGL ES 3.1 needed function, glMemoryBarrierByRegion. Marta Lofstedt (4): gles/es3.1: Enable dispatch of glMemoryBarrierByRegion mesa/es3.1: Add driver interface for glMemoryBarrierByRegion mesa/es3.1: Implement the entry point of MemoryBarrierBy

[Mesa-dev] [PATCH 3/4] mesa/es3.1: Implement the entry point of MemoryBarrierByRegion

From: Marta Lofstedt Signed-off-by: Marta Lofstedt --- src/mesa/main/shaderimage.c | 9 + src/mesa/main/shaderimage.h | 3 +++ 2 files changed, 12 insertions(+) diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c index a348cdb..be66a6c 100644 --- a/src/mesa/main/shad

[Mesa-dev] [PATCH 4/4] i965/es3.1: Implement glMemoryBarrierByRegion

From: Marta Lofstedt Signed-off-by: Marta Lofstedt --- src/mesa/drivers/dri/i965/brw_program.c | 34 + 1 file changed, 34 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_program.c b/src/mesa/drivers/dri/i965/brw_program.c index 85e271d..332d84e 100644

[Mesa-dev] [PATCH 2/4] mesa/es3.1: Add driver interface for glMemoryBarrierByRegion

From: Marta Lofstedt Signed-off-by: Marta Lofstedt --- src/mesa/main/dd.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h index 87eb63e..4b41141 100644 --- a/src/mesa/main/dd.h +++ b/src/mesa/main/dd.h @@ -1017,6 +1017,13 @@ struct dd_function_

[Mesa-dev] [PATCH 1/4] gles/es3.1: Enable dispatch of glMemoryBarrierByRegion

From: Marta Lofstedt Signed-off-by: Marta Lofstedt --- src/mapi/glapi/gen/gl_API.xml | 4 src/mesa/main/tests/dispatch_sanity.cpp | 3 +-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml index 658efa4..3

Re: [Mesa-dev] [PATCH] i965/fs: Fix regression with SIMD8 VS since b5f1a48e234d47b24df38cb562cffb8941d43795.

"Lofstedt, Marta" writes: > In hope of speeding up the review and merge of this bug fix, > I confirm that below patch fix the regression I have had from: > "b5f1a48e234d47b24df38cb562cffb8941d43795" on Gen8. > Wouldn't you feel like reviewing it yourself? :) > /Marta > >> -Original Message-

Re: [Mesa-dev] [PATCH 1/3] egl/x11: fix use of EGL_BAD_NATIVE_WINDOW

On 31 July 2015 at 11:02, Frank Binns wrote: > Commit 4ed23fd590 introduced some calls to _eglError inappropriately > passing it EGL_BAD_NATIVE_WINDOW. This was actually harmless in two of the > cases as _eglError gets called later on with a more appropriate error code > but (just to be safe) swit

Re: [Mesa-dev] [PATCH v2 3/6] i965/vec4: Don't emit scratch reads for a spilled register we have just written

On Fri, 2015-07-31 at 13:12 +0300, Francisco Jerez wrote: > Iago Toral writes: > > > On Thu, 2015-07-30 at 17:08 +0300, Francisco Jerez wrote: > >> Iago Toral Quiroga writes: > >> > >> > When we have code such as this: > >> > > >> > mov vgrf1.0.x:F, vgrf2.:F > >> > mov vgrf3.0.x:F, vgrf1.xx

Re: [Mesa-dev] [PATCH v2 3/6] i965/vec4: Don't emit scratch reads for a spilled register we have just written

Francisco Jerez writes: > Iago Toral writes: > >> On Thu, 2015-07-30 at 17:08 +0300, Francisco Jerez wrote: >>> Iago Toral Quiroga writes: >>> >>> > When we have code such as this: >>> > >>> > mov vgrf1.0.x:F, vgrf2.:F >>> > mov vgrf3.0.x:F, vgrf1.:F >>> > ... >>> > mov vgrf3.0.x:F, vg

Re: [Mesa-dev] [PATCH v2 3/6] i965/vec4: Don't emit scratch reads for a spilled register we have just written

Iago Toral writes: > On Thu, 2015-07-30 at 17:14 +0300, Francisco Jerez wrote: >> Francisco Jerez writes: >> >> > Iago Toral Quiroga writes: >> > >> >> When we have code such as this: >> >> >> >> mov vgrf1.0.x:F, vgrf2.:F >> >> mov vgrf3.0.x:F, vgrf1.:F >> >> ... >> >> mov vgrf3.0.x:F,

Re: [Mesa-dev] [PATCH v2 3/6] i965/vec4: Don't emit scratch reads for a spilled register we have just written

Iago Toral writes: > On Thu, 2015-07-30 at 17:08 +0300, Francisco Jerez wrote: >> Iago Toral Quiroga writes: >> >> > When we have code such as this: >> > >> > mov vgrf1.0.x:F, vgrf2.:F >> > mov vgrf3.0.x:F, vgrf1.:F >> > ... >> > mov vgrf3.0.x:F, vgrf1.:F >> > >> > And vgrf1 is chos

Re: [Mesa-dev] [PATCH] r600, compute: force tiling on 2D and 3D texture compute resources

Reviewed-by: Marek Olšák Marek On Fri, Jul 31, 2015 at 11:59 AM, Zoltan Gilian wrote: > To circumvent a problem occuring when LINEAR_ALIGNED array mode is > selected on a TEXTURE_2D RAT. > This configuration causes MEM_RAT STORE_TYPED to write to incorrect > locations. > --- > src/gallium/driv

Re: [Mesa-dev] [PATCH 18/18] r600g: early exist in r600_clear if there's nothing to do

On 28.07.2015 19:05, Marek Olšák wrote: > From: Marek Olšák > > --- > src/gallium/drivers/r600/r600_blit.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/gallium/drivers/r600/r600_blit.c > b/src/gallium/drivers/r600/r600_blit.c > index 8e553a8..1c59230 100644 > --- a/src/galliu

Re: [Mesa-dev] [PATCH 17/18] radeonsi: early exist in si_clear if there's nothing to do

On 28.07.2015 19:05, Marek Olšák wrote: > From: Marek Olšák > > --- > src/gallium/drivers/radeonsi/si_blit.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/gallium/drivers/radeonsi/si_blit.c > b/src/gallium/drivers/radeonsi/si_blit.c > index c3591a7..c892623 100644 > --- a/src/

Re: [Mesa-dev] [PATCH 14/18] radeonsi: move CP DMA functions to their own file

On 28.07.2015 19:05, Marek Olšák wrote: > From: Marek Olšák Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev

Re: [Mesa-dev] [PATCH 16/18] radeonsi: fix a regression since the resource_copy_region cleanup

On 28.07.2015 19:05, Marek Olšák wrote: > From: Marek Olšák > > Broken since: > 46b2b3b - radeonsi: don't change pipe_resource in resource_copy_region > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91444 > --- > src/gallium/drivers/radeonsi/si_state.c | 2 +- > 1 file changed, 1

[Mesa-dev] [PATCH 1/3] egl/x11: fix use of EGL_BAD_NATIVE_WINDOW

Commit 4ed23fd590 introduced some calls to _eglError inappropriately passing it EGL_BAD_NATIVE_WINDOW. This was actually harmless in two of the cases as _eglError gets called later on with a more appropriate error code but (just to be safe) switch these to _eglLog calls instead. In the remaining ca

[Mesa-dev] [PATCH 3/3] egl/x11: don't abort when creating a DRI2 drawable fails

When calling either eglCreateWindowSurface or eglCreatePixmapSurface it was possible for an application to be aborted as a result of it failing to create a DRI2 drawable on the server. This could happen due to an application passing in an invalid native drawable handle, for example. Signed-off-by:

[Mesa-dev] [PATCH 2/3] egl/x11: set EGL_BAD_NATIVE_(PIXMAP|WINDOW) for invalid pixmaps/windows

Both eglCreatePixmapSurface and eglCreateWindowSurface were incorrectly setting the EGL error to be EGL_BAD_ALLOC when an invalid native drawable handle was being passed in. The EGL spec states the following for eglCreatePixmapSurface: "If pixmap is not a valid native pixmap handle, then a

[Mesa-dev] [PATCH] r600, compute: force tiling on 2D and 3D texture compute resources

To circumvent a problem occuring when LINEAR_ALIGNED array mode is selected on a TEXTURE_2D RAT. This configuration causes MEM_RAT STORE_TYPED to write to incorrect locations. --- src/gallium/drivers/radeon/r600_texture.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --gi

Re: [Mesa-dev] [PATCH 13/18] radeonsi: completely rework updating descriptors without CP DMA

On 28.07.2015 19:05, Marek Olšák wrote: > From: Marek Olšák > > The patch has a better explanation. Just a summary here: > - The CPU always uploads a whole descriptor array to previously-unused memory. > - CP DMA isn't used. > - No caches need to be flushed. > - All descriptors are always up-to-d

Re: [Mesa-dev] [PATCH v3 (part2) 49/56] main: Add SHADER_STORAGE_BLOCK and BUFFER_VARIABLE support for ARB_program_interface_query

On Fri, 2015-07-31 at 09:32 +0200, Samuel Iglesias Gonsálvez wrote: > On Fri, 2015-07-31 at 09:09 +0300, Tapani Pälli wrote: > > On 07/14/2015 10:46 AM, Iago Toral Quiroga wrote: > > > From: Samuel Iglesias Gonsalvez > > > > > > Including TOP_LEVEL_ARRAY_SIZE and TOP_LEVEL_ARRAY_STRIDE > > > que

Re: [Mesa-dev] [PATCH] r600, compute: force tiling on 2D and 3D texture compute resources

Please apply this behavior to r600g only. See rscreen->chip_class. Marek On Fri, Jul 31, 2015 at 12:06 AM, Zoltan Gilian wrote: > To circumvent a problem occuring when LINEAR_ALIGNED array mode is > selected on a TEXTURE_2D RAT. > This configuration causes MEM_RAT STORE_TYPED to write to incorre

Re: [Mesa-dev] [PATCH] i965/fs: Fix regression with SIMD8 VS since b5f1a48e234d47b24df38cb562cffb8941d43795.

In hope of speeding up the review and merge of this bug fix, I confirm that below patch fix the regression I have had from: "b5f1a48e234d47b24df38cb562cffb8941d43795" on Gen8. /Marta > -Original Message- > From: Francisco Jerez [mailto:curroje...@riseup.net] > Sent: Thursday, July 30, 20

Re: [Mesa-dev] [PATCH] r600, compute: force tiling on 2D and 3D texture compute resources

On 31.07.2015 17:39, Zoltan Gilian wrote: > To circumvent a problem occuring when LINEAR_ALIGNED array mode is > selected on a TEXTURE_2D RAT. > This configuration causes MEM_RAT STORE_TYPED to write to incorrect > locations. [...] > @@ -715,10 +716,15 @@ static unsigned r600_choose_tiling(struct

Re: [Mesa-dev] Properly exposing limits with gallium

On Thu, Jul 30, 2015 at 10:21 PM, Ilia Mirkin wrote: > So I'm trying to get these things to line up, especially for nvc0. > > Here are the limits exposed by the blob drivers: > > http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html#v=Vendor > > and they reflect what the hardware is capable.

Re: [Mesa-dev] [PATCH v2 00/78] i965: A new vec4 backend based on NIR

On 07/30/2015 09:48 PM, Jason Ekstrand wrote: > > On Jul 27, 2015 3:39 PM, "Jason Ekstrand" > wrote: >> >> On Mon, Jul 27, 2015 at 2:07 PM, Eduardo Lima Mitev > wrote: >> > On 07/25/2015 03:08 AM, Jason Ekstrand wrote: >> >> Alright, I got th

  1   2   >