Both are
Reviewed-by: Jason Ekstrand
On Apr 27, 2016 11:20 PM, "Samuel Iglesias Gonsálvez"
wrote:
> A later patch will add lower_flrp64 option to NIR.
>
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/compiler/nir/nir.h | 2 +-
> src/compiler/nir/nir_opt_algebraic
Some hardware (i965 on Broadwell generation, for example) does not support
natively the execution of lrp instruction with double arguments.
Add 'lower_flrp64' flag to lower this instruction in that case.
v2:
- Rename lower_flrp_double to lower_flrp64 (Jason)
- Fix typo (Jason)
- Adapt th
A later patch will add lower_flrp64 option to NIR.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir.h | 2 +-
src/compiler/nir/nir_opt_algebraic.py | 12 ++--
src/gallium/drivers/freedreno/ir3/ir3_nir.c | 2 +-
src/gallium/drivers/vc4/vc4_pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
s/bot/both
Patches 1-3 are:
Reviewed-by: Samuel Iglesias Gonsálvez
On 27/04/16 20:25, Jason Ekstrand wrote:
> --- src/compiler/nir/nir_opt_algebraic.py | 31
> ++- 1 file changed, 22 insertions(+), 9
> deletions(-)
>
>
v2:
* Declare loop index variable at loop site (idr)
* Make arrays of MI_MATH instructions 'static const' (idr)
* Remove commented debug code (idr)
* Updated comment in set_query_availability (Ken)
* Replace switch with if/else in hsw_result_to_gpr0 (Ken)
* Only divide GL_FRAGMENT_SHADER_INVO
https://bugs.freedesktop.org/show_bug.cgi?id=95180
Bug ID: 95180
Summary: rasterizer/memory/Convert.h:170:9: error:
â__builtin_isnanâ is not a member of âstdâ
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
On 27/04/16 21:18, Jason Ekstrand wrote:
> On Tue, Apr 12, 2016 at 1:05 AM, Samuel Iglesias Gonsálvez <
> sigles...@igalia.com> wrote:
>
>> Some hardware (i965 on Broadwell generation, for example) does not support
>> natively the execution of lrp instruction with double arguments.
>>
>> Add 'lo
Am 27.04.2016 um 00:11 schrieb Dave Airlie:
> From: Dave Airlie
>
> The GL4.1 spec bumps this to 2048, so we should do so.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/softpipe/sp_limits.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drive
On 23.04.2016 07:24, Marek Olšák wrote:
> On Fri, Apr 22, 2016 at 11:28 PM, Nicolai Hähnle wrote:
>> On 22.04.2016 12:29, Nicolai Hähnle wrote:
>>> On 20.04.2016 23:02, Michel Dänzer wrote:
On 21.04.2016 02:42, Marek Olšák wrote:
> On Thu, Apr 14, 2016 at 9:29 AM, Michel Dänzer
> wro
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #66 from bellamort...@gmail.com ---
Let me get this straight, they refused to fix the optimization bug so you were
forced to work around it?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assi
On Sun, 2016-04-17 at 13:18 -0400, Lars Hamre wrote:
> Return statements in conditional blocks were not having their
> output varyings lowered correctly.
>
> This patch fixes the following piglit tests:
> /spec/glsl-1.10/execution/vs-float-main-return
> /spec/glsl-1.10/execution/vs-vec2-main-retur
On Wednesday, April 27, 2016 1:48:16 PM PDT Jordan Justen wrote:
> On 2016-04-27 12:28:15, Kenneth Graunke wrote:
> > Signed-off-by: Kenneth Graunke
> > ---
> > src/mesa/drivers/dri/i965/brw_context.h | 2 ++
> > src/mesa/drivers/dri/i965/brw_queryobj.c | 4 ++--
> > src/mesa/drivers/dri/i96
STATE_BASE_ADDRESS stalls the whole pipeline, and the documentation
cautions us to emit it as little as possible for better performance.
We recently put some hacks in BLORP to try and avoid emitting it
if it was already set correctly. However, this wasn't quite minimal:
if BLORP is the first oper
We're about to start calling it directly, and this means the callers
won't have to think about generations.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 -
src/mesa/drivers/dri/i965/brw_misc_state.c | 46 ++--
src/mesa/drivers/dri/i965/brw_st
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_ff_gs.c | 2 +-
src/mesa/drivers/dri/i965/brw_gs.c| 2 +-
src/mesa/drivers/dri/i965/brw_state.h | 3 ++-
src/mesa/drivers/dri/i965/brw_vs.c| 2 +-
src/mesa/drivers/dri/i965/brw_wm.c| 2 +-
5 files changed, 6 insertions(+
This way all the programs are in one place again, and it also should
make some future STATE_BASE_ADDRESS related changes possible.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_clip.c | 28 --
src/mesa/drivers/dri/i965/brw_interpolation_map.c | 20
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #65 from Nicolai Hähnle ---
Probably nothing :)
This patch will likely fix the problem:
https://patchwork.freedesktop.org/patch/83779/
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee
Reviewed-by: Nicolai Hähnle
On 27.04.2016 11:44, Brian Paul wrote:
---
src/gallium/auxiliary/util/u_blit.c | 6 +++---
src/gallium/auxiliary/util/u_blitter.c| 8
src/gallium/auxiliary/util/u_dump_defines.c | 12 ++--
src/gallium/auxiliary/util/u_dump_
On 23.04.2016 07:05, Jakob Sinclair wrote:
Fixes a Coverity defect by adding checks to see if a value is negative
before using it to index an array. By checking the value first it makes
the code more clean and it doesn't change the outcome of the function.
Thanks. I don't think that case should
r600_screen_clear_buffer is always called with last parameter true, also
for the initial HTILE clear, so that doesn't seem quite right to me.
Nicolai
On 22.04.2016 03:52, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/r600/r600_blit.c | 2 +-
src/gallium/drivers/ra
Patches 1 & 2 are
Reviewed-by: Nicolai Hähnle
On 22.04.2016 03:52, Marek Olšák wrote:
From: Marek Olšák
not needed AFAIK
---
src/gallium/drivers/radeonsi/si_cp_dma.c | 8
1 file changed, 8 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c
b/src/gallium/drivers/
On Wed, Apr 27, 2016 at 5:01 PM, Emil Velikov wrote:
> On 27 April 2016 at 19:51, Eric Anholt wrote:
>> Rob Herring writes:
>>
>>> On Mon, Apr 25, 2016 at 7:53 PM, Eric Anholt wrote:
Rob Herring writes:
> On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring wrote:
>> On Fri, Apr 22,
---
include/GL/mesa_glinterop.h | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
index 814064d..39822f2 100644
--- a/include/GL/mesa_glinterop.h
+++ b/include/GL/mesa_glinterop.h
@@ -50,7 +50,11 @@
#ifnde
*** BLURB HERE ***
Youry Metlitsky (1):
mesa: Build EGL without X11 headers after interop patchset
include/GL/mesa_glinterop.h | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
--
2.8.0
___
mesa-dev mailing list
mesa-dev@lists.
On Mon, Apr 18, 2016 at 5:18 PM, Matt Turner wrote:
> On Mon, Apr 18, 2016 at 5:08 PM, Ian Romanick wrote:
>> On 04/18/2016 04:14 PM, Matt Turner wrote:
>>> Analogous to commit 1e4e17fbd in the i965/fs backend.
>>>
>>> Because the copy propagation pass in the vec4 backend is strictly local,
>>> w
Am 27.04.2016 um 22:45 schrieb Jose Fonseca:
> On 27/04/16 18:48, Roland Scheidegger wrote:
>> Am 27.04.2016 um 18:13 schrieb Jose Fonseca:
>>> On 27/04/16 02:46, Roland Scheidegger wrote:
Am 27.04.2016 um 03:05 schrieb Dave Airlie:
> On 27 April 2016 at 11:00, Dave Airlie wrote:
On 27 April 2016 at 19:51, Eric Anholt wrote:
> Rob Herring writes:
>
>> On Mon, Apr 25, 2016 at 7:53 PM, Eric Anholt wrote:
>>> Rob Herring writes:
>>>
On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring wrote:
> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
> wrote:
>> Hi Rob,
>>
With this change, to enable precise SIN and COS instructions
on Intel hardware, one can put
in the proper drirc file.
---
src/mesa/drivers/dri/common/xmlpool/t_options.h | 5 +
src/mesa/drivers/dri/i965/brw_compiler.c| 2 --
src/mesa/drivers/dri/i965/brw_context.c | 3 +++
s
This change enables the creation of pbuffer
surfaces on the surfaceless platform.
---
src/egl/drivers/dri2/egl_dri2.h | 7 +-
src/egl/drivers/dri2/platform_surfaceless.c | 178 +++-
2 files changed, 180 insertions(+), 5 deletions(-)
diff --git a/src/egl/drive
On 2016-04-27 12:28:15, Kenneth Graunke wrote:
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 2 ++
> src/mesa/drivers/dri/i965/brw_queryobj.c | 4 ++--
> src/mesa/drivers/dri/i965/gen6_queryobj.c | 30 ++
> 3 files changed, 30
On 27/04/16 18:48, Roland Scheidegger wrote:
Am 27.04.2016 um 18:13 schrieb Jose Fonseca:
On 27/04/16 02:46, Roland Scheidegger wrote:
Am 27.04.2016 um 03:05 schrieb Dave Airlie:
On 27 April 2016 at 11:00, Dave Airlie wrote:
So far I've set the execmask to 1 active channel, I'm contemplating
On Wed, Apr 27, 2016 at 12:13 PM, Kenneth Graunke wrote:
> On Thursday, April 21, 2016 10:18:48 PM PDT Jordan Justen wrote:
> [snip]
>> diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c b/src/mesa/drivers/
> dri/i965/brw_queryobj.c
>> index a8e5aba..81ee5ea 100644
>> --- a/src/mesa/drivers/dri
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_queryobj.c | 4 ++--
src/mesa/drivers/dri/i965/gen6_queryobj.c | 30 ++
3 files changed, 30 insertions(+), 6 deletions(-)
Jordan,
I'm pretty sure you
On Sat, Apr 16, 2016 at 2:45 PM, Jason Ekstrand wrote:
> ---
> .../drivers/dri/i965/brw_fs_surface_builder.cpp| 55
> ++
> 1 file changed, 55 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_surface_
On Tue, Apr 12, 2016 at 1:05 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> Some hardware (i965 on Broadwell generation, for example) does not support
> natively the execution of lrp instruction with double arguments.
>
> Add 'lower_lrp_double' flag to lower this instruction in tha
On Thursday, April 21, 2016 10:18:48 PM PDT Jordan Justen wrote:
[snip]
> diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c b/src/mesa/drivers/
dri/i965/brw_queryobj.c
> index a8e5aba..81ee5ea 100644
> --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/brw_queryobj
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #64 from higu...@gmx.net ---
So what a non-programmer user can do to help having this fixed?
I have recompiled mesa to workaround this, but many other people have this
problem and can't/don't know recompile mesa.
I can ask Gaijin for
On Wed, Apr 27, 2016 at 1:39 PM, Jason Ekstrand wrote:
> On Wed, Apr 27, 2016 at 12:54 AM, Ian Romanick wrote:
>>
>> On 04/27/2016 05:41 AM, Jason Ekstrand wrote:
>> > This matches the "foreach x in container" pattern found in many other
>> > programming languages. Generated by the following reg
Rob Herring writes:
> On Mon, Apr 25, 2016 at 7:53 PM, Eric Anholt wrote:
>> Rob Herring writes:
>>
>>> On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring wrote:
On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
wrote:
> Hi Rob,
>
> On 22 April 2016 at 16:50, Rob Herring wrote:
Quoting Emil Velikov (2016-04-21 06:16:20)
> From: Emil Velikov
>
> Rather than parsing through the same files (public headers) twice, tweak
> the python script to create both files at the same time.
>
> Chances are that if the public headers change, both files will need to
> be regenerated.
>
There is no sense in having the double version of ldexp take a 64-bit
integer. Instead, let's just take a 32-bit int all the time. This also
matches what GLSL does where both variants of ldexp take a regular integer
for the exponent argument.
---
src/compiler/nir/nir_opcodes.py | 2 +-
1 file ch
---
src/compiler/nir/nir_opt_algebraic.py | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
index 2ad1c70..dd89c6f 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
++
The new expressions are more explicit in terms of where the bits go so it's
a little easier to tell what's going on. This is the way GLSL specifies
things so it's a bit easier to verify too. It also has the benifit that
the new expressions easily vectorize so we can constant-fold vector forms
of
https://bugs.freedesktop.org/show_bug.cgi?id=95022
--- Comment #4 from higu...@gmx.net ---
So from what i understand, this is just apitrace running in a compatibility
profile and "glretrace --core file.trace" enforces the normal core profile...
so this is nothing to do with the game, right?
If ye
Reviewed-by: Alejandro Piñeiro
On 27/04/16 20:05, Kenneth Graunke wrote:
> Fixes dEQP-GLES31.functional subtests:
> draw_indirect.negative.command_offset_not_in_buffer_signed32_wrap
> draw_indirect.negative.command_offset_not_in_buffer_unsigned32_wrap
>
> These tests use really large values that
fine by me
Reviewed-by: Jason Ekstrand
On Wed, Apr 27, 2016 at 11:00 AM, Alejandro Piñeiro
wrote:
> The test was failing to build with "undefined reference to `roundf'"
> errors,
> so Make check on mesa was failing.
> ---
>
> The previouos change on the same Makefile.am had the same intention
On 2016-04-27 12:17, Marek Olšák wrote:
Reviewed-by: Marek Olšák
Marek
On Mon, Apr 25, 2016 at 9:03 AM, Jakob Sinclair
wrote:
Fixes a Coverity defect by adding checks to see if a value is negative
before using it to index an array. By checking the value first it
makes
the code a bit safer
Fixes dEQP-GLES31.functional subtests:
draw_indirect.negative.command_offset_not_in_buffer_signed32_wrap
draw_indirect.negative.command_offset_not_in_buffer_unsigned32_wrap
These tests use really large values that overflow GLsizeiptr, at
which point the buffer size isn't less than "end".
Bugzilla
The test was failing to build with "undefined reference to `roundf'" errors,
so Make check on mesa was failing.
---
The previouos change on the same Makefile.am had the same intention (fixing
make check using -lm), so I guess that the problem is on my environment. Having
said so, I checked on the
Am 27.04.2016 um 18:13 schrieb Jose Fonseca:
> On 27/04/16 02:46, Roland Scheidegger wrote:
>> Am 27.04.2016 um 03:05 schrieb Dave Airlie:
>>> On 27 April 2016 at 11:00, Dave Airlie wrote:
>> So far I've set the execmask to 1 active channel, I'm contemplating
>> changing that
>> though
On Wed, Apr 27, 2016 at 12:54 AM, Ian Romanick wrote:
> On 04/27/2016 05:41 AM, Jason Ekstrand wrote:
> > This matches the "foreach x in container" pattern found in many other
> > programming languages. Generated by the following regular expression:
> >
> > s/nir_foreach_phi_src(\([^,]*\),\s*\([
On Tue, Apr 26, 2016 at 10:43 PM, Eduardo Lima Mitev
wrote:
> Patches 1, 4 and 5 need rebasing.
>
No surprises there. Some of these really need Connor's 47-patch series to
happen first.
> Patches 2, 3 and 6 are:
>
> Reviewed-by: Eduardo Lima Mitev
>
Thanks! I'll push what I can.
> Thanks
On Wed, Apr 27, 2016 at 12:52 AM, Ian Romanick wrote:
> Patches 1 and 3 through 6 are
>
> Reviewed-by: Ian Romanick
>
Thanks!
> I'm sending out a comment on patch 2.
>
> On 04/27/2016 05:41 AM, Jason Ekstrand wrote:
> > I think things started out consistent when we first merged NIR since
> th
On Wed, Apr 27, 2016 at 9:53 AM, Nanley Chery wrote:
> On Tue, Apr 26, 2016 at 06:16:12PM -0700, Jason Ekstrand wrote:
> > Good catch!
> >
> > Reviewed-by: Jason Ekstrand
> >
> > Why does it cause an assert?
> >
>
> Thanks! The test does math on the returned properties struct if the
> format que
On Wednesday, April 27, 2016 9:57:54 AM PDT Mark Janes wrote:
> Kenneth Graunke writes:
>
> > Fixes
> > - ES31-CTS.gtf.GL31Tests.texture_stencil8.texture_stencil8
> > - ES31-CTS.gtf.GL31Tests.texture_stencil8.texture_stencil8_multisample
>
> After this patch was pushed, I still see Gen9 failures
Kenneth Graunke writes:
> Fixes
> - ES31-CTS.gtf.GL31Tests.texture_stencil8.texture_stencil8
> - ES31-CTS.gtf.GL31Tests.texture_stencil8.texture_stencil8_multisample
After this patch was pushed, I still see Gen9 failures for
ES31-CTS.gtf.GL31Tests.texture_stencil8.texture_stencil8_multisample
T
On Tue, Apr 26, 2016 at 06:16:12PM -0700, Jason Ekstrand wrote:
> Good catch!
>
> Reviewed-by: Jason Ekstrand
>
> Why does it cause an assert?
>
Thanks! The test does math on the returned properties struct if the
format query is successful. One of the functions, deLog2Ceil32(),
asserts that pr
On Tue, Apr 26, 2016 at 04:41:08PM -0700, Kenneth Graunke wrote:
> My intention was to have the render ring prelude occur at the first
> point where we start emiting render commands into a batch.
>
> Gen4-5 have a single ring that handles both BLT and 3D commands, so it's
> possible to have a BLT
On Mon, Apr 25, 2016 at 7:53 PM, Eric Anholt wrote:
> Rob Herring writes:
>
>> On Fri, Apr 22, 2016 at 9:08 PM, Rob Herring wrote:
>>> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov
>>> wrote:
Hi Rob,
On 22 April 2016 at 16:50, Rob Herring wrote:
> This adds map and unmap fu
---
src/gallium/auxiliary/util/u_blit.c | 6 +++---
src/gallium/auxiliary/util/u_blitter.c| 8
src/gallium/auxiliary/util/u_dump_defines.c | 12 ++--
src/gallium/auxiliary/util/u_dump_state.c | 4 ++--
src/gallium/auxiliary/util/u_format_tests.c | 2 +
The old comment was a bit terse. Also, change the function return
type to bool.
---
src/mesa/main/bufferobj.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/bufferobj.h b/src/mesa/main/bufferobj.h
index a5bfe88..5dcc553 100644
--- a/src/mesa/main/buff
On Wed, Apr 27, 2016 at 6:03 PM, Kenneth Graunke wrote:
> On Wednesday, April 27, 2016 11:22:48 AM PDT Marek Olšák wrote:
>> On Wed, Apr 27, 2016 at 5:05 AM, Kenneth Graunke
> wrote:
>> > On Monday, April 25, 2016 5:54:28 PM PDT Jordan Justen wrote:
>> >> Fixes the OpenGLES 3.1 CTS:
>> >> * ESEX
On Wed, Apr 27, 2016 at 09:17:32AM -0700, Kenneth Graunke wrote:
> On Wednesday, April 27, 2016 3:14:23 PM PDT Topi Pohjolainen wrote:
> > Fixes ES31-CTS.gtf.GL31Tests.texture_stencil8.texture_stencil8_multisample.
> >
> > Current logic divides given layer of one by number of samples (four)
> > tr
On Wednesday, April 27, 2016 3:14:23 PM PDT Topi Pohjolainen wrote:
> Fixes ES31-CTS.gtf.GL31Tests.texture_stencil8.texture_stencil8_multisample.
>
> Current logic divides given layer of one by number of samples (four)
> trashing the layer to zero. Layer adjustment is only to be used with
> non-in
Hi Emil,
I forgot to add Cc: 11.2 stable on the patches
7a215a3e274e7c793ab9c015004f5323cf85a50c "radeonsi: expclear must be
disabled on first Z/S clear"
8c43c06e0463515c1339d44cbb8f78169e6a06fb "radeonsi: work around an MSAA
fast stencil clear problem"
Fast stencil clear was added in 11.2,
On 27/04/16 02:46, Roland Scheidegger wrote:
Am 27.04.2016 um 03:05 schrieb Dave Airlie:
On 27 April 2016 at 11:00, Dave Airlie wrote:
So far I've set the execmask to 1 active channel, I'm contemplating
changing that
though and using less machines.
Ah yes, I think that would indeed be desirab
On Wednesday, April 27, 2016 11:22:48 AM PDT Marek Olšák wrote:
> On Wed, Apr 27, 2016 at 5:05 AM, Kenneth Graunke
wrote:
> > On Monday, April 25, 2016 5:54:28 PM PDT Jordan Justen wrote:
> >> Fixes the OpenGLES 3.1 CTS:
> >> * ESEXT-CTS.draw_elements_base_vertex_tests.invalid_mapped_bos
> >>
>
Reviewed-by: Bruce Cherniak
> On Apr 27, 2016, at 10:13 AM, Tim Rowley wrote:
>
> ---
> src/gallium/drivers/swr/swr_context.cpp| 4 ++--
> src/gallium/drivers/swr/swr_state.cpp | 6 +++---
> src/gallium/drivers/swr/swr_tex_sample.cpp | 4 ++--
> 3 files changed, 7 insertions(+), 7 deleti
On 04/27/2016 05:41 PM, Samuel Pitoiset wrote:
Yeah, please do it for Fermi as well.
On 04/27/2016 04:43 PM, Hans de Goede wrote:
Add support for SV_WORK_DIM.
Note this is only implemented for nve4 for now, hence this patch
being RFC.
Signed-off-by: Hans de Goede
---
src/gallium/drivers/n
On 04/27/2016 05:24 PM, Ilia Mirkin wrote:
On Wed, Apr 27, 2016 at 11:19 AM, Hans de Goede wrote:
Hi,
On 27-04-16 16:49, Ilia Mirkin wrote:
Please add this semantic to src/gallium/docs and explain what it
means.
Ah, I was under the impression these were not documented, but I
now see the
Yeah, please do it for Fermi as well.
On 04/27/2016 04:43 PM, Hans de Goede wrote:
Add support for SV_WORK_DIM.
Note this is only implemented for nve4 for now, hence this patch
being RFC.
Signed-off-by: Hans de Goede
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
sr
Reviewed-by: Bruce Cherniak
> On Apr 25, 2016, at 5:12 PM, Tim Rowley wrote:
>
> Couple of large backend refactorizations, some miscellaneous changes,
> and warning cleanup.
>
> Tim Rowley (6):
> swr: [rasterizer core] backend refactor
> swr: [rasterizer jitter] add mSimdInt1Ty
> swr: [rast
On Wed, Apr 27, 2016 at 11:19 AM, Hans de Goede wrote:
> Hi,
>
> On 27-04-16 16:49, Ilia Mirkin wrote:
>>
>> Please add this semantic to src/gallium/docs and explain what it
>> means.
>
>
> Ah, I was under the impression these were not documented, but I
> now see they are, will fix.
>
>> (I'm not
Hi,
On 27-04-16 16:49, Ilia Mirkin wrote:
Please add this semantic to src/gallium/docs and explain what it
means.
Ah, I was under the impression these were not documented, but I
now see they are, will fix.
> (I'm not even sure what this is, and the easily-found opencl
docs helpfully indicate
---
src/gallium/drivers/swr/swr_context.cpp| 4 ++--
src/gallium/drivers/swr/swr_state.cpp | 6 +++---
src/gallium/drivers/swr/swr_tex_sample.cpp | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/swr/swr_context.cpp
b/src/gallium/drivers/swr/swr
On Wed, Apr 27, 2016 at 10:43 AM, Hans de Goede wrote:
> Add support for SV_WORK_DIM.
>
> Note this is only implemented for nve4 for now, hence this patch
> being RFC.
>
> Signed-off-by: Hans de Goede
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
> src/gallium/driv
In order to implement get_work_dim() the driver may need to know the
clEnqueueNDRangeKernel() work_dim parameter, so pass it to the driver.
Signed-off-by: Hans de Goede
---
src/gallium/include/pipe/p_state.h| 7 +++
src/gallium/state_trackers/clover/core/kernel.cpp | 1 +
2 f
Please add this semantic to src/gallium/docs and explain what it
means. (I'm not even sure what this is, and the easily-found opencl
docs helpfully indicate that get_work_dim returns the work_dim...)
This wasn't done for some of the other compute-specific semantics.
Is this the equivalent of gl_Lo
Add support for SV_WORK_DIM.
Note this is only implemented for nve4 for now, hence this patch
being RFC.
Signed-off-by: Hans de Goede
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 1 +
src/gallium/drivers
Add a new WORK_DIM SV type, this is will return the grid dimensions
(1-4) for compute (opencl) kernels.
This is necessary to implement the opencl get_work_dim() function.
Signed-off-by: Hans de Goede
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 1 +
src/gallium/include/pipe/p_shader_tokens.
On Wed, Apr 27, 2016 at 01:12:57PM +0100, Emil Velikov wrote:
> On 25 April 2016 at 14:06, Stefan Dirsch wrote:
> > According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
> > always returns a valid pointer. If no context is made current, it will
> > contain dummyContext. Thus a
On 26/04/16 02:34, Brian Paul wrote:
---
src/gallium/drivers/llvmpipe/lp_context.c | 10 +++
src/gallium/drivers/llvmpipe/lp_jit.c | 10 +++
src/gallium/drivers/llvmpipe/lp_rast_debug.c| 2 +-
src/gallium/drivers/llvmpipe/lp_setup.c | 20 ++---
s
Fixes ES31-CTS.gtf.GL31Tests.texture_stencil8.texture_stencil8_multisample.
Current logic divides given layer of one by number of samples (four)
trashing the layer to zero. Layer adjustment is only to be used with
non-interleaved msaa surfaces where samples for particular layer are
in multiple sli
On 25 April 2016 at 14:06, Stefan Dirsch wrote:
> According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
> always returns a valid pointer. If no context is made current, it will
> contain dummyContext. Thus a test for NULL will always fail.
>
> https://lists.freedesktop.org/arc
On 11 March 2016 at 08:43, Andreas Fänger wrote:
> This patch makes it possible to build classic osmesa/swrast on windows
> again. Although there is a gallium version of osmesa now, the swrast version
> still has more features lacking in llvmpipe, e.g. anisotropic filtering.
>
> This reverts commi
Reviewed-by: Marek Olšák
Marek
On Mon, Apr 25, 2016 at 9:03 AM, Jakob Sinclair
wrote:
> Fixes a Coverity defect by adding checks to see if a value is negative
> before using it to index an array. By checking the value first it makes
> the code a bit safer but overall should not have a big impac
On 27 April 2016 at 10:31, Jose Fonseca wrote:
> On 27/04/16 09:11, Ian Romanick wrote:
>>
>> On 04/26/2016 08:55 PM, Jose Fonseca wrote:
>>>
>>> Ran `make check` inside src/glx to verify everything compiles and links
>>> correctly.
>>>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=95158
>>
>>
On 27/04/16 09:11, Ian Romanick wrote:
On 04/26/2016 08:55 PM, Jose Fonseca wrote:
Ran `make check` inside src/glx to verify everything compiles and links
correctly.
https://bugs.freedesktop.org/show_bug.cgi?id=95158
In the future, please use
Bugzilla: https://bugs.freedesktop.org/show_bug.c
On Wed, Apr 27, 2016 at 5:05 AM, Kenneth Graunke wrote:
> On Monday, April 25, 2016 5:54:28 PM PDT Jordan Justen wrote:
>> Fixes the OpenGLES 3.1 CTS:
>> * ESEXT-CTS.draw_elements_base_vertex_tests.invalid_mapped_bos
>>
>> Because this is triggering the error message after the normal API
>> valid
https://bugs.freedesktop.org/show_bug.cgi?id=95159
--- Comment #2 from Ian Romanick ---
Please send patches to the mesa-dev mailing list using 'git send-email'.
Otherwise they are likely to go unnoticed.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the as
On 04/26/2016 08:55 PM, Jose Fonseca wrote:
> Ran `make check` inside src/glx to verify everything compiles and links
> correctly.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=95158
In the future, please use
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95158
It helps various scrip
https://bugs.freedesktop.org/show_bug.cgi?id=95088
--- Comment #1 from Emil Velikov ---
The issue is resolved with my earlier series, with one patch still pending
ack/nack/r-b.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=95088
Vinson Lee changed:
What|Removed |Added
CC||ja...@jlekstrand.net,
|
On 04/27/2016 05:41 AM, Jason Ekstrand wrote:
> This matches the "foreach x in container" pattern found in many other
> programming languages. Generated by the following regular expression:
>
> s/nir_foreach_phi_src(\([^,]*\),\s*\([^,]*\))/nir_foreach_phi_src(\2, \1)/
>
> and a similar expressio
Patches 1 and 3 through 6 are
Reviewed-by: Ian Romanick
I'm sending out a comment on patch 2.
On 04/27/2016 05:41 AM, Jason Ekstrand wrote:
> I think things started out consistent when we first merged NIR since there
> weren't a lot of helpers. Over time, however, more nir_foreach helpers
> ha
On 04/26/2016 10:08 PM, Jamey Sharp wrote:
> OpenGL 4.5 Core Profile section 7.1, in the documentation for
> CompileShader, says: "Changing the source code of a shader object with
> ShaderSource does not change its compile status or the compiled shader
> code." (I haven't checked older versions of
96 matches
Mail list logo
