https://bugs.freedesktop.org/show_bug.cgi?id=105995
--- Comment #4 from Errong ---
(In reply to Daniel Stone from comment #1)
> That's correct, pbuffers are not supported on Wayland by Mesa. I haven't
> seen another driver which does support them on Wayland. Using FBOs is far
> better and more pe
https://bugs.freedesktop.org/show_bug.cgi?id=105904
--- Comment #3 from Timothy Arceri ---
Do you recall what version you updated from?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
me
https://bugs.freedesktop.org/show_bug.cgi?id=105995
--- Comment #3 from Errong ---
Created attachment 138775
--> https://bugs.freedesktop.org/attachment.cgi?id=138775&action=edit
sample code
--
You are receiving this mail because:
You are the QA Contact for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=105995
--- Comment #2 from Errong ---
Created attachment 138774
--> https://bugs.freedesktop.org/attachment.cgi?id=138774&action=edit
fixed patch
someone would help to apply this patch to meas please ?
I do not know how to do it.
--
You are receiv
https://bugs.freedesktop.org/show_bug.cgi?id=105995
Daniel Stone changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105995
Bug ID: 105995
Summary: egl driver dri2 on wayland platform can't choose
config with EGL_SURFACE_TYPE, EGL_PBUFFER_BIT
Product: Mesa
Version: git
Hardware: Other
https://bugs.freedesktop.org/show_bug.cgi?id=105807
--- Comment #18 from b...@besd.de ---
Just confirmed that it works now.
Thanks!
Maybe this should be in stable too?
--
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=105105
Tapani Pälli changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Since Gen8+ Intel PRM states that "r127 must not be used for
return address when there is a src and dest overlap in send
instruction."
This patch implements this restriction creating new register allocator
classes that are copies of the normal classes. These new classes
exclude in their set of re
Implement at brw_eu_validate the restriction from Intel Broadwell PRM, vol 07,
section "Instruction Set Reference", subsection "EUISA Instructions", Send
Message (page 990):
"r127 must not be used for return address when there is a src and dest overlap
in send instruction."
Cc: Jason Ekstrand
Cc
https://bugs.freedesktop.org/show_bug.cgi?id=105807
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 11, 2018 at 7:54 PM, Timothy Arceri
wrote:
> On 12/04/18 09:29, Timothy Arceri wrote:
>
>> The compatibility and core tokens were not added until GLSL 1.50,
>> for GLSL 1.40 just assume all shader built with a compat profile
>> are compat shaders.
>>
Reviewed-by: Marek Olšák
Marek
On Tue, Apr 10, 2018 at 8:10 PM, Bas Nieuwenhuizen
wrote:
> For dcn1 && < 64 bpp displayable surfaces, addrlib only accepts
> S swizzles.
>
> At the same time addrlib prefers D swizzles is allowed, so we can
> just allow S swizzles as fallback.
>
> Fixes: b64b712
On 11/04/18 20:56, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Please add to the commit message which test was fixed by this. Otherwise
the change seems reasonable:
Reviewed-by: Timothy Arceri
---
src/gallium/drivers/radeonsi/si_shader.c | 3 ++-
1 file changed, 2 insertions(+), 1 del
Reviewed-by: Timothy Arceri
On 11/04/18 20:56, Nicolai Hähnle wrote:
From: Nicolai Hähnle
It looks as if the structure fields array is fully initialized below,
but in fact at least gcc in debug builds will not actually overwrite
the unused bits of bit fields.
---
src/compiler/glsl_types.cpp
Reviewed-by: Timothy Arceri
On 11/04/18 20:56, Nicolai Hähnle wrote:
From: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_shader_nir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_s
Reorder code to avoid a forward declaration in the next patch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 114 +-
1 file changed, 57 insertions(+), 57 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers
Reorder code to avoid a forward declaration in the next patch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 42 +--
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers
Reorder code to avoid a forward declaration in the next patch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 60 +--
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers
Reorder code to avoid a forward declaration in the next patch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965
When mapping a region of the mipmap_tree, record which complementary
method to use to unmap it afterwards. By doing so we can avoid
duplicating the decision tree used when mapping and thereby eliminate
trivial errors that can be introduced if the two if-chains become out of
sync.
Signed-off-by: Ch
Reorder code to avoid a forward declaration in the next patch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 24 +--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers
Reorder code to avoid a forward declaration in the next patch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 44 +--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers
On 11/04/18 20:56, Nicolai Hähnle wrote:
From: Nicolai Hähnle
trans is zero-initialized, but trans->resource is setup immediately so
needs to be dereferenced.
---
src/gallium/drivers/radeonsi/si_texture.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
di
mesa/st decides whether to update samplers after a program change based on
whether num_textures is nonzero. By not counting samplers in a uniform
struct, we would segfault in
KHR-GLES3.shaders.struct.uniform.sampler_vertex if it was run in the same
context after a non-vertex-shader-uniform testcas
On 12/04/18 09:29, Timothy Arceri wrote:
The compatibility and core tokens were not added until GLSL 1.50,
for GLSL 1.40 just assume all shader built with a compat profile
are compat shaders.
Fixes rendering issues in Dawn of War II on radeonsi which has
enabled OpenGL 3.1 compat support.
oh a
This patch breaks compiling radv.
Dylan
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=105807
--- Comment #16 from Timothy Arceri ---
Ok so I found the problem. We didn't support compat shaders on GLSL 1.40 only
on GLSL versions higher and lower.
I think the Version == 0 might be a separate issue as per comment 15 and it
would be great
This adds everything except non-uniform indexing, which needs a bit
more work and testing.
---
src/amd/vulkan/radv_device.c | 39 +++
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_shader.c | 2 ++
3 files changed, 42 insertions(+)
diff --git
On 12/04/18 09:36, Ian Romanick wrote:
Are we still calculating limits (that affect whether or not a shader can
successfully link) after only doing GLSL optimizations? I'm worried
that making a pretty big change to the optimization path is going to
break some app on (most likely) an older piece
Pretty straight forward, just pass the divisors through the shader
key and then do a LLVM divide.
---
src/amd/vulkan/radv_device.c | 6 ++
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_nir_to_llvm.c | 26 +++---
src/amd/vulkan/radv_pipeline.c| 26 +
---
src/compiler/shader_info.h| 1 +
src/compiler/spirv/spirv_to_nir.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index ababe520b2d..c8128fea01b 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
The continue means we do alignment differently than during creation,
making the buffer smaller than expected.
---
src/amd/vulkan/radv_descriptor_set.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/amd/vulkan/radv_descriptor_set.c
b/src/amd/vulkan/radv_descriptor_set.c
index 1100ca182b
---
src/compiler/shader_info.h| 1 +
src/compiler/spirv/spirv_to_nir.c | 4
2 files changed, 5 insertions(+)
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index c8128fea01b..4a0a843c796 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@
---
src/amd/vulkan/radv_descriptor_set.c | 30 +++-
src/amd/vulkan/radv_descriptor_set.h | 1 +
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_descriptor_set.c
b/src/amd/vulkan/radv_descriptor_set.c
index 7a3a611dd68..9b35451c497 100644
---
src/amd/vulkan/radv_descriptor_set.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_descriptor_set.c
b/src/amd/vulkan/radv_descriptor_set.c
index 9b35451c497..55b4aaa388c 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/sr
---
src/compiler/spirv/spirv.core.grammar.json | 169 -
src/compiler/spirv/spirv.h | 18 +++
2 files changed, 183 insertions(+), 4 deletions(-)
diff --git a/src/compiler/spirv/spirv.core.grammar.json
b/src/compiler/spirv/spirv.core.grammar.json
index f3994a60
---
src/amd/vulkan/radv_cmd_buffer.c | 4 --
src/amd/vulkan/radv_debug.c | 3 -
src/amd/vulkan/radv_descriptor_set.c | 82 +---
src/amd/vulkan/radv_descriptor_set.h | 4 --
src/amd/vulkan/radv_private.h| 2 -
5 files changed, 13 insertions(+), 82 de
Previously we did not care about havin the set storage in order,
but for variable descriptor count we want the highest binding
at the end of the storage.
---
src/amd/vulkan/radv_descriptor_set.c | 43 ++--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/src/a
With update after bind we can't attach bo's to the command buffer
from the descriptor set anymore, so we have to have a global BO
list.
I am somewhat surprised this works really well even though we have
implicit synchronization in the WSI based on the bo list associations
and with the new behavior
This adds support for VK_EXT_descriptor_indexing except for the
non-uniform indexing, which should be sent shortly.
Please review!
Bas Nieuwenhuizen (10):
spirv: Update spirv.h to 12f8de9f04327336b699b1b80aa390ae7f9ddbf4
radv: Keep a global BO list for VkMemory.
radv: Don't store buffer ref
Splitting intel_miptree_map() like so should help with the yuck factor.
Though don't we also need to treat the stencil_mt to a similar treatment
to avoid slow reads?
Note the map should really record what method intel_miptree_map() used
so that is can be unwound correctly without chasing the same
The compatibility and core tokens were not added until GLSL 1.50,
for GLSL 1.40 just assume all shader built with a compat profile
are compat shaders.
Fixes rendering issues in Dawn of War II on radeonsi which has
enabled OpenGL 3.1 compat support.
Bugzilla: https://bugs.freedesktop.org/show_bug.
Are we still calculating limits (that affect whether or not a shader can
successfully link) after only doing GLSL optimizations? I'm worried
that making a pretty big change to the optimization path is going to
break some app on (most likely) an older piece of hardware because the
linker will now d
https://bugs.freedesktop.org/show_bug.cgi?id=105567
charlie changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Split out this functionality to enable a fast-clear optimization for
color miptrees in the next commit.
---
src/mesa/drivers/dri/i965/brw_clear.c | 54 ---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 22 +++
src/mesa/drivers/dri/i965/intel_mipmap_tree.h
This series lives on top of this mailing-list series:
[PATCH v3 0/9] Enable sRGB-encoded fast-clears on CNL
Nanley Chery (2):
i965: Add and use a helper to update the indirect miptree color
i965/blorp: Also skip the fast clear if the clear color differs
src/mesa/drivers/dri/i965/brw_blorp.c
If the aux state is CLEAR and clear color value has changed, only the
surface state must be updated. The bit-pattern in the aux buffer is
exactly the same.
v2: Handle the indirect color on gen10+.
---
src/mesa/drivers/dri/i965/brw_blorp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(
On Wed, Apr 11, 2018 at 11:45:57AM -0700, Jason Ekstrand wrote:
> I tweaked your commit messages a bit, added my R-B to this one, and pushed.
Thanks. Your title reads better.
Thanks,
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https:
The paths which sample with the clear color are now using a getter which
performs the sRGB decode needed to enable this fast clear.
This path can be exercised by fast-clearing a texture, then performing
an operation which requires sRGB decoding. Test coverage for this
feature is provided with the
We want to add and use a getter that turns off the indirect path by
returning zero for the clear address.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/
This getter allows CNL to sample from fast-cleared sRGB textures correctly.
---
src/mesa/drivers/dri/i965/brw_blorp.c| 13 ---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 7 +++---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 29
src/mesa/
We want to add and use a function that accesses the auxiliary buffer's
clear_color_bo and doesn't care if it has an MCS or HiZ buffer
specifically.
---
src/mesa/drivers/dri/i965/brw_blorp.c | 4 +-
src/mesa/drivers/dri/i965/brw_clear.c | 4 +-
src/mesa/drivers/dri/i965/brw_wm.c
The blending issue seems to be present on CNL as well.
Reviewed-by: Jason Ekstrand
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tre
We're going to combine ::mcs_buf and ::hiz_buf in later commits. Once
that happens, this function no longer make sense.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 13 -
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 4
2 files changed, 17 deletions(-)
diff --git a/src/
Make the next patch easier to read by eliminating most of the would-be
duplicate field accesses now.
---
src/mesa/drivers/dri/i965/brw_blorp.c| 8 ++--
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 16 +---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 24 +++
The most noteworthy differences between v2 and v3 are:
* A fixed memory leak.
* The extra helpers for intel_miptree::fast_clear_color are dropped.
* The indirect color buffer on gen10 is accounted for.
Jason Ekstrand (1):
util/srgb: Add a float sRGB -> linear helper
Nanley Chery (8):
i965/mip
From: Jason Ekstrand
Reviewed-by: Nanley Chery
Reviewed-by: Jason Ekstrand
---
src/util/format_srgb.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/util/format_srgb.h b/src/util/format_srgb.h
index 34b50afe3d1..596af56f4cd 100644
--- a/src/util/format_srgb.h
+++ b/src
Free the clear_color_bo in addition to freeing the
intel_miptree_aux_buffer which holds the reference to it.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri
From: Marek Olšák
---
src/mesa/main/accum.c | 1 -
src/mesa/main/arrayobj.c | 1 -
src/mesa/main/atifragshader.c | 1 -
src/mesa/main/attrib.c| 1 -
src/mesa/main/colortab.c | 1 -
src/mesa/main/convolve.c | 1 -
src/mesa/main/debug_output.c
https://bugs.freedesktop.org/show_bug.cgi?id=105807
--- Comment #15 from b...@besd.de ---
I'm probably too tired, but this should work I think except it doesnt.
// Little test program to dump supported shader versions
// compiled like this
// gcc test.c -I/usr/include/GL/ -L/usr/lib/x86_64-lin
On Wed, Apr 11, 2018 at 11:24:00AM -0700, Lionel Landwerlin wrote:
> Reviewed-by: Lionel Landwerlin
>
Thanks! And pushed.
> On 11/04/18 11:00, Nanley Chery wrote:
> > vulkan/genX_blorp_exec.c:69:1: warning: ‘blorp_get_surface_base_address’
> > defined but not used [-Wunused-function]
> > blo
num_dcc_levels means that DCC is supported, but this doesn't
mean that it's enabled by the driver. Instead, we should rely
on radv_image_has_dcc().
This fixes some multisample regressions since 0babc8e5d66
("radv: fix picking the method for resolve subpass") on Vega.
This is because the resolve me
On Wed, Apr 11, 2018 at 10:23 AM, Brian Paul wrote:
> Hmm, in my experience, interleaved arrays are fairly common.
>
In what kinds of apps are they common?
Certainly not in Steam games.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
h
Hi,
if you're interested in mesa/clover, it should mostly work (ocl1.1),
with the notable exception of image support.
If you have an app that doesn't work, file a bug. progress is slow
because few people care.
some ocl1.2 features are implemented as well, but it'll take some time
before ocl1.2 can
https://bugs.freedesktop.org/show_bug.cgi?id=105807
--- Comment #14 from b...@besd.de ---
That would explain why a program gets a zero in return when requesting a shader
language lower than the one hardcoded in comment 11. Which is exactly what
happen in comment 8.
Or at least that seems reasona
https://bugs.freedesktop.org/show_bug.cgi?id=105807
--- Comment #13 from b...@besd.de ---
from mesa/main/version.c: (the one above is getstring.c)
int
_mesa_get_shading_language_version(const struct gl_context *ctx,
int index,
https://bugs.freedesktop.org/show_bug.cgi?id=105807
--- Comment #12 from b...@besd.de ---
OpenGL core spec 4.5 page 4 specifies:
"The core profile of OpenGL 4.5 is also guaranteed to support all previous ver-
sions of the OpenGL Shading Language back to version 1.40. In some implemen-
tations t
https://bugs.freedesktop.org/show_bug.cgi?id=105807
--- Comment #11 from b...@besd.de ---
I think this function is the problem:
/**
* Return the string for a glGetString(GL_SHADING_LANGUAGE_VERSION) query.
*/
static const GLubyte *
shading_language_version(struct gl_context *ctx)
{
switch (
Meant for testing. Defeats some of the benefits of the implementation,
however it still seems to be better than the current hash table,
and the complexity is undeniably very low.
---
src/util/pointer_map.c | 99 +-
src/util/pointer_map.h | 1 -
2 fi
---
src/compiler/nir/nir_lower_vars_to_ssa.c | 35
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/src/compiler/nir/nir_lower_vars_to_ssa.c
b/src/compiler/nir/nir_lower_vars_to_ssa.c
index 3dfe48d6d3..988936ece8 100644
--- a/src/compiler/nir/nir_lo
---
src/compiler/glsl/linker.cpp | 40 +++-
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index af09b7d03e..c549cac4b5 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl
---
src/compiler/nir/nir_from_ssa.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/compiler/nir/nir_from_ssa.c b/src/compiler/nir/nir_from_ssa.c
index 1aa35509b1..e38c4fafd6 100644
--- a/src/compiler/nir/nir_from_ssa.c
+++ b/src/compiler/nir/nir_from_ssa
---
src/compiler/glsl/opt_copy_propagation.cpp | 47 +-
1 file changed, 21 insertions(+), 26 deletions(-)
diff --git a/src/compiler/glsl/opt_copy_propagation.cpp
b/src/compiler/glsl/opt_copy_propagation.cpp
index 7bcd8a090b..0195dc4e40 100644
--- a/src/compiler/glsl/o
Should cut memory consumption approximately in half, while giving
us better cache locality and a simpler implementation.
---
src/compiler/nir/nir_propagate_invariant.c | 33 +++---
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/src/compiler/nir/nir_propagat
This is a rework of our set for the common usecase of storing pointers.
We are currently storing the hash, and comparing the hash of the key
to the hash that is stored for the entry, plus comparing the key itself.
Seeing as comparing a pointer is cheap, this means we are doubling the
size of our se
---
src/compiler/nir/nir_lower_vars_to_ssa.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/compiler/nir/nir_lower_vars_to_ssa.c
b/src/compiler/nir/nir_lower_vars_to_ssa.c
index e8cfe308d2..3dfe48d6d3 100644
--- a/src/compiler/nir/nir_lower_vars_to_ssa.c
+++
---
src/compiler/glsl/glsl_to_nir.cpp | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index 80eb15f1ab..310b678680 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/c
This should simplify things, and cut the memory consumption of the
set effectively in half. Cache locality should also be better.
---
src/compiler/nir/nir_remove_dead_variables.c | 37 ++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/src/compiler/nir/nir
---
src/util/pointer_map.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/util/pointer_map.h b/src/util/pointer_map.h
index 4bfc306a5f..f92e67d40d 100644
--- a/src/util/pointer_map.h
+++ b/src/util/pointer_map.h
@@ -91,6 +91,19 @@ _mesa_pointer_map_next_entry(struct pointer
---
src/compiler/glsl/opt_constant_variable.cpp | 34 ++---
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/compiler/glsl/opt_constant_variable.cpp
b/src/compiler/glsl/opt_constant_variable.cpp
index 914b46004c..d1d315af7a 100644
--- a/src/compiler/glsl
---
src/compiler/glsl/opt_copy_propagation.cpp | 48 ++
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/src/compiler/glsl/opt_copy_propagation.cpp
b/src/compiler/glsl/opt_copy_propagation.cpp
index 6220aa86da..7bcd8a090b 100644
--- a/src/compiler/glsl/o
---
src/util/pointer_map.c | 23 +++
src/util/pointer_map.h | 3 +++
2 files changed, 26 insertions(+)
diff --git a/src/util/pointer_map.c b/src/util/pointer_map.c
index 8076bd827f..463fa19282 100644
--- a/src/util/pointer_map.c
+++ b/src/util/pointer_map.c
@@ -102,6 +102,29
The motivation is that for the common case of pointers as keys the
current hash table implementation has multiple disadvantages.
It stores the hash, which means we get more memory usage than
is strictly necessary. It also compares both the hash, and the
pointer against the key when searching, when
---
src/compiler/glsl/ir_variable_refcount.cpp | 13 ++---
src/compiler/glsl/ir_variable_refcount.h | 4 ++--
src/compiler/glsl/opt_dead_code.cpp| 6 +++---
3 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/src/compiler/glsl/ir_variable_refcount.cpp
b/src/compil
---
src/compiler/glsl/opt_constant_propagation.cpp | 47 --
1 file changed, 22 insertions(+), 25 deletions(-)
diff --git a/src/compiler/glsl/opt_constant_propagation.cpp
b/src/compiler/glsl/opt_constant_propagation.cpp
index 05dc71efb7..8072bf4811 100644
--- a/src/compile
This series came about when I saw a talk online, while simultaneously
being annoyd about the needless waste of memory in our set as reported
by pahole. I have previously made some patches that changed our hash
table from a reprobing one to a quadratic probing one, in the name of
lower overhead and
---
.../glsl/opt_copy_propagation_elements.cpp | 96 +++---
1 file changed, 47 insertions(+), 49 deletions(-)
diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp
b/src/compiler/glsl/opt_copy_propagation_elements.cpp
index 8bae424a1d..8737fe27a5 100644
--- a/s
On Tue, Apr 10, 2018 at 7:46 PM, Bas Nieuwenhuizen
wrote:
> What is the addrlib assertion we are hitting?
>
128bpp formats can't set "display = true" even though the tiling is always
_D for 128bpp.
Marek
>
> On Tue, Apr 10, 2018 at 11:44 AM, Michel Dänzer
> wrote:
> > On 2018-04-06 07:12 PM,
I tweaked your commit messages a bit, added my R-B to this one, and pushed.
And... Now I get to rebase my deref patches again. :-P
--Jason
On Tue, Apr 10, 2018 at 11:13 PM, Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> The matching code doesn't make real use of the return v
Reviewed-by: Lionel Landwerlin
On 11/04/18 11:00, Nanley Chery wrote:
vulkan/genX_blorp_exec.c:69:1: warning: ‘blorp_get_surface_base_address’
defined but not used [-Wunused-function]
blorp_get_surface_base_address(struct blorp_batch *batch)
^~
In file included
vulkan/genX_blorp_exec.c:69:1: warning: ‘blorp_get_surface_base_address’
defined but not used [-Wunused-function]
blorp_get_surface_base_address(struct blorp_batch *batch)
^~
In file included from vulkan/genX_blorp_exec.c:35:0:
./blorp/blorp_genX_exec.h:1249:1: warnin
On Tue, Apr 10, 2018 at 10:26 PM, Timothy Arceri
wrote:
>
> On 11/04/18 15:05, Jason Ekstrand wrote:
>
>> If I understand correctly, this is because when running with minimal GLSL
>> IR, opt_function_inlining doesn't acutally inline them all. Is that
>> correct? If so, would it make sense to ju
According to OpenGL 4.6 spec, section 8.11.4 ("Texture Image Queries"),
relative to errors for GetTexImage, GetTextureImage, and GetnTexImage:
"An INVALID_OPERATION error is generated by GetTextureImage if the
effective target is TEXTURE_CUBE_MAP or TEXTURE_CUBE_MAP_ARRAY, and
the texture
Current code is returning an INVALID_OPERATION when trying to use
getTextureImage() on a level that has not been explicitly defined.
That is, we define a mipmapped Texture2D with 3 levels, and try to use
GetTextureImage() for the 4th levels, and INVALID_OPERATION is returned.
Nevertheless, such c
According to OpenGL 4.6 spec, section 8.11.4 ("Texture Image Queries"),
relative to errors for GetTextureSubImage() function:
"An INVALID_VALUE error is generated if the effective target is
TEXTURE_1D and either yoffset is not zero, or height is not one.
An INVALID_VALUE error is generate
Hi,
I've been instructed to ask this here:
Looking at the table from xorg.freedesktop, it says OpenCL for S.Islands
is WIP.(work in progress)
Does that mean I can hope it's just a matter of time, or could it still
*never* arrive? (say, if the cards 'get old' and the devs drop support?)
Thanks,
Call back to intel_miptree_map when mapping the separate depth
miptree in map_depthstencil. This brings us back to the mapping
method decision tree in miptree_map where we hopefully find the
most performant mapping method for depth.
---
Here's an idea for a replacement of patch 5. Squirreling the
d
https://bugs.freedesktop.org/show_bug.cgi?id=105567
--- Comment #14 from Dylan Baker ---
.la files are generated by libtool, meson doesn't use libtool so there will be
no .la files. It's not a bug, it's actually a feature. As Emil said, projects
should not be dependent on .la files, that's bad be
Awesome, thanks Juan!
Quoting Juan A. Suarez Romero (2018-04-11 06:47:24)
> On Thu, 2018-03-29 at 11:20 -0700, Dylan Baker wrote:
> > This should be nominated for stable
> >
>
> Queued for next 18.0 stable release.
>
> J.A.
>
>
>
> > Quoting Dylan Baker (2018-03-12 11:23:23)
> > > Me
1 - 100 of 160 matches
Mail list logo
