On Fri, 2019-02-01 at 11:23 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote:
> > > Iago Toral writes:
> > >
> > > > On Thu, 2019-01-24 at 11:45 -0800, Francisco Jerez wrote:
> > > > > Iago Toral writes:
> > > > >
> > > > > > On
> You should just land it and start doing in-tree development!
I don't have push access, you know :P
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Looks like SUBFM.3D and SUEAU are perfectly capable of dealing with 3d
tiling, they just need the correct inputs. Supply them.
We also have to deal with the case where a 2d "layer" of a 3d image is
bound. In this case, we supply the z coordinate separately to the
shader, which has to optionally tr
On Sun, Feb 3, 2019 at 6:18 PM Alyssa Rosenzweig
wrote:
> > Small comment, you should plan on single build for all supported
> > generations.. I'm not entirely sure if this same header is eventually
> > planned to be #include'd from different C code w/ different defines
> > for gpu gen (afaict yo
> Looks like you leak the constants? You could pass ctx->ssa_constants
> instead of NULL and the allocation would be automatically freed.
Hm, alright. Is there documentation anywhere on how memctx works in
general?
> Instead of hardcoding 4096, use impl->ssa_index?
Good catch, thank you.
> Loo
> Small comment, you should plan on single build for all supported
> generations.. I'm not entirely sure if this same header is eventually
> planned to be #include'd from different C code w/ different defines
> for gpu gen (afaict you just currently hard-code it at the top of this
> header).. But
Reviewed-by: Karol Herbst
On Sun, Feb 3, 2019 at 4:10 PM Ilia Mirkin wrote:
>
> Atomic operations don't update the local cache, which means that we
> would have to issue CCTL operations in order to get the updated values.
> When we know that a buffer is primarily used for atomic operations, it's
https://bugs.freedesktop.org/show_bug.cgi?id=109391
--- Comment #6 from Rudolf Kastl ---
(In reply to Hi-Angel from comment #5)
> Created attachment 143280 [details] [review]
> Fix LTO build with GCC
(In reply to Hi-Angel from comment #3)
> (In reply to Eric Engestrom from comment #2)
> > That f
https://bugs.freedesktop.org/show_bug.cgi?id=109540
Bug ID: 109540
Summary: gen_builder_meta.hpp:51:117: error: no matching
function for call to ‘cast(llvm::FunctionCallee)’
Product: Mesa
Version: git
Hardware: x86-64 (AMD6
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Vinson Lee changed:
What|Removed |Added
Depends on||109131
Referenced Bugs:
https://bugs.fre
https://bugs.freedesktop.org/show_bug.cgi?id=109131
Vinson Lee changed:
What|Removed |Added
Blocks||109535
Referenced Bugs:
https://bugs.fre
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Francisco Jerez changed:
What|Removed |Added
Depends on||109328
Referenced Bugs:
https://bug
On 03/02/2019 16:04, Jason Ekstrand wrote:
They are effectively (&x)[0] or *&x which does nothing.
Reviewed-by: Lionel Landwerlin
---
src/compiler/nir/nir_deref.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/n
https://bugs.freedesktop.org/show_bug.cgi?id=109391
--- Comment #5 from Hi-Angel ---
Created attachment 143280
--> https://bugs.freedesktop.org/attachment.cgi?id=143280&action=edit
Fix LTO build with GCC
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA
https://bugs.freedesktop.org/show_bug.cgi?id=109391
--- Comment #4 from Hi-Angel ---
Please test the following patch, it should resolve the building problem.
What it does is disables flto for specific files with assembly defined
functions. It's okay since from a cursory look there's not much cod
They are effectively (&x)[0] or *&x which does nothing.
---
src/compiler/nir/nir_deref.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
index 2f5fda643ca..13aa10c7532 100644
--- a/src/compiler/nir/nir_deref.c
+
They are effectively (&x)[0] or *&x which does nothing.
---
src/compiler/nir/nir_deref.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
index 2f5fda643ca..0af26b80e77 100644
--- a/src/compiler/nir/nir_deref.c
+
Atomic operations don't update the local cache, which means that we
would have to issue CCTL operations in order to get the updated values.
When we know that a buffer is primarily used for atomic operations, it's
easier to just avoid the caching at that level entirely.
The same issue persists for
https://bugs.freedesktop.org/show_bug.cgi?id=109532
--- Comment #4 from Ilia Mirkin ---
(In reply to Mark Janes from comment #3)
> This test was broken in the dEQP suite recently for m32 i965 platforms by:
FWIW I don't think this is a test bug. The shaders used appear perfectly
reasonable. It se
On Fri, 18 Jan 2019 17:09:03 -0800
Nanley Chery wrote:
> On Mon, Nov 19, 2018 at 10:54:08AM +0200, Eleni Maria Stea wrote:
[...]
> > + int img_d = smt->surf.logical_level0_px.depth;
>
> I don't think 3D ETC textures are possible. From the GL4.6 spec:
>
> An INVALID_OPERATION error is
GPUs Gen < 8 cannot sample ETC2 formats. So far, they converted the
compressed EAC/ETC2 images to non-compressed RGBA images. When
GetCompressed* functions were called, the pixels were returned in this
RGBA format and not the compressed format that was expected.
Trying to fix this problem, we use
The assertions that the GL_MAP_WRITE_BIT and GL_MAP_INVALIDATE_RANGE_BIT
in intel_miptree_map_etc will fail when the ETC miptree is mapped for
reading. As we are about to fix the GetCompressed* functions in the
following patches and allow the reading from etc miptrees, we have to
remove them.
Fixe
OES_copy_image extension was disabled on Gen7 due to the lack of support
for ETC2 images. Enabled it back. (Kenneth Graunke)
---
src/mesa/drivers/dri/i965/intel_extensions.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_exte
For CopyImageSubData to copy the data during the 1st draw call, we need
to update the shadow tree right before the rendering.
---
src/mesa/drivers/dri/i965/brw_draw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw
From: Nanley Chery
Use more generic field names. We'll reuse these fields for a workaround
with ASTC miptrees.
Reviewed-by: Eleni Maria Stea
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 8
src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 16
src/mesa/driv
Intel Gen7 GPUs don't support the ETC2 formats natively and in order to
show the pixels properly we convert them to RGBA and create RGBA miptrees.
The problem with that is that the GetCompressed* functions that should
return the compressed pixel values return the RGBA instead.
These patches are an
On Sat, 2019-02-02 at 12:58 -0500, Marek Olšák wrote:
>
>
> On Sat, Feb 2, 2019, 12:41 PM Eric Engestrom <
> eric.engest...@intel.com wrote:
> > On Saturday, 2019-02-02 10:32:15 -0500, Marek Olšák wrote:
> > > On Sat, Feb 2, 2019, 7:17 AM Eric Engestrom <
> > eric.engest...@intel.com wrote:
> > >
27 matches
Mail list logo