Gfx10 remembers sample positions in compressed Z/S memory, so the hw
doesn't need the decompress pass for shader loads.
Marek
On Wed, May 22, 2019 at 4:20 PM Marek Olšák wrote:
> The depth decompress pass needs to know the sample locations.
>
> If shader loads read from compressed depth, the te
Changelog in Android makefile:
- Add LOCAL_MODULE_CLASS, intermediates and LOCAL_GENERATED_SOURCES
- Use LOCAL_EXPORT_C_INCLUDE_DIRS to export $(intermediates) path
- Move generated header rules before 'include $(BUILD_STATIC_LIBRARY)'
Fixes the following building error:
In file included from ext
On Fri, Jun 21, 2019 at 1:13 PM Emil Velikov
wrote:
> From: Emil Velikov
>
> Currently libdrm_amdgpu provides a typedef of the various handles. While
> the goal was to make those opaque, it effectively became part of the API
>
> To the best of my knowledge there are two ways to have opaque handl
Reviewed-by: Marek Olšák
Marek
On Wed, Jun 19, 2019 at 4:42 AM Thomas Hellström (VMware) <
tho...@shipmail.org> wrote:
> From: Thomas Hellstrom
>
> For svga, the use of persistent / coherent maps is typically slightly
> slower than without them. It's probably a bit case-dependent and
> possibl
Both patches pushed :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
We look at the highest set bit in the UBO enable mask to work out the
maximum indexable UBO, i.e. the UBO count as we need to report to the
hardware.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 17 +++--
1 file changed, 15 insertions(+), 2 deleti
We refactor panfrost_constant_buffer to mirror v3d's constant buffer
handling, to enable UBOs as well as a single set of uniforms.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 66 ++
src/gallium/drivers/panfrost/pan_context.h | 6 +-
2 fi
We've known about this for a while, but it was never formally in the
machine header files / decoder, so let's add them in.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/include/panfrost-job.h| 15 +++
src/gallium/drivers/panfrost/pan_context.c | 18 +--
We already uploaded UBOs, but only a fixed number (1) for uniforms;
let's upload as many as we compute we need.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 27 +-
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/src/gallium
Prevents an assert(0) later in this (not so edge) case. We still have to
have a dummy there.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context
This implements loads from direct vec4-aligned fields in UBOs. More
future work is needed for indirect or unaligned loads (just compiler changes),
but the core command stream work is handled here.
Alyssa Rosenzweig (9):
panfrost: Constant buffer refactor
panfrost: Report UBO count
panfrost:
Now that all the counting is sorted, it's a matter of passing along a
GPU address and going.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/s
Just a little spring cleanup, extending UBOs to vertex shaders in the
process.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 55 ++
1 file changed, 36 insertions(+), 19 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
UBOs and uniforms now use a common code path with an explicit `index`
argument passed, enabling UBO reads.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 65 +++
1 file changed, 51 insertions(+), 14 deletions(-)
diff --git a/src/gallium/driv
This is the hardware max, as far as I can tell.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_screen.c
b/src/gallium/drivers/panfrost/pan_screen.c
index 5d3acc0a
Marek, I thought you also r-b'd this?
Either way r-b.
On Thu, Jun 20, 2019 at 6:20 AM Marek Olšák wrote:
>
> From: Nicolai Hähnle
>
> The initial prototype used a processor-specific symbol type, but
> feedback suggests that an approach using processor-specific section
> name that encodes the al
Doesn't this cause assertions in si_shader_ps() for monolithic
shaders? Some of these assertions check that at least one bit in a
group is set and I think we end up with input_ena = 0 for monolithic
shaders now?
On Thu, Jun 20, 2019 at 6:20 AM Marek Olšák wrote:
>
> From: Marek Olšák
>
> The dri
https://bugs.freedesktop.org/show_bug.cgi?id=99781
--- Comment #21 from Hal Gentz ---
I just spotted that this got reopened today when going through my emails for
the first time in forever... this is unfortunate.
I'll take another swing at this sometime next week using Uli Schlachter's new
propo
I have encountered what I believe to be a bug in nir_algebraic. Since
the rewrite to use automata, I'm not sure how to begin debugging it.
I'm looking for some suggestions... even if the suggestion is, "Fix your
patterns."
I have added a pattern like:
(('~fadd@32', ('fmul', ('fadd', 1.0, ('fn
https://bugs.freedesktop.org/show_bug.cgi?id=99781
Hal Gentz changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |zegen...@protonmail.com
|o
Hello Emil,
I see glmark2 - [desktop] blur-radius=5
libpng warning: iCCP: known incorrect sRGB profile
Mesa: User error: GL_INVALID_OPERATION in
glFramebufferTexture2D(window-system framebuffer)
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 4879 FrameTime: 0.205 m
https://bugs.freedesktop.org/show_bug.cgi?id=110603
--- Comment #7 from Samuel Pitoiset ---
Can you record a renderdoc capture of the problem please?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=110662
soredake changed:
What|Removed |Added
CC||fds...@krutt.org
--
You are receiving this
Hello Xorg Community!
My name is Priyanshu Varshney. a* fourth-year* student at *Indian Institute
of Technology (IIT)*, Indore, India. I am eager to work on writing an
advanced configuration tool for Mesa drivers and thus I want to know the
possible mentors for the project so that I can start divin
Hello!
Less than three weeks to go to submit your talks, workshops or demos
for this year's X.Org Developer Conference, which will be taking place
in Montréal, Canada on October 2-4, 2019!
The 2019 X.Org Developers Conference is the annual technical meeting
for X Window System and Free Desktop de
Hey
> Good stuff, but isn't this change making us hit assertions?
Hm, I thought it only enabled debugging symbols. Do you have a recommendation
on how to enable debug symbols but not enabling assertions?
Cheers
Rohan Garg
___
mesa-dev mailing list
me
On Friday, 21 June 2019 07:40:02 CEST Tomeu Vizoso wrote:
> On 6/20/19 6:33 PM, Rohan Garg wrote:
> >> Not sure I understand how this works. Isn't this going to cause
> >> unnecessary container builds?
> >>
> >> And, why cannot developers just add whatever they want to DEBIAN_TAG
> >> to that end?
On 6/21/19 12:23 PM, Rohan Garg wrote:
Hey
Good stuff, but isn't this change making us hit assertions?
Hm, I thought it only enabled debugging symbols. Do you have a recommendation
on how to enable debug symbols but not enabling assertions?
I think assertions should be limited to the most ba
Without this fix, LAVA isn't parsing crashes as failed tests, because
the shell logging is interspersed within the fake deqp output.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/deqp-runner.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/
Use the _safe version as asserted by gallium
Signed-off-by: Rohan Garg
---
src/gallium/drivers/panfrost/midgard/midgard_schedule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_schedule.c
b/src/gallium/drivers/panfrost/midgard/m
A-b
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
We want to know if a given slice of a buffer is initialized at a
particular point in the execution of the program. This is accomplished
easily enough -- start out uninitialized and upon an operation writing
to the buffer, mark it initialized.
The motivation is to optimize away expensive operations
Just a fun optimization, shaves some cycles off glmark shaders.
Alyssa Rosenzweig (3):
panfrost/midgard: Share swizzle/mask code
panfrost/midgard: Share swizzle compose
panfrost/midgard: Merge embedded constants
.../drivers/panfrost/midgard/helpers.h| 60 +
.../panfrost
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/helpers.h| 29 +++
.../drivers/panfrost/midgard/midgard_ra.c | 9 +-
2 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src/gallium/dri
Now that scoreboarding is working, this is trivial.
Alyssa Rosenzweig (2):
panfrost: Implement rasterizer discard
panfrost: Conditionally submit fragment job
src/gallium/drivers/panfrost/pan_context.c | 14 --
src/gallium/drivers/panfrost/pan_drm.c | 5 -
2 files changed
r-b
On Thu, Jun 20, 2019 at 6:19 AM Marek Olšák wrote:
>
> From: Marek Olšák
>
> otherwise the behavior is undefined
> ---
> src/amd/common/ac_llvm_build.c | 8
> src/amd/common/ac_llvm_build.h | 3 +++
> src/gallium/drivers/radeonsi/si_c
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/helpers.h| 31 +++
.../panfrost/midgard/midgard_compile.c| 29 -
2 files changed, 31 insertions(+), 29 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src
If there are no tiling jobs and no clears, there is no need to submit a
fragment job (relevant for transform feedback).
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_drm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost
In Midgard, a bundle consists of a few ALU instructions. Within the
bundle, there is room for an optional 128-bit constant; this constant is
shared across all instructions in the bundle.
Unfortunately, many instructions want a 128-bit constant all to
themselves (how selfish!). If we run out of spa
D'aww, look cute that is now that scoreboarding is setup.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost
r-b
On Thu, Jun 20, 2019 at 6:20 AM Marek Olšák wrote:
>
> From: Marek Olšák
>
> ---
> .../drivers/radeonsi/si_state_binning.c| 18 --
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_binning.c
> b/src/gallium/dri
On 6/20/19 8:20 PM, Alyssa Rosenzweig wrote:
This is a rather complex change, adding a lot of code but ideally
cleaning up quite a bit as we go.
Within a batch (single frame), there are multiple distinct Mali job
types: SET_VALUE, VERTEX, TILER, FRAGMENT for the few that we emit right
now (event
> Very nice, this will fix a few tests.
Ah, of course :)
> Good riddance!
To be fair, a lot of that just got moved in with panfrost_job.. :)
> Can we remove now the has_draws arg?
Maybe? The has_draws arg controls a lot of things beyond just, you
know, having draws. The whole API there nee
On 6/21/19 3:05 PM, Alyssa Rosenzweig wrote:
Very nice, this will fix a few tests.
Ah, of course :)
Good riddance!
To be fair, a lot of that just got moved in with panfrost_job.. :)
Can we remove now the has_draws arg?
Maybe? The has_draws arg controls a lot of things beyond just, y
r-b
On Wed, Jun 12, 2019 at 11:44 AM Samuel Pitoiset
wrote:
>
> The driver might need to clear one aspect of the depth/stencil
> resolve attachment before performing the resolve itself.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_clear.c | 73
We only need this if the HTILE is not tc-compat?
Otherwise the read side is independent of compute/fragment shader.
On Wed, Jun 12, 2019 at 11:44 AM Samuel Pitoiset
wrote:
>
> It's required to decompress HTILE before resolving with the
> compute path.
>
> v2: - do proper layout transitions
>
The DRM driver has a dummy implementation and the non-drm backend is
gone, so let's kill this perf counter interface.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 14 --
src/gallium/drivers/panfrost/pan_drm.c | 14 --
src/gallium/dri
The non-drm backend is gone and there's no plan to bring it back to
life. Let's get rid of the panfrost_driver abstraction and call the
panfrost_drm_xxx() functions directly.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_afbc.c | 2 +-
src/gallium/drivers/panfrost/pan
A while back, Laura and Jean was working on a Sphinx-conversion of the
mesa-documentation. Sadly this work stranded due to it also trying to
move to using GitLab Pages for hosting www.mesa3d.org, and because the
documentation and the websit eis the same thing, this lead to problems
with hosting the
On Thursday, 20 June 2019 20:20:38 CEST Alyssa Rosenzweig wrote:
> This is a rather complex change, adding a lot of code but ideally
> cleaning up quite a bit as we go.
>
> Within a batch (single frame), there are multiple distinct Mali job
> types: SET_VALUE, VERTEX, TILER, FRAGMENT for the few t
This simple extension might be useful for debugging purposes.
GAPID has support for it.
Signed-off-by: Samuel Pitoiset
---
A simple crucible test:
https://gitlab.freedesktop.org/mesa/crucible/merge_requests/47
src/amd/vulkan/radv_cmd_buffer.c | 35 +++
src/amd/vulk
Hello list,
The candidate for the Mesa 19.1.1 is now available. Currently we have:
- 27 queued
- 0 nominated (outstanding)
- and 0 rejected patch
The current queue consists mostly in fixes for different drivers (RADV, ANV,
Nouveau, Virgl, V3D, R300g, ...)
The queue also contains different fi
R-b, that's long overdue seeing as the DRM driver has a totally
different (better? :) ) interface anyway (Thank you!)
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailma
Oh, nice! I'm going to give this a tentative Reviewed-by. The changes
themselves look good (and there shouldn't be functional changes). I do
want this to happen; I just need to give some thought to ensuring that
yes, this is really what we want to do.
I'm having troubles thinking of when we might
From: Marek Olšák
- merge all 3 functions (Z, S, ZS)
- don't write the color output
- read the value from texel.x, then write it to position.z or stencil.y
(don't use the value from texel.y or texel.z)
---
src/gallium/auxiliary/util/u_blitter.c| 19 +-
src/gallium/auxiliary/util/u_sim
From: Marek Olšák
This is for drivers that can't map depth and stencil and need to blit
them to a color texture for CPU access.
This also useful for drivers using separate depth and stencil.
---
src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h | 6 +
src/gallium/auxiliary/util/u_blitter.c
From: Marek Olšák
This mainly removes and simplifies code that is no longer needed.
There were some issues with the DB->CB stencil copy on gfx10, so let's
just use a fragment shader blit for all ZS mappings. It's more reliable.
---
src/gallium/drivers/radeonsi/si_blit.c| 29 +---
src/galli
From: Emil Velikov
Currently libdrm_amdgpu provides a typedef of the various handles. While
the goal was to make those opaque, it effectively became part of the API
To the best of my knowledge there are two ways to have opaque handles:
- "typedef void *foo;" - rather messy IMHO
- "stuct foo;"
58 matches
Mail list logo
