On Mon, 2025-01-13 at 16:24 +, Victor Labian Carro wrote:
> Hello,
>
> I followed the instructions in
> https://docs.mesa3d.org/rusticl.html#rusticl to install OpenCL in
> Raspberry Pi 5. However, clinfo command is not showing any devices.
> Can anyone help with suggestions?
>
What is show
Hi,
Some progress, on building, not testing:
$ find . -name 'lib*.a'
./src/compiler/isaspec/libisaspec.a
./src/util/libmesa_util_sse41.a
./src/util/blake3/libblake3.a
./src/gallium/frontends/osmesa/libosmesa_st.a
./src/gallium/drivers/softpipe/libsoftpipe.a
So, maybe it might just be possible.
The build could be worked to get a gles1 lib, which isn't optimal given
the power of the pi's gpu.
On 18/04/2024 11:57, Luke A. Guest wrote:
On 18/04/2024 11:23, Luke A. Guest wrote:
I took a look at this over the last few days with the plan to use
fs-uae to get the following
On 18/04/2024 11:23, Luke A. Guest wrote:
I took a look at this over the last few days with the plan to use fs-uae
to get the following built:
1. Static lib build.
2. Aim for GL 1.5.
3. swrast (softpipe) and osmesa.
I just disabled the compiler directory and found that libmesa depends on
is done on PC/Linux systems.
Hard to believe it's been 30 years!
[snip]
I took a look at this over the last few days with the plan to use fs-uae
to get the following built:
1. Static lib build.
2. Aim for GL 1.5.
3. swrast (softpipe) and osmesa.
I'm not familiar with PiStorm32/
How do you run the opencl-cts tests on this?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 27/04/2021 08:00, Pierre Moreau wrote:
Hello Luke,
If you set `PKG_CONFIG_PATH=$PATH_TO_LIBCLC_INSTALL/share/pkgconfig` when
running meson, it should pick that version instead of the system one.
I run it as `PKG_CONFIG_PATH=[…] meson setup […]`; it might also be possible to
pass it as an a
Hi,
So, I've built a generic LLVM tree for mesa and other projects and
installed it alongside SPIRV-LLVM-Translator into
$HOME/opt/llvm-dev-reldebug.
I have installed libclc there too, although it wouldn't build as part of
llvm and make install wouldn't install to the same ll
On Mon, 2021-03-15 at 13:44 +0100, Erik Faye-Lund wrote:
> TLDR; I'm proposing to standardize on US English in our public-facing
> documentation.
+1
J.A.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/ma
On Thu, 2020-03-19 at 21:57 +0100, Mark Menzynski wrote:
> From: Karol Herbst
>
> Split out the output relevant fields from the nv50_ir_prog_info struct
> in order to have a cleaner separation between the input and output of
> the compilation.
>
Please, submit the ser
ttps://www.mesa3d.org/submittingpatches.html#submit
J.A.
> ---
> .../drivers/nouveau/nv50/nv50_program.c | 344 ++
> 1 file changed, 344 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c
> b/src/gallium/drivers/nouveau/nv50
On Fri, 2019-12-13 at 13:35 -0800, Eric Anholt wrote:
> I finally got back around to experimenting with the gitlab merge bot,
> and it turns out that the day I spent a few weeks back I had actually
> given up 5 minutes before the finish line.
>
> Marge is now enabled for mesa/me
e D3DSIO_RET if it is the last instruction in a shader
Dylan Baker (5):
meson: fix logic for generating .pc files with old glvnd
meson: Try finding libxvmcw via pkg-config before using find_library
meson: Link xvmc with libxv
meson: gallium media state trackers require li
order to obtain future fixes.
Apologies for the big delay in this release; there were several regressions
that we
were investigating, which prevented the pre-release to be on time.
The current queue consist as usual on fixes for different parts.
Take a look at section "Mesa stable queue"
On Wed, 2019-09-18 at 12:08 -0700, Mark Janes wrote:
> Adding the release managers to the CC to make sure they see the thread...
>
> Dylan Baker writes:
>
> > Hi everyone,
> >
> > Since we're migrating to gitlab issues, it seems like a good time to review
&
util: fix SSE-version needed for double opcodes
Hal Gentz (1):
glx: Fix SEGV due to dereferencing a NULL ptr from XCB-GLX.
Jason Ekstrand (7):
Revert "intel/fs: Move the scalar-region conversion to the generator."
anv: Bump maxComputeWorkgroupSize
nir: Don't inf
Hello list,
The candidate for the Mesa 19.1.7 is now available. Currently we have:
- 30 queued
- 0 nominated (outstanding)
- and 0 rejected patch
The current queue consist as usual on fixes for different parts.
Take a look at section "Mesa stable queue" for more information
size when allocating
Juan A. Suarez Romero (7):
docs: add sha256 checksums for 19.1.5
cherry-ignore: add explicit 19.2 only nominations
cherry-ignore: iris: Replace devinfo->gen with GEN_GEN
cherry-ignore: iris: Update fast clear colors on Gen9 with direct
immediat
Hello list,
The candidate for the Mesa 19.1.6 is now available. Currently we have:
- 17 queued
- 0 nominated (outstanding)
- and 3 rejected patch
The current queue consist as usual on fixes for different parts, but nothing
outstanding.
Take a look at section "Mesa stable queue"
On Sat, 2019-08-17 at 12:17 -0400, Ilia Mirkin wrote:
> The compute paths in vl are a bit AMD-specific. For example, they (on
> nouveau), try to use a BGRX8 image format, which is not supported.
> Fixing all this is probably possible, but since the compute paths aren't
> in any
: Emit a dummy MEDIA_VFE_STATE before switching from GPGPU to 3D
Eric Engestrom (1):
util: fix mem leak of program path
Erik Faye-Lund (2):
gallium/dump: add missing query-type to short-list
gallium/dump: add missing query-type to short-list
Greg V (2):
anv: remove unused
Hello list,
The candidate for the Mesa 19.1.5 is now available. Currently we have:
- 15 queued
- 1 nominated (outstanding)
- and 1 rejected patch
The current queue is not as big as in previous releases, and it is as usual
mostly fixes.
Take a look at section "Mesa stable queue"
On Thu, 2019-08-08 at 15:28 +0200, Boris Brezillon wrote:
> On Thu, 8 Aug 2019 06:08:05 -0700
> Alyssa Rosenzweig wrote:
>
> > @Boris I don't see why this patch particularly needs to be backported to
> > 19.1?
>
> Nope, no reason to backport it to 19.1. It'
On Fri, 2019-08-02 at 19:18 +0200, Boris Brezillon wrote:
> ctx->job is supposed to serve as a cache to avoid an hash table lookup
> everytime we access the job attached to the currently bound FB, except
> it was never assigned to anything but NULL.
>
> Fix that by adding the
Ivybridge.
- R8G8B8_UNORM_SRGB is not supported on Haswell.
- A fix for hair artifacts in Max Payne 3 on AMD/RADV.
- Vulkan transform feedback extension is disabled on Intel gen7.
Andres Rodriguez (1):
radv: fix queries with WAIT_BIT returning VK_NOT_READY
Andrii Simiklit (2):
intel
, nir, ...).
Of those fixes, we could highlight several ones:
- Vulkan 24/48 bit formats are now not supported on Ivybridge.
- R8G8B8_UNORM_SRGB is not supported on Haswell.
- A fix for hair artifacts in Max Payne 3 on AMD/RADV.
- Vulkan transform feedback extension is disabled on Intel gen7
On Fri, 2019-07-26 at 10:41 -0400, Ilia Mirkin wrote:
> On Wed, Jul 24, 2019 at 9:34 AM Juan A. Suarez Romero
> wrote:
> > On Wed, 2019-07-24 at 14:27 +0200, Karol Herbst wrote:
> > > it's only fixing a crash in a build with asserts enabled, but if
> > > some
> ---
> src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> index 8f0e0099e7..9acc33d906 10064
On Wed, 2019-07-24 at 14:27 +0200, Karol Herbst wrote:
> it's only fixing a crash in a build with asserts enabled, but if
> somebody wants to apply those to stable, then go ahead.
>
OK; in that case I will keep it out.
Thanks!
J.A.
> On Wed, Jul 24, 2019 at 12:48
cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Looks like a good candidate for 19.1 stable. WDYT?
J.A.
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index a
--
This does not apply cleanly, so I've resolved it as
https://gitlab.freedesktop.org/mesa/mesa/commit/e1800b20f44670829ce4d3ec9c0df2f9f2d87976
J.A.
> src/amd/vulkan/radv_meta_clear.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/vul
Mesa 19.1.3 is now available.
In this release we have:
Mostly in fixes for ANV and RADV drivers, as well as NIR backend fixes.
Several of those patches fixe actually crashes with the drivers,
and a couple of them fix memory leaks.
Bas Nieuwenhuizen (3):
radv: Handle cmask being
with the drivers,
and a couple of them fix memory leaks.
Take a look at section "Mesa stable queue" for more information
Testing reports/general approval
Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.
T
On Mon, 2019-05-06 at 16:01 +0200, Iago Toral Quiroga wrote:
> From: Samuel Iglesias Gonsálvez
>
> There are tests in CTS for alpha to coverage without a color attachment
> that are failing. This happens because we remove the shader color
> outputs when we don't have a valid
---
> src/amd/vulkan/radv_nir_to_llvm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index 76d784b3374..b890ce56f16 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vu
Mesa 19.1.2 is now available.
In this release we have:
Different fixes for the Intel and AMD Vulkan drivers, Freedreno, the Meson
build system,
and some other fixes for other parts and/or drivers.
Worth to mention a fix for a crash in Wolfenstein II with the RADV driver, and
another fix
other parts and/or
drivers.
Worth to mention a fix for a crash in Wolfenstein II with the RADV driver, and
another fix
relevant for DXVK on Intel gen7 drivers.
Take a look at section "Mesa stable queue" for more information
Testing reports/general approval
--
Gert Wollny (1):
virgl: Assume sRGB write control for older guest kernels or virglrenderer
hosts
Haihao Xiang (1):
i965: support UYVY for external import only
Jason Ekstrand (1):
anv: Set STATE_BASE_ADDRESS upper bounds on gen7
Juan A. Suarez Romero (3):
docs: Add
fixes for different parts (Meson build, GLX,
etc).
Take a look at section "Mesa stable queue" for more information
Testing reports/general approval
Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.
The
On Tue, 2019-06-18 at 18:58 +0200, Samuel Pitoiset wrote:
> This fixes new CTS dEQP-VK.pipeline.depth_range_unrestricted.*.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
could this
On Tue, 2019-06-18 at 12:12 +0200, Samuel Pitoiset wrote:
> On 6/18/19 12:05 PM, Juan A. Suarez Romero wrote:
> > On Thu, 2019-06-13 at 12:44 +0200, Samuel Pitoiset wrote:
> > > This fixes a segfault when forcing DCC decompressions on compute
> > > because internal m
On Thu, 2019-06-13 at 12:44 +0200, Samuel Pitoiset wrote:
> This fixes a segfault when forcing DCC decompressions on compute
> because internal meta objects are not created since the on-demand
> stuff.
>
Does it make sense to nominate this to stable?
J.A.
> Signed
ons(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_get.c
> b/src/gallium/drivers/radeonsi/si_get.c
> index c1bddca1a66..9496817ac84 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -256,21 +2
On Tue, 2019-06-11 at 20:28 +0300, Thomas Backlund wrote:
> Den 11.6.2019 kl. 19:00, skrev Juan A. Suarez Romero:
> > Mesa 19.1.0 is now available.
> >
> > Emil Velikov (3):
> >mapi: add static_date offset to MaxShaderCompilerThreadsKHR
> >mapi:
the error read() gave us
Jason Ekstrand (1):
nir/propagate_invariant: Don't add NULL vars to the hash table
Juan A. Suarez Romero (2):
Update version to 19.1.0
docs: Add release notes for 19.1.0
Kenneth Graunke (1):
egl/x11: calloc dri2_surf so it's prope
e_load_ubo.
Jan Zielinski (1):
swr/rast: fix 32-bit compilation on Linux
Jason Ekstrand (4):
iris: Don't assume UBO indices are constant
intel/fs,vec4: Use g0 as the header for MFENCE
intel/fs: Do a stalling MFENCE in endInvocationInterlock()
nir/dead_cf: Call inst
On Tue, 2019-06-04 at 16:52 +0200, Connor Abbott wrote:
> On Tue, Jun 4, 2019 at 4:24 PM Juan A. Suarez Romero
> wrote:
> > On Fri, 2019-05-31 at 14:55 +0200, Connor Abbott wrote:
> > > Bindless handles in GL are 64-bit. This fixes an assert failure in LLVM.
> >
rc/gallium/drivers/radeonsi/si_shader_nir.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
> b/src/gallium/drivers/radeonsi/si_shader_nir.c
> index 19ed71ae05d..72e6ffbac8a 100644
> --- a/src/gallium/driv
Suggested-by: Kristian Høgsberg
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110698
> Signed-off-by: Vinson Lee
> ---
> src/freedreno/vulkan/tu_device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/freedreno/vulkan/tu_device.c
On Mon, 2019-04-15 at 16:15 +0200, Juan A. Suarez Romero wrote:
> Hi all,
>
> Here is the tentative release plan for 19.1.0.
>
> As many of you are well aware, it's time to the next branch point.
> The calendar is already updated, so these are the tentative dates:
>
wizzle for INPUT_ATTACHMENT, STORAGE_IMAGE
Dave Airlie (1):
Revert "mesa: unreference current winsys buffers when unbinding winsys
buffers"
Greg V (1):
gallium: enable dmabuf on BSD as well
Juan A. Suarez Romero (1):
Update version to 19.1.0-rc4
Lionel Landwerlin (3):
On Tue, 2019-05-28 at 02:08 +0200, Roland Scheidegger wrote:
> Am 27.05.19 um 11:39 schrieb Juan A. Suarez Romero:
> > On Fri, 2019-05-24 at 03:08 +0200, srol...@vmware.com wrote:
> > > From: Roland Scheidegger
> > >
> > > The default null_output really need
On Fri, 2019-05-24 at 03:08 +0200, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
> The default null_output really needs to be static, otherwise the values
> we'll eventually get later are doubly random (they are not initialized,
> and even if they were it's a
On Tue, 2019-05-21 at 15:10 -0400, Marek Olšák wrote:
> It should be fixed with: "[PATCH] radeonsi: fix a regression in
> si_rebind_buffer"
>
> Marek
Thanks! I'll reintroduce both commits for next 19.1 release.
J.A.
> On Tue, May 21, 2019, 6:24 AM Mike L
urces that exist
intel/fs/ra: Stop adding RA interference to too many SENDS nodes
anv: Emulate texture swizzle in the shader when needed
anv: Stop forcing bindless for images
anv: Only consider minSampleShading when sampleShadingEnable is set
Juan A. Suarez Romero (2):
On Tue, 2019-05-21 at 09:36 +0200, Gert Wollny wrote:
> Hi Marek,
>
> it seems that this patch is causing a few issues [1], any idea what is
> going on? Maybe it is best to revert the patch for now?
>
> Best,
> Gert
>
As this is commit is causing issues, I'
ts, I can remove that patch from the queue, unless Marek
can provide a fix for it.
Thanks!
J.A.
> May 18 15:31:43 quark kwin_x11[607]: qt.qpa.xcb: QXcbConnection: XCB
> error: 3 (BadWindow), sequence: 2825, resource id: 37748896, major
> code: 18 (ChangeProperty), minor code: 0
adeonsi/si_state_draw.c | 9 +-
> 3 files changed, 72 insertions(+), 33 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
> b/src/gallium/drivers/radeonsi/si_descriptors.c
> index 744fc9a15d7..6a4dcacc0f3 100644
> --- a/src/gallium/drivers/radeons
_dri.so to two of the kmsro drivers.
Dylan Baker (1):
meson: Force the use of config-tool for llvm
Eric Engestrom (1):
travis: fix syntax, and drop unused stuff
Gert Wollny (1):
softpipe/buffer: load only as many components as the the buffer resource
type provides
Juan A. Sua
will remain alive with bi-
weekly releases until the 19.1.1 release.
In the path to 19.1.0 release, there is a tracker bug for the regressions found
since 19.0:
https://bugs.freedesktop.org/show_bug.cgi?id=110625
Here are the people which helped shape the current release.
1 Adam Jackson
reported only
once for each function it appears in
Fixes: 316964709e2 ("util: add os_read_file() helper")
CC: Eric Engestrom
---
src/util/os_file.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/util/os_file.h b/src/util/os_file.h
index 2f97c19ed55..97c42b0aefc 100644
---
This reverts commit 40b3abb4d16af4cef0307e1b4904c2ec0924299e.
It is not clear that this commit was entirely correct, and unfortunately
it was pushed by error.
CC: Jason Ekstrand
---
Jason, we agreed on leaving this out of the VK_KHR_shader_float16_int8
patchset, but due a mistake I've p
On Thu, 2019-03-14 at 11:25 -0500, Jason Ekstrand wrote:
> Looking at this a bit more, I'm not sure that just short-circuiting actually
> covers all the cases. Unfortunately, we don't know what all the cases are
> because the SPIR-V spec doesn't say. I'm tryin
On Wed, 2019-04-17 at 13:17 -0700, Francisco Jerez wrote:
> "Juan A. Suarez Romero" writes:
>
> > From: Iago Toral Quiroga
> >
> > v2:
> > - Adapted unit tests to make them consistent with the changes done
> >to the validation of half-float
that point.
- Remove conditions from not verified case.
- Fix brackets on conditional.
---
src/intel/compiler/brw_eu_validate.c| 268 ++
src/intel/compiler/test_eu_validate.cpp | 630
2 files changed, 898 insertions(+)
diff --git a/src/intel/compiler
On Mon, 2019-04-15 at 18:57 +0300, Eero Tamminen wrote:
> Hi,
>
> On 15.4.2019 17.15, Juan A. Suarez Romero wrote:
> > Here is the tentative release plan for 19.1.0.
> >
> > As many of you are well aware, it's time to the next branch point.
> > The calenda
2019 - Release candidate 3
May 21 2019 - Release candidate 4/final release
This gives us around 2 weeks until the branch point.
Note: In the spirit of keeping things clearer and more transparent, we
will be keeping track of any features planned for the release in
Bugzilla [1].
Do add a separate "
On Wed, 2019-04-10 at 17:13 -0700, Francisco Jerez wrote:
> "Juan A. Suarez Romero" writes:
>
> > From: Iago Toral Quiroga
> >
> > v2:
> > - Adapted unit tests to make them consistent with the changes done
> >to the validation of half-float
On Wed, 2019-04-10 at 17:13 -0700, Francisco Jerez wrote:
> "Juan A. Suarez Romero" writes:
>
> > From: Iago Toral Quiroga
> >
> > v2:
> > - Adapted unit tests to make them consistent with the changes done
> >to the validation of half-float
insertions(+)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index cfaf126e2f5..4a735641c86 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -170,6 +170,20 @@ src1_is_null(const struct gen_device_info
| 155 +++-
src/intel/compiler/test_eu_validate.cpp | 116 ++
2 files changed, 270 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index bd0e48a5e5c..54bffb3af03 100644
--- a/src/intel/com
From: Iago Toral Quiroga
v2: f32to16/f16to32 can use a :W destination (Curro)
---
src/intel/compiler/brw_fs.cpp | 71 +++
1 file changed, 71 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index d4803c63b93..48b5cc6c403
On Wed, 2019-03-27 at 19:37 -0700, Francisco Jerez wrote:
> "Juan A. Suarez Romero" writes:
>
> > From: Iago Toral Quiroga
> >
> > v2:
> > - Adapted unit tests to make them consistent with the changes done
> >to the validation of half-floa
e soon.
> >
> > On 2/12/19 12:55 PM, Iago Toral Quiroga wrote:
> > > The changes in this version address review feedback to v3. The most
> > > significant
> > > changes include:
> > >
> > > 1. A more generic constant combining pass that can
, 876 insertions(+)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index 18c95efb05b..5eea02f5c94 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -170,6 +170,13 @@ src1_is_null(const struct gen_device_info
tions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index bd0e48a5e5c..cad50469c65 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -469,6 +469,66 @@ is_packed(unsigned vstride, unsigned
CCing Iago and Curro.
On Fri, 2019-03-22 at 10:08 +0100, Juan A. Suarez Romero wrote:
> From: Iago Toral Quiroga
>
> The section 'Execution Data Types' of 3D Media GPGPU volume, which
> describes execution types, is exactly the same in BDW and SKL+.
>
> Also, this
CCing Iago and Curro.
On Fri, 2019-03-22 at 10:07 +0100, Juan A. Suarez Romero wrote:
> From: Iago Toral Quiroga
>
> ---
> src/intel/compiler/brw_fs.cpp | 65 +++
> 1 file changed, 65 insertions(+)
>
> diff --git a/src/intel/compiler/b
From: Iago Toral Quiroga
The section 'Execution Data Types' of 3D Media GPGPU volume, which
describes execution types, is exactly the same in BDW and SKL+.
Also, this section states that there is a single execution type, so it
makes sense that this is the wider of the two floating p
From: Iago Toral Quiroga
---
src/intel/compiler/brw_fs.cpp | 65 +++
1 file changed, 65 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 2fc7793709b..3616a7afc31 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src
On Fri, 2019-03-08 at 13:29 -0600, Jason Ekstrand wrote:
> On Fri, Mar 8, 2019 at 9:30 AM Juan A. Suarez Romero
> wrote:
> > On Thu, 2019-03-07 at 07:15 -0600, Jason Ekstrand wrote:
> >
> > > Woah, is this legal SPIR-V? I think a second OpSelectionMerge is required.
As stated in Vulkan spec:
"Resetting a descriptor pool recycles all of the resources from all
of the descriptor sets allocated from the descriptor pool back to
the descriptor pool, and the descriptor sets are implicitly freed."
This fixes dEQP-VK.api.descriptor_poo
On Thu, 2019-03-07 at 07:15 -0600, Jason Ekstrand wrote:
> Woah, is this legal SPIR-V? I think a second OpSelectionMerge is required.
I'd say it is legal. The spec does not mandate that each branch has its own
merge instruction; only that the control flow must be structured for shad
insertions(+), 1 deletion(-)
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 7868eeb60bc..f749118efbe 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -605,7 +605,16 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct
list_head *cf_list
When emitting a branch in a block, it does not make sense to continue
processing further instructions, as they will not be reachable.
This fixes a nasty case with a loop with a branch that both then-part
and else-part exits the loop:
%1 = OpLabel
OpLoopMerge %2 %3 None
On Fri, 2019-02-22 at 10:04 -0600, Jason Ekstrand wrote:
> On Fri, Feb 22, 2019 at 9:58 AM Jason Ekstrand wrote:
> > On Fri, Feb 22, 2019 at 9:57 AM Lionel Landwerlin
> > wrote:
> > > On 22/02/2019 15:51, Juan A. Suarez Romero wrote:
> > >
> > &g
Fill out "Vertex Sub Pixel Precision Select" possible values.
Signed-off-by: Juan A. Suarez Romero
---
src/intel/genxml/gen10.xml | 5 -
src/intel/genxml/gen11.xml | 5 -
src/intel/genxml/gen7.xml | 5 -
src/intel/genxml/gen75.xml | 5 -
src/intel/genxml/gen
::VertexSubPixelPrecisionSelect (Jason)
v3: use _8Bit definition as value (Jason)
CC: Jason Ekstrand
CC: Kenneth Graunke
Signed-off-by: Juan A. Suarez Romero
---
src/intel/vulkan/anv_device.c| 2 +-
src/intel/vulkan/genX_pipeline.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel
::VertexSubPixelPrecisionSelect (Jason)
CC: Jason Ekstrand
CC: Kenneth Graunke
---
src/intel/vulkan/anv_device.c| 2 +-
src/intel/vulkan/genX_pipeline.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 3120865466a
/intel/vulkan/anv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 3120865466a..95224407318 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1095,7 +1095,7 @@ void
On Wed, 2019-02-13 at 11:53 -0800, Ian Romanick wrote:
> On 2/13/19 9:59 AM, Juan A. Suarez Romero wrote:
> > On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote:
> > > On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote:
> > > > On Tue, 2019-02-12 at 16:22 -0800, Ian
On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote:
> On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote:
> > On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> > > On 2/12/19 12:58 AM, Juan A. Suarez Romero wrote:
> > > > opt_split_alu_of_phi moves ALU inst
On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> On 2/12/19 12:58 AM, Juan A. Suarez Romero wrote:
> > opt_split_alu_of_phi moves ALU instruction to the end of continue block.
> >
> > But if the continue block ends with a jump instruction (an explicit
> > "
On Tue, 2019-02-12 at 09:38 -0800, Caio Marcelo de Oliveira Filho wrote:
> Hi Juan,
>
> On Tue, Feb 12, 2019 at 04:37:23PM +0100, Juan A. Suarez Romero wrote:
> > On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> > > I had a chat with Caio about this and I'm
On Tue, 2019-02-12 at 11:31 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 10:48 AM Juan A. Suarez Romero
> wrote:
> > This can happen when we record a VkCmdDraw in a secondary buffer that
> >
> > was created inheriting from the primary buffer, but with the fra
This can happen when we record a VkCmdDraw in a secondary buffer that
was created inheriting from the primary buffer, but with the framebuffer
set to NULL in the VkCommandBufferInheritanceInfo.
Vulkan 1.1.81 spec says that "the application must ensure (using scissor
if neccesary) tha
In opt_peel_initial_if optimization, when moving the continue list to
end of the continue block, before the jump, could happen that the
continue list itself also ends with a jump.
This would mean that we would have two jump instructions in a row: the
first one from the continue list and the
On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> I had a chat with Caio about this and I'm skeptical. In general, users of
> the CF manipulation code shouldn't be stitching two blocks together where the
> first contains a jump and the second is non-empty. If th
opt_split_alu_of_phi moves ALU instruction to the end of continue block.
But if the continue block ends with a jump instruction (an explicit
"continue" instruction) then the ALU must be inserted before the jump,
as it is illegal to add instructions after the jump.
CC: Ian Roman
On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> I had a chat with Caio about this and I'm skeptical. In general, users of
> the CF manipulation code shouldn't be stitching two blocks together where the
> first contains a jump and the second is non-empty. If th
1 - 100 of 969 matches
Mail list logo
