Previously, we were marking constant surface used in the generator and
non-constant ones in brw_fs_nir. We should pick one and go with it.
---
src/intel/compiler/brw_fs_generator.cpp | 2 --
src/intel/compiler/brw_fs_nir.cpp | 16
2 files changed, 8 insertions(+), 10
This commit pulls the surface descriptor helpers out into brw_eu.h and
makes them no longer depend on the codegen infrastructure. This should
allow us to use them directly from the IR code instead of the generator.
This change is unfortunately less mechanical than perhaps one would like
but it
---
src/intel/compiler/brw_eu_emit.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index d22c5743038..e8235ce05f7 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++
---
src/intel/compiler/brw_fs.cpp | 138 ++-
src/intel/compiler/brw_fs.h | 2 +-
src/intel/compiler/brw_fs_generator.cpp | 162 +++---
.../compiler/brw_schedule_instructions.cpp| 17 ++
4 files changed, 177 insertions(+), 142
---
src/intel/compiler/brw_eu_defines.h | 1 +
src/intel/compiler/brw_fs.cpp | 10 ++
src/intel/compiler/brw_fs_nir.cpp | 14 --
src/intel/compiler/brw_shader.cpp | 2 ++
4 files changed, 21 insertions(+), 6 deletions(-)
diff --git
---
src/intel/compiler/brw_eu_defines.h | 1 -
src/intel/compiler/brw_fs.cpp | 31 ++--
src/intel/compiler/brw_fs.h | 4 -
src/intel/compiler/brw_fs_cse.cpp | 1 -
src/intel/compiler/brw_fs_generator.cpp | 73 ---
---
src/intel/compiler/brw_eu.h | 27 ---
src/intel/compiler/brw_eu_emit.c | 72 ---
src/intel/compiler/brw_fs.cpp | 181 +-
src/intel/compiler/brw_fs_generator.cpp | 62 --
.../compiler/brw_schedule_instructions.cpp
---
src/intel/compiler/brw_eu_defines.h | 7
src/intel/compiler/brw_fs.cpp | 9 +
src/intel/compiler/brw_fs.h | 6
src/intel/compiler/brw_fs_cse.cpp | 5 +++
src/intel/compiler/brw_fs_generator.cpp | 35
Instead of magically falling back to SIMD8 for atomics and typed
messages on Ivy Bridge, explicitly figure out the exec size and pass
that into brw_surface_payload_size.
---
src/intel/compiler/brw_eu_emit.c | 59 +---
1 file changed, 39 insertions(+), 20 deletions(-)
This patch series is something we've talked about doing for a while and
haven't gotten around to yet. It implements a generic SEND opcode and then
reworks a bunch of the current SEND instructions such as texturing to use
that instead of piles of shader codegen. Among other things, this gives us
Like all the other sends, it's just mlen * REG_SIZE.
Fixes: 3cbc02e4693 "intel: Use TXS for image_size when we have..."
---
src/intel/compiler/brw_fs.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index
On 11/02/2018 01:06 PM, Emil Velikov wrote:
From: Emil Velikov
If the user provides an invalid display or device the ToVendor lookup
will fail.
In this case, the local [Mesa vendor] error code will be set. Thus on
sequential eglGetError(), the error will be EGL_SUCCESS.
To be more specific,
https://bugs.freedesktop.org/show_bug.cgi?id=108508
Ahmed Elsayed changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
If you pass a bool in as the value to set, the C standard says that it
gets converted to an int prior to shifting. If you try to set a bool to
bit 31, this lands you in undefined behavior. It's better just to add
the explicit cast and let the compiler delete it for us.
---
From: Marek Olšák
---
src/gallium/state_trackers/va/surface.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
index 5376be28531..9646427ea5f 100644
---
On 17/5/18 10:55 am, Ilia Mirkin wrote:
ES has all kinds of additional linking rules. I suspect they'll break
down if some of the shaders are ES and some are not-ES.
Hi Ilia,
Can you think of an example of this. I've attempted to create a CTS test
with the following justification:
Add
User are encouraged to switch to LLVM 7.0 released in September 2018.
Signed-off-by: Samuel Pitoiset
---
configure.ac | 4 +-
meson.build | 2 +-
src/amd/common/ac_llvm_build.c| 270 +-
Reviewed-by: Jordan Justen
On 2018-11-01 20:01:36, Kenneth Graunke wrote:
> There are some cases where the VS is the only stage enabled, it uses the
> entire URB, and the URB is large enough that placing later stages after
> the VS exceeds the number of bits for "URB Starting Address".
>
> For
Reviewed-by: Samuel Pitoiset
On 11/1/18 7:52 PM, Jan Vesely wrote:
The option was removed in LLVM r345763
Signed-off-by: Jan Vesely
---
src/amd/common/ac_llvm_util.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/amd/common/ac_llvm_util.c
This change breaks:
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag,Fail
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom,Fail
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_tessc,Fail
On Fri, 2 Nov 2018 at 15:22, Dave Airlie wrote:
>
> On Tue, 23 Oct 2018 at 10:57, Eric Anholt wrote:
> >
> > Eric Engestrom writes:
> >
> > > Fixes errors thrown by GCC's Undefined Behaviour sanitizer (ubsan) every
> > > time this macro is used.
>
> This seems to be causing problems for me here
On Fri, Nov 02, 2018 at 12:09:54AM -0500, Jason Ekstrand wrote:
> On Thu, Nov 1, 2018 at 5:51 AM Toni Lönnberg
> wrote:
>
> > On Wed, Oct 31, 2018 at 01:18:11PM -0500, Jason Ekstrand wrote:
> > > On Wed, Oct 31, 2018 at 11:10 AM Toni Lönnberg
> > > wrote:
> > >
> > > > When we debug media or
The spec says:
"vkCmdCopyQueryPoolResults is considered to be a transfer
operation, and its writes to buffer memory must be synchronized
using VK_PIPELINE_STAGE_TRANSFER_BIT and VK_ACCESS_TRANSFER_WRITE_BIT
before using the results."
VK_PIPELINE_STAGE_TRANSFER_BIT will wait for
https://bugs.freedesktop.org/show_bug.cgi?id=108635
--- Comment #4 from kyle.de...@mykolab.com ---
Hmmm.
I'll post this on the KDE side and see what they think.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=108635
--- Comment #2 from kyle.de...@mykolab.com ---
Narrowed it down to XWayland.
Seems like it doesn't like that order swap...
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=108635
kyle.de...@mykolab.com changed:
What|Removed |Added
Summary|68dc591af16ebb36814e4c187e4 |68dc591af16ebb36814e4c187e4
We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it guessing the max number of components from one of
its inputs.
Fixes the following CTS tests:
https://bugs.freedesktop.org/show_bug.cgi?id=108635
Tapani Pälli changed:
What|Removed |Added
CC||lem...@gmail.com
--
You are receiving
Hi all,
could somebody provide Reviewed-by in order to apply in mesa-dev and
avoid trivial building error?
Thanks
Mauro
On Tue, Oct 30, 2018 at 10:42 PM Mauro Rossi wrote:
>
> libmesa_git_sha1 whole static dependency is added to get git_sha1.h header
> and avoid following building error:
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=108635
--- Comment #1 from kyle.de...@mykolab.com ---
I don't know how to collect meaningful debug output from a crashing
startplasmacompositor... :/
Actually, come to think of it, it's kwin_wayland that's dying, I suppose.
Not that this helps me or
https://bugs.freedesktop.org/show_bug.cgi?id=108635
kyle.de...@mykolab.com changed:
What|Removed |Added
Severity|normal |major
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=108635
kyle.de...@mykolab.com changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=108635
--- Comment #3 from Tapani Pälli ---
Since this commit fixed failing dEQP and Piglit tests I'm assuming there is
something wrong in either kwin or XWayland. Perhaps with this commit it starts
to actually utilize
https://bugs.freedesktop.org/show_bug.cgi?id=108635
Bug ID: 108635
Summary: 68dc591af16ebb36814e4c187e4998948103c99c causes
"startplasmacompositor" to segfault
Product: Mesa
Version: git
Hardware: Other
OS:
On November 2, 2018 06:25:59 Timothy Arceri wrote:
We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it guessing the max number of components from one of
its inputs.
Fixes the following CTS tests:
https://bugs.freedesktop.org/show_bug.cgi?id=108635
--- Comment #5 from kyle.de...@mykolab.com ---
On a whim, I tried to start Sway, but XWayland also fails to start...
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
On 2/11/18 11:52 pm, Jason Ekstrand wrote:
On November 2, 2018 06:25:59 Timothy Arceri wrote:
We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it guessing the max number of components from one of
its
On Thu, 1 Nov 2018 at 09:50, Gert Wollny wrote:
>
> From: Gert Wollny
>
> The bind flags defined by mesa/gallium might not always be in sync
> with the ones copied to virglrenderer/gallium. Therefore, use the
> flags defined in virgl like it is done for all the other calls to
> create resources.
We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it guessing the max number of components from one of
its inputs.
Fixes the following CTS tests:
On November 2, 2018 08:20:34 Timothy Arceri wrote:
On 2/11/18 11:52 pm, Jason Ekstrand wrote:
On November 2, 2018 06:25:59 Timothy Arceri wrote:
We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it
https://bugs.freedesktop.org/show_bug.cgi?id=108636
Bug ID: 108636
Summary: test_optpass has use after free bug, failing with
memory testing tools like address sanitizer
Product: Mesa
Version: git
Hardware: Other
On Friday, 2018-11-02 13:38:53 +0100, Mauro Rossi wrote:
> Hi all,
> could somebody provide Reviewed-by in order to apply in mesa-dev and
> avoid trivial building error?
Not an expert on Android.mk, but this looks reasonable, and adding that
dep is definitely right, so:
Reviewed-by: Eric
On 11/2/18 3:58 PM, Michel Dänzer wrote:
On 2018-11-02 10:23 a.m., Samuel Pitoiset wrote:
User are encouraged to switch to LLVM 7.0 released in September 2018.
At least two major releases of LLVM should always be supported,
otherwise we force our downstreams and users to upgrade LLVM and
On Thu, 1 Nov 2018 at 16:54, Eric Engestrom wrote:
>
> On Thursday, 2018-11-01 17:37:57 +0100, Mathias Fröhlich wrote:
> > Hi,
> >
> > On Thursday, 1 November 2018 17:28:48 CET Eric Engestrom wrote:
> > > Pushed now, but travis still fails:
> > > https://travis-ci.org/mesa3d/mesa/jobs/449405406
>
Bump
On Mon, Oct 22, 2018 at 5:14 PM Jason Ekstrand wrote:
> This is something that Connor and I have talked about quite a bit over the
> last couple of months. The core idea is to replace NIR's current 32-bit
> 0/-1 D3D10-style booleans with a 1-bit data type. All in all, I think it
> worked
https://bugs.freedesktop.org/show_bug.cgi?id=108636
--- Comment #1 from Hanno Böck ---
Created attachment 142341
--> https://bugs.freedesktop.org/attachment.cgi?id=142341=edit
stack trace from asan
--
You are receiving this mail because:
You are the assignee for the
LGTM
On Fri, Nov 2, 2018 at 8:37 AM Timothy Arceri wrote:
> We cannot use nir_build_alu() to create the new alu as it has no
> way to know how many components of the src we will use. This
> results in it guessing the max number of components from one of
> its inputs.
>
> Fixes the following CTS
On Fri, Nov 2, 2018 at 6:05 AM Toni Lönnberg
wrote:
> On Fri, Nov 02, 2018 at 12:09:54AM -0500, Jason Ekstrand wrote:
> > On Thu, Nov 1, 2018 at 5:51 AM Toni Lönnberg
> > wrote:
> >
> > > On Wed, Oct 31, 2018 at 01:18:11PM -0500, Jason Ekstrand wrote:
> > > > On Wed, Oct 31, 2018 at 11:10 AM
On 2018-11-02 10:23 a.m., Samuel Pitoiset wrote:
> User are encouraged to switch to LLVM 7.0 released in September 2018.
At least two major releases of LLVM should always be supported,
otherwise we force our downstreams and users to upgrade LLVM and Mesa in
lockstep.
--
Earthling Michel Dänzer
On Fri, Nov 02, 2018 at 09:47:11AM -0500, Jason Ekstrand wrote:
> On Fri, Nov 2, 2018 at 6:05 AM Toni Lönnberg
> wrote:
>
> > On Fri, Nov 02, 2018 at 12:09:54AM -0500, Jason Ekstrand wrote:
> > > On Thu, Nov 1, 2018 at 5:51 AM Toni Lönnberg
> > > wrote:
> > >
> > > > On Wed, Oct 31, 2018 at
https://bugs.freedesktop.org/show_bug.cgi?id=108635
kyle.de...@mykolab.com changed:
What|Removed |Added
Component|EGL |XWayland
Build mesa 9238 failed
Commit 9cab8ccd6c by Jan Vesely on 11/1/2018 6:30 PM:
amd: Make vgpr-spilling depend on llvm version\n\nThe option was removed in LLVM r345763\n\nSigned-off-by: Jan Vesely \nReviewed-by: Marek Olšák \nReviewed-by: Samuel Pitoiset
Build mesa 9239 completed
Commit 1c140470ef by Anuj Phogat on 10/24/2018 6:35 PM:
anv/icl: Disable prefetching of sampler state entries\n\nWA_1606682166:\nIncorrect TDL's SSP address shift in SARB for 16:6 & 18:8 modes.\nDisable the Sampler state prefetch
From: Marek Olšák
---
src/gallium/drivers/r300/r300_context.c | 2 +-
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_pipe_common.c | 2 +-
src/gallium/drivers/r600/radeon_uvd.c | 2 +-
src/gallium/drivers/r600/radeon_vce.c | 2 +-
From: Marek Olšák
---
src/gallium/include/pipe/p_defines.h | 3 +++
src/mesa/state_tracker/st_manager.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index dacedf5b936..693f041b1da 100644
---
Quoting Matt Turner (2018-11-02 12:59:14)
> Reviewed-by: Matt Turner
>
> Probably fine to add a Tested-by from the reporter as well.
>
> Thanks Dylan!
Yup. I'll push this to master now.
signature.asc
Description: signature
___
mesa-dev mailing list
From: Emil Velikov
Cc: Erik Faye-Lund
Signed-off-by: Emil Velikov
---
Ff| 2 ++
docs/relnotes/19.0.0.html | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
create mode 100644 Ff
diff --git a/Ff b/Ff
new file mode 100644
index 000..804e31ab99e
---
On Fri, 2 Nov 2018 at 15:58, Emil Velikov wrote:
> Ff| 2 ++
> docs/relnotes/19.0.0.html | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
> create mode 100644 Ff
>
> diff --git a/Ff b/Ff
> new file mode 100644
> index 000..804e31ab99e
> --- /dev/null
>
On Fri, 2018-11-02 at 15:40 +, Emil Velikov wrote:
> On Tue, 30 Oct 2018 at 17:11, Erik Faye-Lund
> wrote:
> > EXT_shader_implicit_conversions is a useful extension that adds
> > implicit
> > conversions to OpenGL ES 3.1. Since it's tested excensively in
> > dEQP, and
> > Mesa already has
On Tue, 30 Oct 2018 at 17:11, Erik Faye-Lund
wrote:
>
> EXT_shader_implicit_conversions is a useful extension that adds implicit
> conversions to OpenGL ES 3.1. Since it's tested excensively in dEQP, and
> Mesa already has support for implicit conversions, it seems reasonable to
> allow for the
On Fri, 2018-11-02 at 15:57 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Cc: Erik Faye-Lund
> Signed-off-by: Emil Velikov
> ---
> Ff| 2 ++
> docs/relnotes/19.0.0.html | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
> create mode 100644 Ff
>
> diff
Hi,
On Friday, 2 November 2018 06:22:13 CET Dave Airlie wrote:
> On Tue, 23 Oct 2018 at 10:57, Eric Anholt wrote:
> >
> > Eric Engestrom writes:
> >
> > > Fixes errors thrown by GCC's Undefined Behaviour sanitizer (ubsan) every
> > > time this macro is used.
>
> This seems to be causing
On 2018-11-01 20:04:18, Kenneth Graunke wrote:
> This will let us make multiple genX_*.c files, without copy and pasting
> all this boilerplate.
> ---
> src/mesa/drivers/dri/i965/Makefile.sources| 10 ++
> src/mesa/drivers/dri/i965/genX_boilerplate.h | 160 ++
>
From: Emil Velikov
Otherwise, we get no entrypoint which seems to break the world.
Note: there's a follow-up fix needed to our GLVND code, to make piglit
happy.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108635
Fixes: 7552fcb7b9b ("egl: add base EGL_EXT_device_base implementation")
From: Emil Velikov
If the user provides an invalid display or device the ToVendor lookup
will fail.
In this case, the local [Mesa vendor] error code will be set. Thus on
sequential eglGetError(), the error will be EGL_SUCCESS.
To be more specific, GLVND remembers the last vendor and calls back
In some cases (not building with llvm, which automatically pulls in
pthreads) nine needs to be directly linked with pthreads. Fixes building
on x86 (32 bit) without llvm.
Distro bug: https://bugs.gentoo.org/670094
Fixes: 6b4c7047d57178d3362a710ad503057c6a582ca3
("meson: build gallium nine
Reviewed-by: Matt Turner
Probably fine to add a Tested-by from the reporter as well.
Thanks Dylan!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=105328
Matt Turner changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |fdo-b...@engestrom.ch
Previously the debug would be:
libEGL debug: No DRI config supports native format 0x20203852
libEGL debug: No DRI config supports native format 0x38385247
but
libEGL debug: No DRI config supports native format R8
libEGL debug: No DRI config supports native format GR88
is a lot easier to
This requires that the caller make a little (stack) allocation to store
the string.
---
src/gbm/main/gbm.c | 18 ++
src/gbm/main/gbm.h | 6 ++
2 files changed, 24 insertions(+)
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 0bf2922bacdd..174f62ad797f 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=108365
--- Comment #1 from Alok Hota ---
Thanks for the details! I'll look into this.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
71 matches
Mail list logo
