On Thu, 2019-01-17 at 13:55 -0600, Jason Ekstrand wrote:
> On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga > wrote:
> > v2:
> >
> > - make 16-bit be its own separate case (Jason)
> >
> >
> >
> > Reviewed-by: Topi Pohjolainen
> >
> > ---
> >
> > src/intel/compiler/brw_fs_nir.cpp | 18
On Thu, 2019-01-17 at 13:42 -0600, Jason Ekstrand wrote:
> On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga > wrote:
> > Some conversions are not directly supported in hardware and need to
> > be
> >
> > split in two conversion instructions going through an intermediary
> > type.
> >
> >
On Thu, 2019-01-17 at 22:31 -0600, Jason Ekstrand wrote:
> On Thu, Jan 17, 2019 at 6:42 PM Matt Turner
> wrote:
> > On Tue, Jan 15, 2019 at 5:54 AM Iago Toral Quiroga <
> > ito...@igalia.com> wrote:
> >
> > >
> >
> > > NIR already has these so they are redundant. A run of shader-db
> > confirms
On Thu, 2019-01-17 at 12:57 -0600, Jason Ekstrand wrote:
> Yup, that'll do it. Gotta watch out for ++... Assuming it fixes the
> problem, that patch is
>
> Reviewed-by: Jason Ekstrand
>
>
> On Thu, Jan 17, 2019 at 12:35 PM Lionel Landwerlin <
> lionel.g.landwer...@intel.com> wrote:
> >
>
https://bugs.freedesktop.org/show_bug.cgi?id=106595
zefkerri...@gmail.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On Thu, Jan 17, 2019 at 6:42 PM Matt Turner wrote:
> On Tue, Jan 15, 2019 at 5:54 AM Iago Toral Quiroga
> wrote:
> >
> > NIR already has these so they are redundant. A run of shader-db confirms
> > that the only cases where these backend optimizations are activated
> > are some Tomb Raider
https://bugs.freedesktop.org/show_bug.cgi?id=109258
--- Comment #5 from n3rdopolis ---
Created attachment 143147
--> https://bugs.freedesktop.org/attachment.cgi?id=143147=edit
Reverse 47273d7312cb5b5b6b0b9faa814d574bbbce1c01
Weston and Gnome shell work with LIBGL_ALWAYS_SOFTWARE with this
On Tue, Jan 15, 2019 at 5:54 AM Iago Toral Quiroga wrote:
>
> NIR already has these so they are redundant. A run of shader-db confirms
> that the only cases where these backend optimizations are activated
> are some Tomb Raider shaders where the affected variables are qualified
> as "precise",
I'm done for the day but I've read through most of the patches. I think
I've got 4 or 5 tricky ones left. By and large, I think things are looking
really good. I don't know that we'll make 19.0 but there's a possibility.
If not, it'll likely land shortly after.
On Tue, Jan 15, 2019 at 7:54 AM
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> Reviewed-by: Topi Pohjolainen
> ---
> .../compiler/brw_fs_combine_constants.cpp | 60 +++
> 1 file changed, 49 insertions(+), 11 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_combine_constants.cpp
>
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> NIR already has these so they are redundant. A run of shader-db confirms
> that the only cases where these backend optimizations are activated
> are some Tomb Raider shaders where the affected variables are
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> v2:
> - Do not propagate if the bit-size changes
> ---
> src/intel/compiler/brw_fs_cmod_propagation.cpp | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> There are no 8-bit immediates, so assert in that case.
> 16-bit immediates are replicated in each word of a 32-bit immediate, so
> we only need to check the lower 16-bits.
>
> v2:
> - Fix is_zero with
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> ---
> src/intel/compiler/brw_fs_nir.cpp | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index a3d193b8a44..ccf1891b925 100644
>
On Thu, Jan 17, 2019 at 5:11 PM Francisco Jerez
wrote:
> Subject is still inaccurate. How about "intel/fs: Don't touch
> accumulator destination while applying regioning alignment rule."
>
Sounds good to me. I'll fix it.
>
> Jason Ekstrand writes:
>
> > In some shaders, you can end up with
Jason Ekstrand writes:
> On Thu, Jan 17, 2019 at 3:34 PM Francisco Jerez
> wrote:
>
>> Jason Ekstrand writes:
>>
>> > Bah... previous e-mail unfinished. Please ignore.
>> >
>> > On Thu, Jan 17, 2019 at 4:15 AM Francisco Jerez
>> > wrote:
>> >
>> >> Jason Ekstrand writes:
>> >>
>> >> > The
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> The changes in this version address review feedback to v2 and, most
> importantly,
> rebase on top of relevant changes in master, specifically Curro's regioning
> lowering pass. This new regioning pass simplifies some of the NIR
>
This patch doesn't really do what the commit message says. What it really
does is implement float -> 8-bit converions for *any* size float.
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> These are not directly supported in hardware and brw_nir_lower_conversions
> should have taken
Subject is still inaccurate. How about "intel/fs: Don't touch
accumulator destination while applying regioning alignment rule."
Jason Ekstrand writes:
> In some shaders, you can end up with a stride in the source of a
> SHADER_OPCODE_MULH. One way this can happen is if the MULH is acting on
>
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> 3-src instructions don't support immediates, but since 36bc5f06dd22,
> we allow them on MAD and LRP relying on the combine constants pass to
> fix it up later. However, that pass is specialized for 32-bit
In some shaders, you can end up with a stride in the source of a
SHADER_OPCODE_MULH. One way this can happen is if the MULH is acting on
the top bits of a 64-bit value due to 64-bit integer lowering. In this
case, the compiler will produce something like this:
mul(8)acc0<1>UD g5<8,4,2>UD
On Thu, Jan 17, 2019 at 3:34 PM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > Bah... previous e-mail unfinished. Please ignore.
> >
> > On Thu, Jan 17, 2019 at 4:15 AM Francisco Jerez
> > wrote:
> >
> >> Jason Ekstrand writes:
> >>
> >> > The pass was discovered to cause problems
On Thu, Jan 17, 2019 at 05:05:41PM -0500, Rob Clark wrote:
> On Thu, Jan 17, 2019 at 3:56 PM Jonathan Gray wrote:
> >
> > On Mon, Jan 14, 2019 at 03:46:35PM +0200, Eero Tamminen wrote:
> > > Hi,
> > >
> > > On 13.1.2019 9.44, Jonathan Gray wrote:
> > > ...> As we can not depend on python to build
On Thu, Jan 17, 2019 at 3:56 PM Jonathan Gray wrote:
>
> On Mon, Jan 14, 2019 at 03:46:35PM +0200, Eero Tamminen wrote:
> > Hi,
> >
> > On 13.1.2019 9.44, Jonathan Gray wrote:
> > ...> As we can not depend on python to build Mesa in OpenBSD I will have to
> > > go back to maintaining a local Mesa
I believe it should work in principle [at least the tegra drm +
nouveau bit, perhaps not the android things], however it's not
well-tested. I have a Jetson TK1, but it dies fairly instantaneously
once any network goes through the NIC, which is a bad situation for a
netboot setup.
If you're
Jason Ekstrand writes:
> Bah... previous e-mail unfinished. Please ignore.
>
> On Thu, Jan 17, 2019 at 4:15 AM Francisco Jerez
> wrote:
>
>> Jason Ekstrand writes:
>>
>> > The pass was discovered to cause problems with the MUL+MACH combination
>> > we emit for nir_[iu]mul_high. In an
Hello, guys. I have device with tegra K1(T124). I try to get open source
graphical stack. What I use: mesa 3d(18.2-19.0), libdrm(2.4.96),
drm_hwcomposer(the latest), gbm_gralloc(the latest), 4.19 kernel by
google(tegra drm + nouveau). What I get: normal bootanimatin, but the
system UI is not
"Passes' function names, separated by comma, listed in NIR_SKIP
environment variable will be skipped in debug mode. The mechanism is
hooked into the _PASS macro, like NIR_PRINT."
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/130
Caio
On Mon, Jan 14, 2019 at 03:46:35PM +0200, Eero Tamminen wrote:
> Hi,
>
> On 13.1.2019 9.44, Jonathan Gray wrote:
> ...> As we can not depend on python to build Mesa in OpenBSD I will have to
> > go back to maintaining a local Mesa build system if autotools is removed.
>
> Mesa already needs
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> Source0 and Destination extract the floating-point precision automatically
> from the SrcType and DstType instruction fields respectively when they are
> set to types :F or :HF. For Source1 and Source2 operands, we use the new
> 1-bit
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> We open coded this in a couple of places, so a helper function is probably
> sensible. Plus it makes it more consistent with the 3src hardware type
> case.
>
> Suggested-by: Topi Pohjolainen
> ---
> src/intel/compiler/brw_reg_type.c |
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> We are now using these bits, so don't assert that they are not set, just
> avoid compaction in that case.
>
> Reviewed-by: Topi Pohjolainen
> ---
> src/intel/compiler/brw_eu_compact.c | 5 -
> 1 file changed, 4 insertions(+), 1
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> From the Skylake PRM, Extended Math Function:
>
> "The execution size must be no more than 8 when half-floats
>are used in source or destination operand."
>
> Earlier generations do not support
Again, please squash with the previous patch. Splitting stuff this
granular just makes review harder.
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> Reviewed-by: Jason Ekstrand
> ---
> src/intel/compiler/brw_compiler.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
Patches 10 and 11 really could be one patch.
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> Reviewed-by: Jason Ekstrand
> ---
> src/intel/compiler/brw_compiler.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/intel/compiler/brw_compiler.c
>
This should probably be squashed into patch 7 so that it's clear from one
patch that it's being properly handed on both sides of the gen9 boundary.
I'd also squash in patch 15 and just give the whole thing the title "Handle
extended math restrictions for half-float" with a detailed message
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> v2:
> - make 16-bit be its own separate case (Jason)
>
> Reviewed-by: Topi Pohjolainen
> ---
> src/intel/compiler/brw_fs_nir.cpp | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> There are some hardware restrictions that brw_nir_lower_conversions should
> have taken care of before we get here.
>
> v2:
> - rebased on top of regioning lowering pass
>
> Reviewed-by: Topi Pohjolainen
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> Going forward having these split is a bit more convenient since these two
> groups have different restrictions.
>
> v2:
> - Rebased on top of new regioning lowering pass.
>
> Reviewed-by: Topi Pohjolainen
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> Some conversions are not directly supported in hardware and need to be
> split in two conversion instructions going through an intermediary type.
> Doing this at the NIR level simplifies a bit the complexity in the backend.
>
> v2:
> -
Hi,
On Thu, 17 Jan 2019 at 16:35, Jason Ekstrand wrote:
> On January 17, 2019 08:58:03 Erik Faye-Lund
> wrote:
> > Whoops! I meant to say something like "we'd need to be able to
> > distinguis between CI steps that are triggered due to new MRs versus
> > updated MRs, or pushes to existing
Yup, that'll do it. Gotta watch out for ++... Assuming it fixes the
problem, that patch is
Reviewed-by: Jason Ekstrand
On Thu, Jan 17, 2019 at 12:35 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Looking at the change the binding table emission, I think the image++ has
> been
Reviewed-by: Jason Ekstrand
On Wed, Jan 16, 2019 at 1:32 AM Francisco Jerez
wrote:
> The docs are fairly incomplete and inconsistent about it, but this
> seems to be the reason why half-float destinations are required to be
> DWORD-aligned on BDW+ projects. This way the regioning lowering
Looking at the change the binding table emission, I think the image++
has been moved such that it doesn't produce the same tables anymore.
Trying this change on CI :
https://github.com/djdeath/mesa/commit/a6b8eaf1325389d94d1d8a5b3bb952a362125eb2
On 17/01/2019 18:19, Clayton Craft wrote:
Quoting Mark Janes (2019-01-17 10:13:37)
> Hi Iago,
>
> It looks like you tested this patch in CI and got the same failures that
> we are seeing on master:
>
> http://mesa-ci-results.jf.intel.com/itoral/builds/263/group/63a9f0ea7bb98050796b649e85481845
The correct link is:
Hi Iago,
It looks like you tested this patch in CI and got the same failures that
we are seeing on master:
http://mesa-ci-results.jf.intel.com/itoral/builds/263/group/63a9f0ea7bb98050796b649e85481845
Why was this patch pushed?
-Mark
Mark Janes writes:
> This patch regresses thousands of
This patch regresses thousands of tests on BDW and HSW:
http://mesa-ci-results.jf.intel.com/vulkancts/builds/10035/group/63a9f0ea7bb98050796b649e85481845#fails
I'll revert it as soon as my testing completes.
Iago Toral Quiroga writes:
> We had defined MAX_IMAGES as 8, which we used to size
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Dylan Baker changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |baker.dyla...@gmail.com
On Wed, Jan 16, 2019 at 2:23 PM Eric Anholt wrote:
> Marek Olšák writes:
>
> > From: "Jiang, Sonny"
> >
> > and add radeonsi support. This will be used by radeonsi internally.
> >
> > Signed-off-by: Sonny Jiang
>
> It's still strange to me to be proposing changes to gallium core with no
>
I think this is probably mostly ok. There's still some question about
exactly what gets stored there and who is storing it.
On Thu, Jan 17, 2019 at 4:34 AM apinheiro wrote:
> I was waiting Jason to chime in, but just in case he is too busy I took
> a look in detail to the patch. It LGTM, so
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 252 ++-
1 file changed, 128 insertions(+), 124 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 488ed0b6225..0bb2dcdcc20 100644
---
The driver only supports up to 8 sample locations.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 2 --
src/amd/vulkan/radv_meta_resolve.c | 8
src/amd/vulkan/radv_nir_to_llvm.c | 3 ---
3 files changed, 13 deletions(-)
diff --git
Totally useless to write the descriptors inside the loop.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 47 ++--
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index b2112a6ed34..488ed0b6225 100644
--- a/src/amd/vulkan/radv_device.c
+++
https://bugs.freedesktop.org/show_bug.cgi?id=108877
--- Comment #4 from Marek Olšák ---
This issue should be fixed with these two patches:
https://patchwork.freedesktop.org/patch/276824/
https://patchwork.freedesktop.org/patch/276858/
--
You are receiving this mail because:
You are the QA
On January 17, 2019 08:58:03 Erik Faye-Lund
wrote:
On Thu, 2019-01-17 at 14:37 +, Daniel Stone wrote:
Hi,
On Thu, 17 Jan 2019 at 07:38, Erik Faye-Lund
wrote:
1. New MRs should probably get their cover-letter automatically
sent to
the mailing list for incrased visibility.
[...]
I
Acked-by: Marek Olšák
Marek
On Thu, Jan 17, 2019 at 1:17 AM Timothy Arceri
wrote:
> Currently only add a cache key for a shader once it is linked.
> However games like Team Fortress 2 compile a whole bunch of shaders
> which are never actually linked. These compiled shaders can take
> up a
Reviewed-by: Marek Olšák
Marek
On Thu, Jan 17, 2019 at 1:17 AM Timothy Arceri
wrote:
> This basically reverts c2bc0aa7b188.
>
> By running the opts we reduce memory using in Team Fortress 2
> from 1.5GB -> 1.3GB from start-up to game menu.
>
> This will likely increase Deus Ex start up times
Hi, Lucas!
Here is result of execution standard Qt5 example application mainwindow
built under custom buildroot with gcc-4.9.4, mesa3d-17.3.6.
But we had the same error with latest buildroot and latest supported mesa and
gcc.
---
# ./mainwindow
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting
Bah... previous e-mail unfinished. Please ignore.
On Thu, Jan 17, 2019 at 4:15 AM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > The pass was discovered to cause problems with the MUL+MACH combination
> > we emit for nir_[iu]mul_high. In an experimental branch of mine, I ran
> > into
On Thu, 2019-01-17 at 14:37 +, Daniel Stone wrote:
> Hi,
>
> On Thu, 17 Jan 2019 at 07:38, Erik Faye-Lund
> wrote:
> > 1. New MRs should probably get their cover-letter automatically
> > sent to
> > the mailing list for incrased visibility.
> >
> > [...]
> >
> > I don't think any of these
On Thu, 2019-01-17 at 10:00 +0100, Michel Dänzer wrote:
> On 2019-01-17 8:38 a.m., Erik Faye-Lund wrote:
> > 3. There's some browsing-pain with the commit list. For instance, I
> > always second-guess if the latest commit is at the top or bottom.
>
> At the top, same as in all Git related tools
Hi,
On Thu, 17 Jan 2019 at 07:38, Erik Faye-Lund
wrote:
> 1. New MRs should probably get their cover-letter automatically sent to
> the mailing list for incrased visibility.
>
> [...]
>
> I don't think any of these issues are show-stoppers from moving
> entirely to MRs, though. Perhaps issue #1
On Thu, Jan 17, 2019 at 4:15 AM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > The pass was discovered to cause problems with the MUL+MACH combination
> > we emit for nir_[iu]mul_high. In an experimental branch of mine, I ran
> > into issues where the MUL+MACH ended up using a strided
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Jan Vesely changed:
What|Removed |Added
Depends on||109334
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=109334
Jan Vesely changed:
What|Removed |Added
Blocks||99553
Referenced Bugs:
Put a few nits below, but otherwise looks good.
-
Lionel
On 13/11/2018 00:05, Jordan Justen wrote:
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_compute.c | 131 +-
src/mesa/drivers/dri/i965/brw_context.h | 2 +
Sorry, for replying so late, going through my unread emails :(
We already have functions for doing this :
brw_load_register_reg
brw_load_register_imm32/64
brw_load_register_mem
Why not use those?
-
Lionel
On 13/11/2018 00:05, Jordan Justen wrote:
Signed-off-by: Jordan Justen
---
Mesa 18.3.2 is now available.
In this release candidate we have added more PCI IDs for AMD Vega devices and
a number of fixes for the RADV Vulkan drivers.
On the Intel side we have a selection ranging from quad swizzles support for
ICL to compiler fixes.
The nine state tracker has also seen
On 1/17/19 12:32 PM, apinheiro wrote:
On 17/1/19 9:39, Kenneth Graunke wrote:
On Wednesday, January 16, 2019 11:38:05 PM PST Erik Faye-Lund wrote:
On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
All,
The mesa project has now hit 100 merge requests (36 are still open).
I (and I'm
I was waiting Jason to chime in, but just in case he is too busy I took
a look in detail to the patch. It LGTM, so assuming it passes intel CI:
Reviewed-by: Alejandro Piñeiro
On 15/1/19 12:08, Sergii Romantsov wrote:
During conversion type-length was lost due to math.
CC: Jason Ekstrand
On 17/1/19 9:39, Kenneth Graunke wrote:
On Wednesday, January 16, 2019 11:38:05 PM PST Erik Faye-Lund wrote:
On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
All,
The mesa project has now hit 100 merge requests (36 are still open).
I (and I'm sure others) would be curious to hear
Jason Ekstrand writes:
> The pass was discovered to cause problems with the MUL+MACH combination
> we emit for nir_[iu]mul_high. In an experimental branch of mine, I ran
> into issues where the MUL+MACH ended up using a strided source due to
> working on half of a uint64_t and the new lowering
Hi Sergey,
Am Mittwoch, den 16.01.2019, 13:34 +0300 schrieb Nazarov Sergey:
> Hello!
> I use mesa+etnaviv Gallium driver on iMX6Q based board.
> I have double free error at the end of any application using mesa.
> I've found that the problem comes from current ARM g++ compilers
> (at least from
On 2019-01-17 8:38 a.m., Erik Faye-Lund wrote:
>
> 3. There's some browsing-pain with the commit list. For instance, I
> always second-guess if the latest commit is at the top or bottom.
At the top, same as in all Git related tools I've seen.
--
Earthling Michel Dänzer |
On Wednesday, January 16, 2019 11:38:05 PM PST Erik Faye-Lund wrote:
> On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
> > All,
> >
> > The mesa project has now hit 100 merge requests (36 are still open).
> > I (and I'm sure others) would be curious to hear people's initial
> > thoughts
Instead of doing every time we emit cache flushes.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 12 ++--
src/amd/vulkan/radv_private.h| 3 +--
src/amd/vulkan/si_cmd_buffer.c | 2 +-
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git
Remove two useless checks.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 11 ++-
src/amd/vulkan/si_cmd_buffer.c | 9 ++---
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
It's invalid to emit a ZPASS_DONE event on the compute queue, and
the fence BO is unused on the compute queue (ie. we don't flush
CB or DB caches).
This saves some space in the upload BO.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 3 ++-
1 file changed, 2
This parameter is actually useless as the immediate value
can always be zero.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 2 +-
src/amd/vulkan/radv_private.h| 1 -
src/amd/vulkan/radv_query.c | 4 ++--
src/amd/vulkan/si_cmd_buffer.c | 9 -
4 files
80 matches
Mail list logo
