Mauro Rossi 於 2019年3月4日 週一 上午3:58寫道：
>
> Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
> Rename the variable labels according to targets and python scripts
> Align the building rules as per Automake for simplification
>
> Fixes building errors during rebuils due to
On 3/5/19 1:44 AM, Alyssa Rosenzweig wrote:
I get roughly the same demos working with it as with Arm's driver, but
there's lots of improvements to be made (mostly in the kernel) to how
memory is managed and jobs are scheduled.
Which demos have regressed, just so we can keep track?
One is
On 3/5/19 3:29 AM, Dave Airlie wrote:
On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote:
On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig wrote:
Why aren't we using regular dma-buf fences here? The submit ioctl
should be able to take a number of in fences to wait on and return an
out
On 3/5/19 1:25 AM, Alyssa Rosenzweig wrote:
Reviewed-by: Alyssa Rosenzweig
Out of curiosity, when would this code path be needed? Was this a
problem on the non-DRM driver too, or just the new kernel which makes
heavier use of real BOs?
With non-DRM this code doesn't execute (at least on the
On 3/4/19 8:52 PM, Rob Herring wrote:
On Mon, Mar 4, 2019 at 1:38 PM Alyssa Rosenzweig wrote:
unsigned transient_count =
ctx->transient_pools[ctx->cmdstream_i].entry_index*ctx->transient_pools[0].entry_size
+ ctx->transient_pools[ctx->cmdstream_i].entry_offset;
-
On Mon, 2019-03-04 at 15:36 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Fri, 2019-03-01 at 19:04 -0800, Francisco Jerez wrote:
> > > Iago Toral writes:
> > >
> > > > On Thu, 2019-02-28 at 09:54 -0800, Francisco Jerez wrote:
> > > > > Iago Toral writes:
> > > > >
> > > > > >
Replace done using:
find ./src -type f -exec sed -i -- \
's/glsl_type_is_struct(/glsl_type_is_struct_or_ifc(/g' {} \;
---
src/amd/common/ac_nir_to_llvm.c | 2 +-
src/amd/vulkan/radv_nir_to_llvm.c| 2 +-
Replace done using:
find ./src -type f -exec sed -i -- \
's/record_location_offset(/struct_location_offset(/g' {} \;
---
src/amd/common/ac_nir_to_llvm.c| 4 ++--
src/compiler/glsl/gl_nir_lower_samplers_as_deref.c | 2 +-
src/compiler/glsl_types.cpp| 4
Replace done using:
find ./src -type f -exec sed -i -- \
's/get_record_instance(/get_struct_instance(/g' {} \;
---
src/compiler/glsl/ast_to_hir.cpp| 2 +-
src/compiler/glsl/tests/array_refcount_test.cpp | 2 +-
src/compiler/glsl_types.cpp | 6 +++---
---
src/compiler/glsl_types.cpp | 16
src/compiler/glsl_types.h | 4 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index bc9bf1380b2..50320a46e98 100644
--- a/src/compiler/glsl_types.cpp
+++
Replace was done using:
find ./src -type f -exec sed -i -- \
's/is_record(/is_struct(/g' {} \;
---
src/compiler/glsl/ast_function.cpp| 4 +--
src/compiler/glsl/ast_to_hir.cpp | 22 ++--
src/compiler/glsl/glsl_parser_extras.cpp | 2 +-
> The patches in this MR are needed so the nondrm backend keeps working:
>
> https://gitlab.freedesktop.org/panfrost/nondrm/merge_requests/1
Oh, thank you! I didn't see this the first time around; ignore all the
comments about nondrm regressions. Sorry for the confusion.
-A
> You should more likely be using syncobjects, not fences.
...I still don't know what either of them actually are...?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie wrote:
>
> On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote:
> >
> > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig
> > wrote:
> > >
> > > > Why aren't we using regular dma-buf fences here? The submit ioctl
> > > > should be able to take a
On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg wrote:
>
> On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig wrote:
> >
> > > Why aren't we using regular dma-buf fences here? The submit ioctl
> > > should be able to take a number of in fences to wait on and return an
> > > out fence if requested.
On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig wrote:
>
> > Why aren't we using regular dma-buf fences here? The submit ioctl
> > should be able to take a number of in fences to wait on and return an
> > out fence if requested.
>
> Ah-ha, that sounds like the "proper" approach for mainline.
> Why aren't we using regular dma-buf fences here? The submit ioctl
> should be able to take a number of in fences to wait on and return an
> out fence if requested.
Ah-ha, that sounds like the "proper" approach for mainline. Much of this
was (incorrectly) inherited from the Arm driver. Thank
On Mon, Mar 4, 2019 at 4:43 PM Alyssa Rosenzweig wrote:
>
> Wooo!!!
>
> Seeing this patch in my inbox has been some of the best news all day!
>
> Without further ado, my (solicited?) comments:
>
> > +/* Copyright 2018, Linaro, Ltd., Rob Herring */
>
> Please triple check upstream that this
> I get roughly the same demos working with it as with Arm's driver, but
> there's lots of improvements to be made (mostly in the kernel) to how
> memory is managed and jobs are scheduled.
Which demos have regressed, just so we can keep track?
___
Wooo!!!
Seeing this patch in my inbox has been some of the best news all day!
Without further ado, my (solicited?) comments:
> +/* Copyright 2018, Linaro, Ltd., Rob Herring */
Please triple check upstream that this license is okay; the other files
in include/drm-uapi are BSDish.
> +/*
Reviewed-by: Alyssa Rosenzweig
Out of curiosity, when would this code path be needed? Was this a
problem on the non-DRM driver too, or just the new kernel which makes
heavier use of real BOs?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 2019-03-04 15:21:26, Mauro Rossi wrote:
> Hi,
> On Mon, Mar 4, 2019 at 7:50 PM Mauro Rossi wrote:
> >
> > Il lun 4 mar 2019, 18:59 Dylan Baker ha scritto:
> >>
> >> I wrote c812, and I'd be very happy to revert it. The problem that I ran
> >> into
> >> was putting it in a place that android,
Hi Drew
On Mon, Mar 4, 2019 at 8:01 PM Drew Davenport wrote:
>
> We ran into a similar issue with this syscall in Chrome OS. This patch
> addressed the issue:
> https://lists.freedesktop.org/archives/mesa-dev/2019-February/215721.html
>
> Does it help in this case as well?
That doesn't work,
Iago Toral writes:
> On Fri, 2019-03-01 at 19:04 -0800, Francisco Jerez wrote:
>> Iago Toral writes:
>>
>> > On Thu, 2019-02-28 at 09:54 -0800, Francisco Jerez wrote:
>> > > Iago Toral writes:
>> > >
>> > > > On Wed, 2019-02-27 at 13:47 -0800, Francisco Jerez wrote:
>> > > > > Iago Toral
Hi,
On Mon, Mar 4, 2019 at 7:50 PM Mauro Rossi wrote:
>
> Hi,
> Sounds good to me.
>
> The way it could have been prevented was to avoid having fp64 generated file
> as the only one with with different path in sources.
>
> Could you just confirm that inc_compiler is not needed in
>
https://bugs.freedesktop.org/show_bug.cgi?id=109818
--- Comment #2 from farmboy0+freedesk...@googlemail.com ---
a03101c717846f2f0d548dc5c713528329234e6d is the first bad commit
commit a03101c717846f2f0d548dc5c713528329234e6d
Author: Bas Nieuwenhuizen
Date: Fri Feb 22 14:24:28 2019 +0100
> "is_t6xx" is not going to scale. We need to do feature and issues.
> Doesn't have to be in this series though.
Indeed, that's not my concern for this particular series. On that note,
I suppose it doesn't matter right now; we only advertise out-of-the-box
support for T860 so it doesn't matter if
On Mon, Mar 4, 2019 at 1:38 PM Alyssa Rosenzweig wrote:
>
> > unsigned transient_count =
> > ctx->transient_pools[ctx->cmdstream_i].entry_index*ctx->transient_pools[0].entry_size
> > + ctx->transient_pools[ctx->cmdstream_i].entry_offset;
> > - printf("Uploaded transient %d
On Mon, Mar 4, 2019 at 10:12 AM Tomeu Vizoso wrote:
>
> This backend interacts with the new DRM driver for Midgard GPUs which is
> currently in development.
>
> When using this backend, Panfrost has roughly on-par functionality as
> when using the non-DRM driver from Arm.
>
> Signed-off-by: Tomeu
On Mon, Mar 4, 2019 at 1:35 PM Alyssa Rosenzweig wrote:
>
> > /* If set, we'll require the use of single render-target framebuffer
> > * descriptors (SFBD), for older hardware -- specifically, > If
>
> This require_sfbd field should also be set at the same time. In
> particular, we'll want a
> unsigned transient_count =
> ctx->transient_pools[ctx->cmdstream_i].entry_index*ctx->transient_pools[0].entry_size
> + ctx->transient_pools[ctx->cmdstream_i].entry_offset;
> - printf("Uploaded transient %d bytes\n", transient_count);
> + //printf("Uploaded transient %d
> + __u32 out_sync;
Why __u32 instead of u32 or uint32_t? I don't think we use the prefixed
types anywhere else.
> + int (*init_context) (struct panfrost_context *ctx);
> + void (*fence_reference) (struct pipe_screen *screen,
> + struct pipe_fence_handle
Reveiewed-by: Alyssa Rosenzweig
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Alyssa Rosenzweig
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> /* If set, we'll require the use of single render-target framebuffer
> * descriptors (SFBD), for older hardware -- specifically, +ctx->is_t6xx = pscreen->driver->query_gpu_version(pscreen) == 0x0750;
Where did this magic number come from? Is that for T760 or actually T600
or
Reviewed-by: Alyssa Rosenzweig
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
We ran into a similar issue with this syscall in Chrome OS. This patch
addressed the issue:
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215721.html
Does it help in this case as well?
On Wed, Feb 27, 2019 at 4:13 PM wrote:
>
> From: Marc-André Lureau
>
> Since commit
Some applications, like google-chrome, cause the state tracker to
destroy sampler/resource views from a context other than the one
which was used to create it. Previously, we just leaked the view.
Now, when we're in this situation we declare the view a zombie and
add it to a list of zombie views
Hi,
Sounds good to me.
The way it could have been prevented was to avoid having fp64 generated
file as the only one with with different path in sources.
Could you just confirm that inc_compiler is not needed in
src/mesa/meson.build, and provide R-b so that I will proceed with push?
I've tried
Quoting Mauro Rossi (2019-03-04 01:21:05)
> Hi Tapani,
> On Mon, Mar 4, 2019 at 6:51 AM Tapani Pälli wrote:
> >
> > Hi;
> >
> > On 3/3/19 10:10 PM, Mauro Rossi wrote:
> > > Necessary to avoid building error in Android,
> > > due to 'compiler/glsl/float64_glsl.h' file not found
> > >
> > > Fixes:
For the series,
Reviewed-by: Neha Bhende
Regards,
Neha
From: Brian Paul
Sent: Monday, March 4, 2019 9:20 AM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende
Subject: [PATCH 2/2] svga: silence array out of bounds warning
MinGW release build
Hi Brian,
For both, if you need:
Reviewed-by: Mathias Fröhlich
best
Mathias
On Monday, 4 March 2019 18:20:57 CET Brian Paul wrote:
> MinGW release builds warns about use of a possbily uninitialized
> variable here.
> ---
> src/gallium/drivers/svga/svga_pipe_rasterizer.c | 2 +-
> 1 file
MinGW release build complains about a possible out-of-bounds
array access. Test i < 4 to silence it.
---
src/gallium/drivers/svga/svga_tgsi_insn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/svga/svga_tgsi_insn.c
MinGW release builds warns about use of a possbily uninitialized
variable here.
---
src/gallium/drivers/svga/svga_pipe_rasterizer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/svga/svga_pipe_rasterizer.c
Hi,
On Friday, 1 March 2019 16:50:13 CET Brian Paul wrote:
> The series looks OK to me.
>
> Reviewed-by: Brian Paul
Thanks!
Pushed!
Mathias
>
> On 02/28/2019 11:18 PM, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich
> >
> > Now that the buffer object usage history tracks if it
Hi,
the patches in this series get Panfrost working with the DRM driver that
Rob Herring and I have been working on lately:
https://gitlab.freedesktop.org/panfrost/linux/tree/panfrost-5.0-rc4
I get roughly the same demos working with it as with Arm's driver, but
there's lots of improvements to
Implement resource_get_handle for non-scanout cases.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_resource.c | 37 +++--
src/gallium/drivers/panfrost/pan_screen.h | 1 +
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 776469c3e411..ac58411b265d 100644
---
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 19 +--
src/gallium/drivers/panfrost/pan_context.h | 3 +++
src/gallium/drivers/panfrost/pan_screen.h | 1 +
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git
It will be used by the DRM backend to store GEM handles from the kernel.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_allocate.h | 1 +
src/gallium/drivers/panfrost/pan_resource.h | 2 ++
2 files changed, 3 insertions(+)
diff --git
This backend interacts with the new DRM driver for Midgard GPUs which is
currently in development.
When using this backend, Panfrost has roughly on-par functionality as
when using the non-DRM driver from Arm.
Signed-off-by: Tomeu Vizoso
---
include/drm-uapi/panfrost_drm.h| 128
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_allocate.c | 4 ++--
src/gallium/drivers/panfrost/pan_resource.c | 2 +-
src/gallium/drivers/panfrost/pan_screen.h| 6 --
src/gallium/drivers/panfrost/pan_wallpaper.c | 2 +-
4 files changed, 4 insertions(+), 10
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 11 +++
src/gallium/drivers/panfrost/pan_context.h | 7 +++
src/gallium/drivers/panfrost/pan_screen.c | 11 ++-
src/gallium/drivers/panfrost/pan_screen.h | 11 ++-
4 files changed, 30
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/pan_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index b419f25224f2..776469c3e411 100644
---
If alignement is 0, offets returned by
radv_cmd_buffer_upload_alloc() are always 0. These two
virtual addresses were pointing at the same location.
v2: - add an asertion that checks if alignment is power of two
Cc: 18.3 19.0
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c
Reviewed-by: Tapani Pälli
On 3/4/19 2:45 PM, Mauro Rossi wrote:
Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification
Fixes building errors during
Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification
Fixes building errors during rebuils due to missing dependencies
(v2) Fixed a missing
Now that we propagate constants to the first source of 2src instructions we
see more opportunities of constant folding in the backend.
v2:
- The hardware only uses 5 bits (or 6 bits for Q/UQ) from the shift
count parameter in SHL/SHR instructions, so do the same in constant
propagation
And let combine constants promote the constants if needed.
---
src/intel/compiler/brw_fs_combine_constants.cpp | 2 ++
src/intel/compiler/brw_fs_copy_propagation.cpp | 4
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/intel/compiler/brw_fs_combine_constants.cpp
Even if it is not supported by the hardware, we will fix it up
in the combine constants pass.
v2:
- This will enable new constant folding opportunities in the algebraic pass
for MUL or ADD with types other than F, so do not assert on that type.
For now we just skip anything that is not
This v2 addresses comments to v1, specifically constant folding of SHR/SHL
instructions now only take up to 5-bits from the shift count parameter, just
like the hardware does.
Also, patch 2 has been fixed to avoid hitting assertions that would then be
fixed by patch 3. I sent the series up to
If alignement is 0, offets returned by
radv_cmd_buffer_upload_alloc() are always 0. These two
virtual addresses were pointing at the same location.
Cc: 18.3 19.0
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
https://bugs.freedesktop.org/show_bug.cgi?id=109807
--- Comment #2 from Lionel Landwerlin ---
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/374
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing
Still unreviewed.
Sam
On Thu, 2019-02-21 at 12:08 +0100, Samuel Iglesias Gonsálvez wrote:
> CL#3532 added a test for alpha to coverage without a color
> attachment.
> First the test draws a primitive with alpha 0 and a subpass with only
> a depth buffer. No writes to a depth buffer are expected.
Reviewed-by: Bas Nieuwenhuizen
On Fri, Mar 1, 2019 at 6:25 PM Samuel Pitoiset
wrote:
>
> This export format is faster. Seems to improve performance in
> Wreckfest.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_pipeline.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi Tapani,
On Mon, Mar 4, 2019 at 6:51 AM Tapani Pälli wrote:
>
> Hi;
>
> On 3/3/19 10:10 PM, Mauro Rossi wrote:
> > Necessary to avoid building error in Android,
> > due to 'compiler/glsl/float64_glsl.h' file not found
> >
> > Fixes: cb4e3e3 ("st/mesa: add support for lowering fp64/int64 for nir
https://bugs.freedesktop.org/show_bug.cgi?id=109805
--- Comment #7 from Samuel Pitoiset ---
Can you try to boot your kernel with amdgpu.vm_debug=1? Does the VM faults
happen more often with that option?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=109818
--- Comment #1 from Samuel Pitoiset ---
Can you upload a renderdoc capture and eventually bisect the problem?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
68 matches
Mail list logo
