On Thu, Oct 24, 2024 at 8:38 AM Christian König
wrote:
>
> Completely agree, but that's a platform decision which Alex needs to make.
+ Felix
Does buffer sharing with ROCm depend on the shared VA space?
Alex
>
> Christian.
>
> Am 24.10.24 um 14:16 schrieb Marek Olšá
What sort of problem are you having? You should be able to click on
"Register" at the top right and then create an account. You will need
a valid email to do so.
Alex
On Thu, Jul 11, 2024 at 6:25 AM Riza Dindir wrote:
>
> Hello
>
> I wanted to report a problem wit
w scheduler that there
> are new GPU commands in the ring buffer. Userspace inserts all the wait,
> draw, and signal commands into the ring buffer and then "rings" the doorbell.
> It's my understanding that the ring buffer and the doorbell are always mapped
> in t
21 um 14:26 schrieb Daniel Vetter:
> > > > > On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote:
> > > > > > On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
> > > > > > > Am 28.04.21 um 12:05 schrieb Dani
On Wed, Apr 28, 2021 at 6:31 AM Christian König
wrote:
>
> Am 28.04.21 um 12:05 schrieb Daniel Vetter:
> > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
> >> On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote:
> >>> On Tuesday, April 27th, 2021 at 7
't be avoided, I'd prefer a to get a clear
> error, and not bad results on screen because nothing is synchronized
> anymore.
It's an upcoming requirement for windows[1], so you are likely to
start seeing this across all GPU vendors that support windows. I
think the timing depends on how
The mesa process has switched to using merge requests.
The steps for creating a MR are:
1*) Click "fork" in the Meso repo to create a private repo where
you'll push branches for MRs.
2) git push your branch into your private repo
3) The "git push" command printed a link to create a MR for that
bra
x27;t do anything illegal. It's on the reviewers
to determine if the patch is reasonable and should be applied. The
name is just window dressing.
Alex
On Thu, Dec 12, 2019 at 5:42 PM Timothy Arceri wrote:
>
>
>
> On 13/12/19 1:54 am, Daniel Stone wrote:
> > On Wed, 1
usually make it through. If we are proposing to
do away with the mailing list, what is the plan for non-patch
discussions? Opening issues in gitlab?
Alex
>
> Dylan
>
> Quoting Alex Deucher (2019-12-10 07:30:43)
> > How do we deal with drive by fixes? E.g., some random user submi
How do we deal with drive by fixes? E.g., some random user submits a
fix but doesn't want to create a gitlab account just to submit a fix?
Whoever reviews the patch should submit an MR?
Alex
On Mon, Dec 9, 2019 at 6:07 PM Dylan Baker wrote:
>
> Hi everyone,
>
> I think its
On Tue, 11 Jun 2019 at 14:32, Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 10.06.19 um 15:56 schrieb Bas Nieuwenhuizen:
> > On Sat, Jun 8, 2019 at 3:36 PM Alex Smith
> wrote:
> >> On Mon, 3 Jun 2019 at 13:27, Koenig, Christian <
> christia
platform
supports large or resizeable BARs or not.
Alex
>
> This fixes dEQP-VK.api.info.device.memory_budget.
>
> Cc: 19.0 19.1
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_device.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-
On Mon, 3 Jun 2019 at 13:27, Koenig, Christian
wrote:
> Am 03.06.19 um 14:21 schrieb Alex Smith:
>
> On Mon, 3 Jun 2019 at 11:57, Koenig, Christian
> wrote:
>
>> Am 02.06.19 um 12:32 schrieb Alex Smith:
>> > Put the uncached GTT type at a higher index than the
Thanks, will have a look - can't look right now, will see if I can sometime
tomorrow.
Alex
On Mon, 3 Jun 2019 at 13:27, Koenig, Christian
wrote:
> Am 03.06.19 um 14:21 schrieb Alex Smith:
>
> On Mon, 3 Jun 2019 at 11:57, Koenig, Christian
> wrote:
>
>> Am 02.06.19 u
On Mon, 3 Jun 2019 at 11:57, Koenig, Christian
wrote:
> Am 02.06.19 um 12:32 schrieb Alex Smith:
> > Put the uncached GTT type at a higher index than the visible VRAM type,
> > rather than having GTT first.
> >
> > When we don't have dedicated VRAM, we don't
On Sun, 2 Jun 2019 at 11:59, Bas Nieuwenhuizen
wrote:
> On Sun, Jun 2, 2019 at 12:32 PM Alex Smith
> wrote:
> >
> > Put the uncached GTT type at a higher index than the visible VRAM type,
> > rather than having GTT first.
> >
> > When we don't have de
top (Raven Ridge), this improves average FPS in
the Rise of the Tomb Raider benchmark by up to ~30%. Tested a couple of
other (Feral) games and saw similar improvement on those as well.
Signed-off-by: Alex Smith
---
I noticed that the memory types advertised on my Raven laptop looked a
bit odd so pla
> -CHIP_CEDAR,
> +CHIP_CEDAR,/* Evergreen */
Could also make this /* GFX4 (Evergreen) */
> CHIP_REDWOOD,
> CHIP_JUNIPER,
> @@ -73,17 +73,17 @@ enum radeon_family {
> CHIP_TURKS,
> CHIP_CAICOS,
> -CHIP_CAYMAN,
> +CHIP_CAYMAN, /* North
Acked-by: Alex Deucher
On Mon, May 13, 2019 at 4:01 PM Liu, Leo wrote:
>
> Ping...
>
> On 5/9/19 2:10 PM, Liu, Leo wrote:
> > Since the using output optimization is only for back buffer case
> >
> > Signed-off-by: Leo Liu
> > ---
> > src/gallium/a
On Tue, Mar 26, 2019 at 2:44 PM Liu, Leo wrote:
>
> VCN supports this profile as well as UVD, so add it
>
> Signed-off-by: Leo Liu
> CC:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/radeon_vcn_dec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> di
nt
to work on for your project. Many projects have GSoC ideas pages that
you can review to see some possible ideas.
Alex
On Wed, Mar 13, 2019 at 10:50 AM Adarsh Khubchandani wrote:
>
> Hello. I sent a message regarding guidance that I needed for EVOC to some
> mentors, but no one seems
version so that userspace can check
what features are supported by the kernel driver. See amdgpu_drv.c in
the amdgpu kernel driver.
Alex
>
> Cheers
>
> Mike
>
> On Thu, 28 Feb 2019 at 21:20, Marek Olšák wrote:
> >
> > Hi,
> >
> > This series enables D
> +
>
>
> I see that APU are not affected by the change.
>
> Are they affected by the issue this patch aims to fix though ? If so,
> wouldn't it make sense to switch to PIPE_USAGE_STREAM for APUs ?
They are not affected. "VRAM" on APUs is just carved out sy
t me to the bug and make sure your dmesg output is
attached and xorg log (if using X)?
Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Alex Deucher
On Mon, Jan 28, 2019 at 10:56 AM Marek Olšák wrote:
>
> From: Marek Olšák
>
> ---
> src/amd/common/ac_llvm_util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/commo
Reviewed-by: Alex Smith
for the series.
On Wed, 9 Jan 2019 at 13:37, Samuel Pitoiset
wrote:
> A simple Vulkan extension that allows apps to query size and
> usage of all exposed memory heaps.
>
> The different usage values are not really accurate because
> they are per drm-fd,
Thanks! I've played around with this a bit and it looks like it's behaving
how I'd expect.
One comment inline below...
On Tue, 8 Jan 2019 at 15:17, Samuel Pitoiset
wrote:
> A simple Vulkan extension that allows apps to query size and
> usage of all exposed memory heaps.
>
> The different usage
On Mon, 7 Jan 2019 at 17:20, Samuel Pitoiset
wrote:
>
> On 1/7/19 6:06 PM, Alex Smith wrote:
>
> Hi Samuel,
>
> Thanks for implementing this - I've been wanting this extension for a
> while so it's good it's finally available.
>
> This is just reporting
ap size - system wide usage of the heap + current app usage of the
heap)? (+ app usage since the spec says budget includes currently allocated
device memory)
Alex
On Mon, 7 Jan 2019 at 16:35, Samuel Pitoiset
wrote:
> A simple Vulkan extension that allows apps to query size and
> usage
Ping?
On Thu, Dec 20, 2018 at 10:13 AM Alex Deucher wrote:
>
> Signed-off-by: Alex Deucher
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> include/pci_ids/radeonsi_pci_ids.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/pci_ids/radeonsi_pci_id
Signed-off-by: Alex Deucher
Cc: mesa-sta...@lists.freedesktop.org
---
include/pci_ids/radeonsi_pci_ids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
b/include/pci_ids/radeonsi_pci_ids.h
index a2bc9213207..75ac7761bb4 100644
--- a/include/pci_ids
Ping?
Alex
On Fri, Dec 7, 2018 at 4:11 PM Alex Deucher wrote:
>
> Signed-off-by: Alex Deucher
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> include/pci_ids/radeonsi_pci_ids.h | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/pc
s, and a bunch of people begrudgingly going
along with it despite having limitations to their work flow. Every
conversion seems to go this way. It's not like these are new
sentiments.
Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Dec 13, 2018 at 11:41 AM Jason Ekstrand wrote:
>
> On Thu, Dec 13, 2018 at 9:56 AM Ilia Mirkin wrote:
>>
>> On Thu, Dec 13, 2018 at 10:52 AM Alex Deucher wrote:
>> >
>> > On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
>> > wrote:
>>
wed. All of the links click through to the source view rather
than the patch view.
Alex
>
> On 12/6/18 12:32 AM, Jordan Justen wrote:
> > This documents a process for using GitLab Merge Requests as an second
> > way to submit code changes for Mesa. Only one of the two methods is
&
No offense, but if someone did bring up a need for autotools would it
really make a difference? I believe the majority has spoken.
Alex
On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker wrote:
>
> Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
> final call
Signed-off-by: Alex Deucher
Cc: mesa-sta...@lists.freedesktop.org
---
include/pci_ids/radeonsi_pci_ids.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
b/include/pci_ids/radeonsi_pci_ids.h
index 35ea3559b02..f7defc4197a 100644
--- a
Signed-off-by: Alex Deucher
Cc: mesa-sta...@lists.freedesktop.org
---
include/pci_ids/radeonsi_pci_ids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
b/include/pci_ids/radeonsi_pci_ids.h
index f7defc4197a..a2bc9213207 100644
--- a/include/pci_ids
Reviewed-by: Alex Smith
On Wed, 5 Dec 2018 at 10:32, Samuel Pitoiset
wrote:
> If the driver used a compute shader for resetting a query pool,
> it should be completed when caches are flushed.
>
> This might reduce the number of stalls if operations are done
> between vkCmdReset
; while CP DMA copies are not. I plan to change this at some point.
>
> Reviewed-by: Samuel Pitoiset
>
> On 12/5/18 10:52 AM, Alex Smith wrote:
> > As done for vkCmdBeginQuery() already. Prevents timestamps from being
> > overwritten by previous vkCmdResetQueryPool() calls i
r for resetting the query
pool")
Signed-off-by: Alex Smith
---
src/amd/vulkan/radv_query.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 550abe307a..e226bcef6a 100644
--- a/src/
cious that it's 100% repro.
What's actually happening is that some of the timestamps are being written
before vkCmdResetQueryPool completes, so the reset ends up overwriting them
back to TIMESTAMP_NOT_READY. I've updated the test case on the bug to map
the buffer and check if any resul
Tested-by: Alex Smith
Thanks! s/Queryool/QueryPool/ in the subject, btw.
On Tue, 4 Dec 2018 at 15:52, Samuel Pitoiset
wrote:
> Because WAIT_REG_MEM can only wait for a 32-bit value, it's not
> safe to use it for timestamp queries. If we only wait on the low
> 32 bits of a time
On Thu, Nov 29, 2018 at 9:19 PM Jason Ekstrand wrote:
>
> On November 29, 2018 19:49:33 Alex Deucher wrote:
>
> > On Thu, Nov 29, 2018 at 8:26 PM Eric Anholt wrote:
> >>
> >> Emil Velikov writes:
> >>
> >>> Hi all,
> >>>
>
t; What do you guys think?
>
> Strongly disagree. We shouldn't be maintaining build systems for fun,
> we should be doing the minimum amount of build system work to get our
> actual work done quickly and reliably.
If someone has a legitima
Tested-by: Alex Smith
Confirmed it fixes both the testcase and the in-game bug it was causing.
Thanks!
On Tue, 27 Nov 2018 at 08:34, Samuel Pitoiset
wrote:
> cc stable?
>
> Reviewed-by: Samuel Pitoiset
>
> On 11/24/18 11:31 PM, Bas Nieuwenhuizen wrote:
> > Mirrors AMDVLK
it. In either case,
>
> Reviewed-by: Jason Ekstrand
>
> On Thu, Oct 25, 2018 at 5:25 AM Alex Smith
> wrote:
>
>> When depth testing is disabled, we shouldn't pay attention to the
>> specified depthCompareOp, and just treat it as always passing. Before,
>&
_face() would have incorrectly changed passOp to
VK_STENCIL_OP_KEEP.
Signed-off-by: Alex Smith
---
src/intel/vulkan/genX_pipeline.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 33f1f7832a..877a9
Thanks, that's fixed it for me.
On Tue, 23 Oct 2018 at 18:05, Liu, Leo wrote:
> JPEG was added after DRM version 3.26
>
> Signed-off-by: Leo Liu
> Fixes: 4558758c51749(amd/common: add vcn jpeg ip info query)
> Cc: Boyuan Zhang
> Cc: Alex Smith
> ---
> src
On Tue, Oct 23, 2018 at 1:06 PM Liu, Leo wrote:
>
> JPEG was added after DRM version 3.26
>
> Signed-off-by: Leo Liu
> Fixes: 4558758c51749(amd/common: add vcn jpeg ip info query)
> Cc: Boyuan Zhang
> Cc: Alex Smith
Reviewed-by: Alex Deucher
> ---
> src/amd/commo
Hi,
With this commit, both radeonsi and radv fail to load for me with:
amdgpu: amdgpu_query_hw_ip_info(vcn_jpeg) failed.
If I comment out that query in ac_gpu_info.c, then they work again. I'm
running kernel 4.18.7 with a Vega 64 - is the DRM version check on that
correct?
Thanks,
Alex
O
and present to a display
connected to an AMD card (tested HD 530 + Vega 64).
v2: Rebase on current master.
Signed-off-by: Alex Smith
---
src/intel/vulkan/anv_wsi_x11.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/vulkan/anv_wsi_x11.c b/src/intel/vulkan
and present to a display
connected to an AMD card (tested HD 530 + Vega 64).
Signed-off-by: Alex Smith
---
src/intel/vulkan/anv_wsi_x11.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/vulkan/anv_wsi_x11.c b/src/intel/vulkan/anv_wsi_x11.c
index 2feb5f1337
This patch never landed in git, is that intentional?
On Mon, 1 Oct 2018 at 17:46, Jason Ekstrand wrote:
> On Sun, Sep 30, 2018 at 1:04 PM Bas Nieuwenhuizen
> wrote:
>
>> ---
>> src/amd/vulkan/radv_device.c | 27 +++
>> src/amd/vulkan/radv_extensions.py | 1 +
>> 2
uot;
Fixes: 7e7ee82698 "ac: add support for 16bit buffer loads"
Cc: "18.2"
Signed-off-by: Alex Smith
---
src/amd/common/ac_nir_to_llvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index
Fixes the garbage output I was seeing with bloom enabled. Thanks!
Tested-by: Alex Smith
On Wed, 3 Oct 2018 at 20:16, Jason Ekstrand wrote:
> The ssa_for_alu_src helper will correctly handle swizzles and other
> source modifiers for you. The expansions for unpack_hal
Fixes a crash I see on Broadwell.
Tested-by: Alex Smith
Cc to stable for 18.2? The crash is reproducible there as well.
On Tue, 2 Oct 2018 at 23:25, Jason Ekstrand wrote:
> Previously, we just went ahead and emitted MI_BATCH_BUFFER_START as
> normal. If we are near enough to the end
Signed-off-by: Alex Deucher
Cc: mesa-sta...@lists.freedesktop.org
---
include/pci_ids/radeonsi_pci_ids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
b/include/pci_ids/radeonsi_pci_ids.h
index c8d30597230..dd2fc3b8f25 100644
--- a/include/pci_ids
I'd like to know more about this project and to know who to contact exactly
> for further queries regarding the same.
Julien Isorce , Leo Liu , or
Christian König would be possible mentors
for this project.
Alex
___
mesa-dev mailing list
m
On Fri, Aug 31, 2018 at 1:57 AM Dave Airlie wrote:
>
> From: Dave Airlie
>
> ac_surface.c: gfx6_compute_surface says
> /* DB doesn't support linear layouts. */
I think r100 was the last chip to support linear depth surfaces.
Alex
>
> Now if we expose linear depth
ard?
Improve the OpenCL driver in mesa. The shader ISA documents are
available on developer.amd.com and you can use the compute shader
support in the r600 OpenGL driver as a reference.
Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https:/
FWIW, putting "RADV" inside the brackets (e.g. " (RADV, LLVM ...)") would
still work for us.
On 17 August 2018 at 10:38, Samuel Pitoiset
wrote:
> Yeah, ignore this patch.
>
> On 8/17/18 11:25 AM, Alex Smith wrote:
>
>> All of our Vulkan games rely on t
All of our Vulkan games rely on the presence of "RADV" somewhere in the
device name string to distinguish between RADV and AMDVLK/GPU-PRO, and
that's used to check whether the driver version is supported, whether to
enable bug workarounds, etc. This will certainly break that.
Than
When you think you have a plan for a project
(e.g., what features the project will include, what are your
timelines, etc.) send it our for feedback start looking for a mentor
to help you with the project.
Good luck!
Alex
___
mesa-dev mailing list
mesa-d
According to the spec, these should apply to all read/write access
types (so would be equivalent to specifying all other access types
individually). Currently, they were doing nothing.
v2: Handle VK_ACCESS_MEMORY_WRITE_BIT in dstAccessMask.
Signed-off-by: Alex Smith
Cc: mesa-sta
On 20 July 2018 at 19:01, Jason Ekstrand wrote:
> On Fri, Jul 20, 2018 at 8:37 AM Lionel Landwerlin <
> lionel.g.landwer...@intel.com> wrote:
>
>> On 20/07/18 11:44, Alex Smith wrote:
>>
>> According to the spec, these should apply to all read/write access
&g
According to the spec, these should apply to all read/write access
types (so would be equivalent to specifying all other access types
individually). Currently, they were doing nothing.
Signed-off-by: Alex Smith
Cc: mesa-sta...@lists.freedesktop.org
---
src/intel/vulkan/anv_private.h | 6
rc/gallium/drivers/radeonsi/si_get.c | 1 +
> src/gallium/drivers/radeonsi/si_pipe.c | 3 ++-
> src/gallium/drivers/radeonsi/si_state.c | 1 +
> src/gallium/drivers/radeonsi/si_state_binning.c | 1 +
> 12 files changed, 26 insertions(+), 3 deletions(-)
Reviewed-by:
FWIW none of our released Vulkan games will be using these functions.
On 29 June 2018 at 03:28, Dieter Nützel wrote:
> Tested-by: Dieter Nützel
>
> on RX 580 with F1 2017.
>
> Dieter
>
>
> Am 28.06.2018 12:21, schrieb Samuel Pitoiset:
>
>> Always emitting a bottom-of-pipe event is quite dumb. I
Hi Dave,
I did a quick test with this on Rise of the Tomb Raider. It reduced the
time taken to create all pipelines for the whole game over 8 threads (with
RADV_DEBUG=nocache) from 12m24s to 11m35s. Nice improvement :)
Also didn't see any issues, so:
Tested-by: Alex Smith
Thanks,
Alex
Reviewed-by: Alex Smith
On 15 June 2018 at 17:52, Eric Engestrom wrote:
> It's a bit late to round up after an integer division.
>
> Fixes: de889794134e6245e08a2 "radv: Implement VK_AMD_shader_info"
> Cc: Alex Smith
> Signed-off-by: Eric Engestrom
> ---
&g
; +++ b/src/gallium/drivers/virgl/virgl_winsys.h
> @@ -31,7 +31,7 @@ struct pipe_fence_handle;
> struct winsys_handle;
> struct virgl_hw_res;
>
> -#define VIRGL_MAX_CMDBUF_DWORDS (16*1024)
> +#define VIRGL_MAX_CMDBUF_DWORDS (16*1025)
Maybe add a comment here? This seems like
Thanks, I've pushed it.
On 8 June 2018 at 10:38, Lionel Landwerlin
wrote:
> Sorry for missing that.
>
> Fixes: e73d136a023080 ("vulkan/wsi/x11: Implement FIFO mode.")
> Reviewed-by: Lionel Landwerlin
>
>
> On 01/06/18 12:16, Cameron Kumar wrote:
>
>> The queue_manager thread can access the imag
Any feedback on this?
On 1 June 2018 at 12:16, Cameron Kumar wrote:
> The queue_manager thread can access the images from x11_present_to_x11,
> hence this reorder prevents dereferencing of dangling pointers.
>
> Cc: "18.1"
> ---
> src/vulkan/wsi/wsi_common_x11.c | 6 +++---
> 1 file changed, 3
On 1 June 2018 at 22:51, Dylan Baker wrote:
> Quoting Samuel Pitoiset (2018-06-01 08:58:42)
> >
> >
> > On 06/01/2018 05:48 PM, Dylan Baker wrote:
> > > Quoting Alex Smith (2018-06-01 07:56:38)
> > >> On 1 June 2018 at 15:48, Dylan Baker wrote:
> &g
Oops. Thanks for tracking that down.
Reviewed-by: Alex Smith
On 2 June 2018 at 13:31, Bas Nieuwenhuizen wrote:
> Otherwise on pre-GFX9, if the constant layout allows both TESS_EVAL and
> GEOMETRY shaders, but the PIPELINE has only GEOMETRY, it would return the
> GEOMETRY shade
On 1 June 2018 at 16:58, Samuel Pitoiset wrote:
>
>
> On 06/01/2018 05:48 PM, Dylan Baker wrote:
>
>> Quoting Alex Smith (2018-06-01 07:56:38)
>>
>>> On 1 June 2018 at 15:48, Dylan Baker wrote:
>>>
>>> Quoting Alex Smith (2018-
On 1 June 2018 at 15:48, Dylan Baker wrote:
> Quoting Alex Smith (2018-05-31 08:44:18)
> > With GFX9 merged shaders, active_stages would be set to the original
> > stages specified if shaders were not cached, but to the stages still
> > present after merging if they were.
On 31 May 2018 at 21:15, Bas Nieuwenhuizen wrote:
> On Thu, May 31, 2018 at 5:44 PM, Alex Smith
> wrote:
> > This was not previously handled correctly. For example,
> > push_constant_stages might only contain MESA_SHADER_VERTEX because
> > only that stage was change
With GFX9 merged shaders, active_stages would be set to the original
stages specified if shaders were not cached, but to the stages still
present after merging if they were.
Be consistent and use the original stages.
Signed-off-by: Alex Smith
Cc: "18.1"
---
src/amd/vulkan/radv_pipe
This was being handled in a few different places, consolidate it into a
single radv_get_shader() function.
Signed-off-by: Alex Smith
Cc: "18.1"
---
src/amd/vulkan/radv_cmd_buffer.c | 20
src/amd/vulkan/radv_pipeline.c | 38 -
ave made the address get emitted twice.
Signed-off-by: Alex Smith
Cc: "18.1"
---
src/amd/vulkan/radv_cmd_buffer.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index da9591b9a5..c6a2d6c5b
Hmm, the crash I was seeing is in RenderDoc from one of its own shaders.
Maybe it's missing some support checks? I'll look into it.
If you're happy with this though, I'll push it.
Thanks,
Alex
On 30 May 2018 at 21:17, Marek Olšák wrote:
> Reviewed-by: Marek Olšák
).
Signed-off-by: Alex Smith
Cc: "18.1"
---
src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index
Any more thoughts on this? Any objections to it going to stable as well (it
fixes bugs, but is quite a large change)?
Thanks,
Alex
On 19 April 2018 at 09:27, Matthew Nicholls
wrote:
> On 18/04/18 22:56, Dave Airlie wrote:
>
> On 18 April 2018 at 00:31, Matthew Nicholls
On 10 April 2018 at 15:49, Juan A. Suarez Romero
wrote:
> On Tue, 2018-04-03 at 10:58 +0100, Alex Smith wrote:
> > I don't know exactly what's causing it, no. I noticed the issue was
> fixed on master so just bisected to this.
> >
&
so but presumably you guys
> don't actually know the exact shader combination thats tripping things up?
>
>
> On 03/04/18 19:36, Samuel Pitoiset wrote:
>
>> This fixes a rendering issue with Wolfenstein 2 as well. A backport
>> sounds reasonable to me.
>>
>
e there as
well.
Thanks,
Alex
On 7 March 2018 at 20:43, Marek Olšák wrote:
> For the series:
>
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Tue, Mar 6, 2018 at 8:40 PM, Timothy Arceri
> wrote:
> > These helpers insert the basic block in the same order as they
> >
On 16 March 2018 at 12:46, Juan A. Suarez Romero
wrote:
> On Fri, 2018-03-16 at 13:40 +0100, Juan A. Suarez Romero wrote:
> > On Fri, 2018-03-16 at 12:17 +0000, Alex Smith wrote:
> > > Hi Juan,
> > >
> > > On 16 March 2018 at 11:42, Juan A. Suarez
mp libdrm_amdgpu version requirement.
>
> (cherry picked from commit 52be440f48ac7c337f6604846bb6f0cfd88e7118)
>
>
> commit 6ddf838def69036a48524e2f5ae79fb01170e59c
> Author: Bas Nieuwenhuizen
>
> radv: Always lower indirect derefs after nir_lower_global_vars_to_
> local.
On 13 March 2018 at 19:14, Dave Airlie wrote:
> On 13 March 2018 at 01:38, Alex Smith wrote:
> > From the spec:
> >
> > "When copying between compressed and uncompressed formats the
> > extent members represent the texel dimensions of the source
> &
at we copy the correct number of layers
for 2D to 3D copies.
Fixes: 7b890a36 "radv: Fix vkCmdCopyImage for 2d slices into 3d Images"
Cc:
Signed-off-by: Alex Smith
---
src/amd/vulkan/radv_meta_copy.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --
ou have ASAP to meet a schedule and fix
it up later which seems to contradict the whole idea of group review
and making sure your code is the best it can be. In my experience,
one of the biggest concerns people that are not familiar with open
source tend to have is that it takes too long to get upstream because
of all the code review. I'm not really trying to argue, I realize it
is a fine line...
Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Tested-by: Alex Smith
Thanks!
On 9 March 2018 at 16:21, Bas Nieuwenhuizen wrote:
> The vulkan API is not ideal as it does not allow us have a
> shared limit.
>
> Feral needs 15+6 for one of their games, and I'm not a fan
> of overcommitting the limits, so increase the
Ping.
Maybe it'd be better to just increase MAX_DYNAMIC_BUFFERS? I can't see any
side effects of that other than increasing the size of radv_cmd_buffer?
Alex
On 5 March 2018 at 09:59, Alex Smith wrote:
> I just checked what Rise of the Tomb Raider is using. Maximum it hits
On Wed, Mar 7, 2018 at 3:34 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> We can get it from si_screen.
Acked-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/si_compute.c | 3 +--
> src/gallium/drivers/radeonsi/si_shader.h| 4 +---
> src/gal
On Wed, Mar 7, 2018 at 3:35 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Tested by our OpenCL team.
>
> Fixes: 9c499e6759b26c5e "st/mesa: don't invoke st_finalize_texture &
> st_convert_sampler for TBOs"
Acked-by: Alex Deucher
> ---
>
On Wed, Mar 7, 2018 at 3:34 PM, Marek Olšák wrote:
> From: Marek Olšák
>
Reviewed-by: Alex Deucher
> ---
> src/amd/common/ac_gpu_info.c | 11 +++
> src/amd/common/ac_gpu_info.h | 2 ++
> 2 files changed, 13 insertions(+)
>
> diff --git a/src/amd/common/ac_gpu
On Wed, Mar 7, 2018 at 3:34 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> This is only required with the latest libdrm.
>
> This fixes 32-bit support with high addresses.
> (and possibly 64-bit support too because the high bits need to be masked out)
Acked-by: Alex Deuc
On Wed, Mar 7, 2018 at 3:34 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Cc: 17.3 18.0
Reviewed-by: Alex Deucher
> ---
> src/amd/common/ac_gpu_info.c | 21 -
> src/amd/common/ac_gpu_info.h | 1 +
> src/gal
1 - 100 of 1026 matches
Mail list logo
