From: Dave Airlie
This might be a bit over optimising.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 9 +++---
src/amd/vulkan/radv_descriptor_set.c | 55 +++-
src/amd/vulkan/radv_private.h| 1 +
3 files changed, 41 insertions(+)
From: Dave Airlie
There's no point recalculating these the whole time on descriptor
emission, just store them at pipeline creation.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 14 ++--
src/amd/vulkan/radv_pipeline.c | 49 ++--
On Fri, 2017-11-03 at 12:01 -0400, Ilia Mirkin wrote:
> On Fri, Nov 3, 2017 at 6:56 AM, Iago Toral Quiroga > wrote:
> > Regarding location aliasing requirements, the OpenGL spec says:
> >
> > "Further, when location aliasing, the aliases sharing the
> > location
> > must have the same underl
On 11/06/2017 04:08 AM, Chih-Wei Huang wrote:
2017-11-03 19:02 GMT+08:00 Tapani Pälli :
On 11/03/2017 12:30 PM, Chih-Wei Huang wrote:
2017-11-03 15:47 GMT+08:00 Tapani Pälli :
Hi Chih-Wei;
This looks good to me. Only thing that causes a bit of headache is ...
what
is the difference between P
On 4 November 2017 at 10:01, Marek Olšák wrote:
> Not sure if the "HW" prefix everywhere makes sense since gallium
> doesn't imply there is a hardware driver behind it, but I don't really
> care much.
Well it's more that the atomic's aren't normal ssbo atomics, and there is
dedicated hardware for
>> +Hardware Atomic Register File
>> +^
>> +
>> +Hardware atomics are declared as a 2D array with an optional array id.
>> +
>> +The first member of the dimension is the buffer resource the atomic
>> +is located in.
>> +The second member is a range into the buffer resour
radeon_emit(cs, PKT3(PKT3_NOP, 0, 0));
>> + radeon_emit(cs, reloc);
>> + }
>> + ++rctx->append_fence_id;
>> + reloc = radeon_add_to_buffer_list(&rctx->b, &rctx->b.gfx,
>> +
>> r600_resource(rctx->append_fence),
>> +
From: Dave Airlie
This should reduce some pointless loops.
v2: fix missing check which causes crashes with compute shaders
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 53 +++-
src/amd/vulkan/radv_pipeline.c | 2 ++
src/amd/vulkan/ra
From: Dave Airlie
This should reduce some pointless loops.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 51 ++--
src/amd/vulkan/radv_pipeline.c | 2 ++
src/amd/vulkan/radv_private.h| 1 +
3 files changed, 16 insertions(+), 38 del
This matches nvc0 behavior, tested with the fbo-float-nan piglit.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_screen.
Radeonsi also sets this flag.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103544
Signed-off-by: Ilia Mirkin
---
This needs testing with the fbo-float-nan piglit that was recently added. Just
guessing that this is the right flag to set here.
src/gallium/drivers/r600/evergreen_state.c
From: Dave Airlie
The next patch will try and avoid calling the indirect function.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 40 ++--
src/amd/vulkan/radv_descriptor_set.c | 6 +++---
src/amd/vulkan/radv_device.c | 14 ++--
From: Dave Airlie
We can avoid adding the buffer in the non-local case, this will
avoid all the overhead of the indirect call.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_radeon_winsys.h | 4
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 2 +-
src/amd/vulkan/winsys/amdg
From: Dave Airlie
The function that calls us has just added the buffer to the
list already, no need to try and add it again.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/ra
From: Dave Airlie
This register is the same on all gpus so far, so emit it in one
place and also for the pre-gfx9 gpus set the value in the pipeline
creation.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 14 +++---
src/amd/vulkan/radv_pipeline.c | 1 +
2 files c
From: Dave Airlie
This moves some calculations of register values into the pipeline
construction, it saves looking at outinfo in the cmd buffer emit.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 29 -
src/amd/vulkan/radv_pipeline.c | 21 ++
On Mon, Nov 6, 2017 at 12:44 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This is just a simple refactor.
>
> Signed-off-by: Dave Airlie
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 20
> src/amd/vulkan/radv_meta.c | 3 +--
> src/amd/vulkan/radv_private.h| 4 +++
Reviewed-by: Bas Nieuwenhuizen
On Mon, Nov 6, 2017 at 1:37 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> If we allocate attachments in the begin command buffer due to the
> render pass continue bit, we were leaking them.
>
> Since renderpasses inside a cmd buffer malloc/free these properly,
>
From: Dave Airlie
If we allocate attachments in the begin command buffer due to the
render pass continue bit, we were leaking them.
Since renderpasses inside a cmd buffer malloc/free these properly,
and set to NULL, we just need to call free at end.
Fixes a memory leak with multithreading demo.
https://bugs.freedesktop.org/show_bug.cgi?id=103586
Bug ID: 103586
Summary: OpenCL/Clover: AMD Turks: corrupt output buffer
(depending on dimension order?)
Product: Mesa
Version: 17.2
Hardware: Other
OS: All
From: Dave Airlie
This is just a simple refactor.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 20
src/amd/vulkan/radv_meta.c | 3 +--
src/amd/vulkan/radv_private.h| 4
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/s
From: Dave Airlie
This just removes a hole in the cmd_state and packs some bools
together.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_private.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 51bdde
From: Dave Airlie
Instead of storing all the pointers and zeroing them all out,
just store a valid bitmask in the state. This also moves
the CmdBindPipeline path down the cpu usage path for the
multithreading demo as it no longer has to traverse MAX_SETS
to find the active descriptor sets.
Signe
From: Dave Airlie
This isn't required to be cleared, since buffers are only linked
by vertex elements, so if elements are clear then no buffers
should be referenced.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_cmd_buffer.c | 6 +++---
src/amd/vulkan/radv_private.h| 2 +-
2 files cha
Fixes: 379b24a40d3d "i965: make use of nir linking"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103537
---
Jason's fixes referenced in the bug report help a little,
however there are still issues with the vector backend and
I don't have time to investigate right now so just disable it.
On Sunday, November 5, 2017 11:17:06 AM PST Rob Clark wrote:
> Overlooked initially, be we need to remap the SSBO index for this as
> well.
>
> Signed-off-by: Rob Clark
> ---
> src/compiler/nir/nir_lower_atomics_to_ssbo.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/compiler/nir
Rb
On November 5, 2017 11:17:18 Rob Clark wrote:
Overlooked initially, be we need to remap the SSBO index for this as
well.
Signed-off-by: Rob Clark
---
src/compiler/nir/nir_lower_atomics_to_ssbo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compiler/nir/nir_lower_atomics_to_ss
On Sun, Nov 5, 2017 at 1:13 PM, Tobias Klausmann
wrote:
>
> On 11/5/17 4:48 PM, Ilia Mirkin wrote:
>> This enables std430-style packing for UBOs which aren't otherwise marked
>> as std140.
>>
>> There might be small register lifetime changes as a result of removed
>> duplicate loads in some cases,
Overlooked initially, be we need to remap the SSBO index for this as
well.
Signed-off-by: Rob Clark
---
src/compiler/nir/nir_lower_atomics_to_ssbo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compiler/nir/nir_lower_atomics_to_ssbo.c
b/src/compiler/nir/nir_lower_atomics_to_ssbo.c
in
On 11/5/17 4:48 PM, Ilia Mirkin wrote:
> This enables std430-style packing for UBOs which aren't otherwise marked
> as std140.
>
> There might be small register lifetime changes as a result of removed
> duplicate loads in some cases, but this seems worth it overall.
A before/after shader-db run
On Sun, Nov 05, 2017 at 04:31:40PM +0100, Christian Gmeiner wrote:
> > +#ifndef H_ETNAVIV_TEXTURE_PLAIN
> > +#define H_ETNAVIV_TEXTURE_PLAIN
> > +
> > +#include
> > +
> > +#include "pipe/p_context.h"
> > +#include "pipe/p_state.h"
> > +
> > +#include "hw/state_3d.xml.h"
>
> Is this include neede
This enables std430-style packing for UBOs which aren't otherwise marked
as std140.
There might be small register lifetime changes as a result of removed
duplicate loads in some cases, but this seems worth it overall.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_fr
2017-10-30 17:17 GMT+01:00 Wladimir J. van der Laan :
> This will be shared with the texture descriptor path.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_texture.c | 40
> +--
> src/gallium/driv
2017-10-30 17:17 GMT+01:00 Wladimir J. van der Laan :
> Prepare for two texture handling paths, the descriptor-based
> path will be added in a future commit. These are structured
> so that the texture implementation handles its own state
> emission.
>
> Signed-off-by: Wladimir J. van der Laan
Rev
2017-10-30 17:17 GMT+01:00 Wladimir J. van der Laan :
> Want to be able to emit state from the texture implementation.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_emit.c | 83
> --
> src/gal
2017-10-30 17:17 GMT+01:00 Wladimir J. van der Laan :
> This needs to be shared between texture_plain and texture_desc.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_emit.c| 12
> src/gallium/drivers/etna
Reviewed-by: Christian Gmeiner
2017-11-05 16:23 GMT+01:00 Christian Gmeiner :
> 2017-11-05 13:38 GMT+01:00 Wladimir :
+ if (!ctx->specs.use_blt) {
+ /* This (ab)uses the RS as a plain buffer memset().
+ * Currently uses a fixed row size of 64 bytes. Some
2017-11-05 13:38 GMT+01:00 Wladimir :
>>> + if (!ctx->specs.use_blt) {
>>> + /* This (ab)uses the RS as a plain buffer memset().
>>> + * Currently uses a fixed row size of 64 bytes. Some benchmarking
>>> with
>>> + * different sizes may be in order. */
>>> +
2017-10-30 17:17 GMT+01:00 Wladimir J. van der Laan :
> Need this to efficiently emit texture descriptor invalidations.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_context.c | 1 +
> src/gallium/drivers/etnaviv/etnaviv_
2017-10-30 17:17 GMT+01:00 Wladimir J. van der Laan :
> Track varying component offset of the point size output, as well as
> provide the offset of the point coord input.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_comp
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> Update state objects to add new state, and emit function to emit new
> state.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_emit.c | 247
> +++--
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> - This core must load shaders from memory (AFAIK)
> - Yet another new location for UNIFORMS
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_screen.c | 19 +
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> Update context reset for HALTI3..HALTI5, sorting states for the HALTI
> version that has them.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_context.c | 37
> ++
https://bugs.freedesktop.org/show_bug.cgi?id=103579
Bug ID: 103579
Summary: Vertex shader causes compiler to crash in SPIRV-to-NIR
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: n
>> + if (!ctx->specs.use_blt) {
>> + /* This (ab)uses the RS as a plain buffer memset().
>> + * Currently uses a fixed row size of 64 bytes. Some benchmarking
>> with
>> + * different sizes may be in order. */
>> + struct etna_bo *ts_bo = etna_resource(surf->
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> RS align is not necessary and might even be harmful when using the BLT
> engine for blitting.
>
> Signed-off-by: Wladimir J. van der Laan
> ---
> src/gallium/drivers/etnaviv/etnaviv_resource.c | 15 +
> src/gallium/drivers/etnaviv/et
On Sun, Nov 5, 2017 at 1:09 PM, Christian Gmeiner
wrote:
> 2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
>> Prepare for BLT-based blitting path by moving RS-based
>> blitting to its own implementation file.
>>
>> Signed-off-by: Wladimir J. van der Laan
>> ---
>> src/gallium/drivers/etnav
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> Add an implemenation of key clear_blit functions using the BLT engine
> that replaced the RS on GC7000.
>
> Signed-off-by: Wladimir J. van der Laan
> ---
> src/gallium/drivers/etnaviv/Makefile.sources | 1 +
src/gallium/drivers/etnav
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> Prepare for BLT-based blitting path by moving RS-based
> blitting to its own implementation file.
>
> Signed-off-by: Wladimir J. van der Laan
> ---
> src/gallium/drivers/etnaviv/Makefile.sources | 1 +
src/gallium/drivers/etnaviv/mes
2017-11-05 13:02 GMT+01:00 Christian Gmeiner :
> 2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
>> Add a low-level library for using the BLT engine from the etnaviv
>> driver.
>>
>
> As I have no HW to test it I am just looking at the code and write
> down what I think :)
>
> There are some
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> Add a low-level library for using the BLT engine from the etnaviv
> driver.
>
As I have no HW to test it I am just looking at the code and write
down what I think :)
There are some code style issues: https://www.mesa3d.org/codingstyle.html
2017-11-05 12:54 GMT+01:00 Wladimir :
> On Sun, Nov 5, 2017 at 12:47 PM, Christian Gmeiner
> wrote:
>> 2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
>>> When the BLT is involved as source or target, add an extra BLT
>>> enable/disable sequence around the sync sequence.
>>>
>>
>> Does this
On Sun, Nov 5, 2017 at 12:47 PM, Christian Gmeiner
wrote:
> 2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
>> When the BLT is involved as source or target, add an extra BLT
>> enable/disable sequence around the sync sequence.
>>
>
> Does this mean we are doing lazy blit operations? Or why i
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> When the BLT is involved as source or target, add an extra BLT
> enable/disable sequence around the sync sequence.
>
Does this mean we are doing lazy blit operations? Or why is this needed at all?
> Signed-off-by: Wladimir J. van der Laan
>
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> This is used by HALTI2+ (GC3000+) when drawing with DRAW_INSTANCED.
>
> It is also necessary when switching between integer and floating point
> vertex element formats.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmein
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> The HALTI level is an indication of the gross architecture of the GPU.
> It determines for significant part what feature level the GPU has, what
> state (especially frontend state) is there, and where it is located.
>
> Signed-off-by: Wladimir
2017-10-30 17:16 GMT+01:00 Wladimir J. van der Laan :
> The relocation structure is never changed by submitting it.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
> ---
> src/gallium/drivers/etnaviv/etnaviv_emit.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion
57 matches
Mail list logo
