Dear Roland Scheidegger
Thank you very much for your time and efforts.
First, I want to talk about the problem that I encountered.
I am currently developing a display server system using the llvmpipe driver
and the kms-dri winsys module. During the compositing process, winsys->
displaytarget_map
Hi Rob,
On Fri, Apr 20, 2018 at 6:09 AM Rob Herring wrote:
> Maintaining both flink names and prime fd support which are provided by
> 2 different gralloc implementations is problematic because we have a
> dependency on a specific gralloc implementation header.
> This mostly removes the depende
Hi Rob,
On Thu, Apr 19, 2018 at 1:03 AM Robert Foss
wrote:
> This patch both adds support for probing & filtering DRM nodes
> and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
> gralloc call.
> Currently the filtering is based just on the driver name,
> and the desired name is
Looks good.
Do we need to add : Fixes: c7dcee58b5fe183e1653c13bff6a212f0d157b29
(i965: Avoid problems from referencing orphaned BOs after growing.)
Which is the same as commit da25ae92bebb8921003c0df30820d06a5f5e3fef.
Regardless :
Reviewed-by: Lionel Landwerlin
On 18/04/18 13:57, Kenneth Gr
Am 19.04.2018 um 08:04 schrieb Seongchan Jeong:
> The lp_setup_set_fragment_sampler_views function can be called
> when the texture module is enabled. However, mapping can be
> performed several times for one display target texture, but
> unmapping does not proceed. So some logic have been added to
Aaron Watry writes:
> From CL 1.2 Section 5.2.1:
> CL_INVALID_VALUE if buffer was created with CL_MEM_HOST_WRITE_ONLY and
> flags specify CL_MEM_HOST_READ_ONLY , or if buffer was created with
> CL_MEM_HOST_READ_ONLY and flags specify CL_MEM_HOST_WRITE_ONLY , or if
> buffer was c
From CL 1.2 Section 5.2.1:
CL_INVALID_VALUE if buffer was created with CL_MEM_HOST_WRITE_ONLY and
flags specify CL_MEM_HOST_READ_ONLY , or if buffer was created with
CL_MEM_HOST_READ_ONLY and flags specify CL_MEM_HOST_WRITE_ONLY , or if
buffer was created with CL_MEM_HOST_NO_ACCES
Otherwise a lot of games complain about not having enough memory,
and it is sort of local so this seems reasonable to me.
CC: 18.0
---
src/amd/vulkan/radv_device.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_devic
https://bugs.freedesktop.org/show_bug.cgi?id=106142
Bug ID: 106142
Summary: weston crashes on start up
Product: Mesa
Version: 17.3
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: m
On Wed, Apr 18, 2018 at 11:03 AM, Robert Foss wrote:
> This patch both adds support for probing & filtering DRM nodes
> and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
> gralloc call.
>
> Currently the filtering is based just on the driver name,
> and the desired name is supplie
Maintaining both flink names and prime fd support which are provided by
2 different gralloc implementations is problematic because we have a
dependency on a specific gralloc implementation header.
This mostly removes the dependency on the gralloc implementation and
headers. The dependency on GRALL
https://bugs.freedesktop.org/show_bug.cgi?id=106140
Bug ID: 106140
Summary: EGLconfigs returns with no match for glmark2-es2-x11
Product: Mesa
Version: 17.3
Hardware: Other
OS: All
Status: NEW
Severity: no
GLSL 4.6 spec describes hex constant as:
hexadecimal-constant:
0x hexadecimal-digit
0X hexadecimal-digit
hexadecimal-constant hexadecimal-digit
Right now if you have a shader with the following structure:
#if 0X1 // or any hex number with the 0X prefix
// some code
#endif
On Thu, Apr 19, 2018 at 7:44 AM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:
> This didn't actually help the failing tests I'm looking at
> but hopefully has teeth elsewhere.
>
> CC: Jason Ekstrand
> CC: Jordan Justen
> CC: Anuj Phogat
> Signed-off-by: Topi Pohjolainen
> ---
> src/m
2018-04-19 20:08 GMT+02:00 Vlad Golovkin :
> -- Forwarded message --
> From: Vlad Golovkin
> Date: 2018-04-19 21:06 GMT+03:00
> Subject: Re: [Mesa-dev] [PATCH] mesa/math: Allocate memory for
> GLmatrix elements and its inverse contiguously
> To: Thomas Helland
>
>
> 2018-04-17 8:5
On 19/04/18 19:50, Ian Romanick wrote:
> On 04/18/2018 01:57 PM, Jose Maria Casanova Crespo wrote:
>> All operations with offset_reg at do_vector_read are done
>> with UD type. So copy propagation was not working through
>> the generated MOVs:
>>
>> mov(8) vgrf9:UD, vgrf7:D
>
> I have noticed othe
https://bugs.freedesktop.org/show_bug.cgi?id=105904
--- Comment #5 from Snubb ---
My computer reproduced bug!!
64 bit cube.exe working and 32 bit cube.exe and 32 bit dxvk not working before
deleting ~./cache/radv_builtin_shaders
I don't know why or how but i grabbed some output so you can try
Quoting Dylan Baker (2018-04-16 14:28:42)
> Quoting Dylan Baker (2018-04-13 08:46:46)
> > Quoting Dylan Baker (2018-04-09 14:02:51)
> > > This fixes -Ddri-drivers-path, -Dvdpau-libs-path, etc. with DESTDIR when
> > > those paths are absolute. Currently due to the way python's os.path.join
> > > han
-- Forwarded message --
From: Vlad Golovkin
Date: 2018-04-19 21:06 GMT+03:00
Subject: Re: [Mesa-dev] [PATCH] mesa/math: Allocate memory for
GLmatrix elements and its inverse contiguously
To: Thomas Helland
2018-04-17 8:55 GMT+03:00 Thomas Helland :
> Hi, and thanks for the patch
On 04/18/2018 01:57 PM, Jose Maria Casanova Crespo wrote:
> All operations with offset_reg at do_vector_read are done
> with UD type. So copy propagation was not working through
> the generated MOVs:
>
> mov(8) vgrf9:UD, vgrf7:D
I have noticed other cases of this. Copy propagation doesn't work
a
https://bugs.freedesktop.org/show_bug.cgi?id=106133
Dylan Baker changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |baker.dyla...@gmail.com
From: Thierry Reding
Resources created for scanout but without modifiers need to be treated
as pitch-linear. This is because applications that don't use modifiers
to create resources must be assumed to not understand modifiers and in
turn won't be able to create a DRM framebuffer and passing alon
From: Thierry Reding
This code path is no longer required with framebuffer modifier support.
Signed-off-by: Thierry Reding
---
src/gallium/drivers/tegra/tegra_screen.c | 69 ++--
1 file changed, 3 insertions(+), 66 deletions(-)
diff --git a/src/gallium/drivers/tegr
From: Thierry Reding
Resources created with modifiers are treated as scanout because there is
no way for applications to specify the usage (though that capability may
be useful to have in the future). Currently all the resources created by
applications with modifiers are for scanout, so make sure
Since mesa_classic is not build-on-demand the tests will create a demand
and add a bunch of extra compilation.
Fixes: 43a6e84927e3b1290f6f211f5dfb184dfe5a719e
("meson: build mesa test.")
Signed-off-by: Dylan Baker
---
src/mesa/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion
This one's completely my fault, I didn't do good enough testing after
rebasing and this got missed.
Fixes: d28c24650110c130008be3d3fe584520ff00ceb1
("meson: build graw tests")
Signed-off-by: Dylan Baker
---
src/gallium/targets/graw-xlib/meson.build | 3 +--
1 file changed, 1 insertion(+),
Since we have an option to turn test building on and off, we should
honor that.
Fixes: 34cb4d0ebc14663113705beae63dd52b9d1b2d87
("meson: build tests for gallium mesa state tracker")
Signed-off-by: Dylan Baker
---
src/meson.build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
di
https://bugs.freedesktop.org/show_bug.cgi?id=106131
Dylan Baker changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106131
Reviewed-by: Dylan Baker
I'll go ahead and push this with the added bugzilla tag, thanks!
Dylan
Quoting Mike Lothian (2018-04-19 02:02:39)
> Fixes: 34cb4d0ebc1 ("meson: build tests for gallium mesa state tracker")
>
> Signed-off-by:
Maintaining two different paths is annoying but this gets
rid of the performance regression introduced by the global
BO list.
We might find a better solution in the future, but for now
just keeps two paths.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 32 ++
In order to reduce a performance regression introduced by
4b13fe55a4 ("radv: Keep a global BO list for VkMemory."),
we are going to maintain two different paths.
One when VK_EXT_descriptor_indexing is enabled by the
application because we need to have a global BO list, and
one (the old one) when i
Ported from RadeonSI.
Local BOs ignore BO priorities, and we don't need those on APUs.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
b/src/amd/
The previous logic of the supports_48b_addresses wasn't actually
checking if i915.ko was running with full_48bit_ppgtt. The ENOENT
it was checking for was actually coming from the invalid context
id provided in the test execbuffer. There is no path in the
kernel driver where the presence of
EXEC_O
This didn't actually help the failing tests I'm looking at
but hopefully has teeth elsewhere.
CC: Jason Ekstrand
CC: Jordan Justen
CC: Anuj Phogat
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/gen7_urb.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git
No clue about travis, but from RADV side
Acked-by: Bas Nieuwenhuizen
Thanks!
On Thu, Apr 19, 2018 at 4:18 PM, Juan A. Suarez Romero
wrote:
> This is a backport for 18.0 from 6ce400782c ("travis: radeonsi and radv
> need LLVM 4.0") that fixes Travis build with meson + vulkan.
>
> CC: 18.0
> --
Sorry, sent this very same patch twice.
J.A.
On Thu, 2018-04-19 at 16:18 +0200, Juan A. Suarez Romero wrote:
> This is a backport for 18.0 from 6ce400782c ("travis: radeonsi and radv
> need LLVM 4.0") that fixes Travis build with meson + vulkan.
>
> CC: 18.0
> ---
> .travis.yml | 4 ++-
This is a backport for 18.0 from 6ce400782c ("travis: radeonsi and radv
need LLVM 4.0") that fixes Travis build with meson + vulkan.
CC: "18.0"
---
.travis.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 84de1353859..e4858dc9173 100644
This is a backport for 18.0 from 6ce400782c ("travis: radeonsi and radv
need LLVM 4.0") that fixes Travis build with meson + vulkan.
CC: 18.0
---
.travis.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 84de1353859..e4858dc9173 100644
--
Ported from RadeonSI.
Local BOs ignore BO priorities, and we don't need those on APUs.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
b/src/amd/
When advertizing this extension, egl_dri2 uses the DRI2_RENDERER_QUERY
extension to query whether an sRGB format is supported. That extension will
query our driver with the BIND flag PIPE_BIND_RENDER_TARGET rather than
PIPE_BIND_DISPLAY_TARGET which is used when building the configs.
We only return
This helper adds buffers created by the application to the
global BO list, while radv_cs_add_buffer() is called directly
for adding BOs created by the driver. This will allow us to
improve the global BO list path a little bit.
Because the priority is quite useless I removed the parameter.
Signed-
Maintaining two different paths is annoying but this gets
rid of the performance regression introduced by the global
BO list.
We might find a better solution in the future, but for now
just keeps two paths.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 32 ++
In order to reduce a performance regression introduced by
4b13fe55a4 ("radv: Keep a global BO list for VkMemory."),
we are going to maintain two different paths.
One when VK_EXT_descriptor_indexing is enabled by the
application because we need to have a global BO list, and
one (the old one) when i
https://bugs.freedesktop.org/show_bug.cgi?id=100629
--- Comment #14 from freedesk...@bremsspur.org ---
(In reply to Timothy Arceri from comment #13)
> The trace is complaining when I try to run it in compat.
>
> "error: context mismatch: expected OpenGL 4.4 core, but got OpenGL 4.5
> compat"
>
>
Reviewed-by: Iago Toral Quiroga
On Wed, 2018-04-18 at 22:57 +0200, Jose Maria Casanova Crespo wrote:
> All operations with offset_reg at do_vector_read are done
> with UD type. So copy propagation was not working through
> the generated MOVs:
>
> mov(8) vgrf9:UD, vgrf7:D
>
> This change allows
Fixes: 34cb4d0ebc1 ("meson: build tests for gallium mesa state tracker")
Signed-off-by: Mike Lothian
---
src/mesa/state_tracker/tests/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/tests/meson.build
b/src/mesa/state_tracker/tests/meson.bui
On 18/04/18 22:56, Dave Airlie wrote:
On 18 April 2018 at 00:31, Matthew Nicholls
wrote:
Previously before fb077b0728, the LOD parameter was being used in place of the
sample index, which would only copy the first sample to all samples in the
destination image. After that multisample image cop
On Wed, 2018-04-18 at 15:41 -0400, Marek Olšák wrote:
> On Wed, Apr 18, 2018 at 8:00 AM, Juan A. Suarez Romero
> wrote:
> > On Mon, 2018-04-16 at 20:52 -0400, Marek Olšák wrote:
> > > Hi,
> > >
> > > This cleanup is motivated by a Mesa/LLVM crash on Ubuntu 18.04.
> > > It happens inside gallivm_
On 04/17/2018 01:12 PM, Tom de Vries wrote:
[ Quoted text copied from
https://lists.freedesktop.org/archives/mesa-dev/2016-March/108926.html ]
Hi,
I've been playing around with bar.sync in ptx, JIT-compiling it to GM107
(my quadro m1200 card), and disassembling with cuobjdump -sass.
I looke
https://bugs.freedesktop.org/show_bug.cgi?id=105464
--- Comment #11 from Samuel Pitoiset ---
Hi,
Well, you can still re-enable the previous behaviour with "enable-ds128" and I
expect performance to be similar.
Otherwise, if you want to reproduce the problem you have to clone
https://github.com/
On 04/19/2018 07:31 AM, Bas Nieuwenhuizen wrote:
I have seen a few applications and games do the dynamic buffer bounds
incorrectly, this
make it easier to work around, e.g. for debugging.
Example?
Either way:
Reviewed-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 4 +++-
Reviewed-by: Samuel Pitoiset
On 04/19/2018 06:36 AM, Bas Nieuwenhuizen wrote:
---
src/amd/vulkan/radv_device.c | 5 -
src/amd/vulkan/radv_pipeline.c | 3 ++-
src/amd/vulkan/radv_shader.c | 1 +
src/amd/vulkan/si_cmd_buffer.c | 4
4 files changed, 11 insertions(+), 2 deletions
https://bugs.freedesktop.org/show_bug.cgi?id=106133
Bug ID: 106133
Summary: make check "OSError: [Errno 24] Too many open files"
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Mac OS X (All)
Status: NEW
On 04/18/2018 11:56 PM, Dave Airlie wrote:
On 18 April 2018 at 00:31, Matthew Nicholls
wrote:
Previously before fb077b0728, the LOD parameter was being used in place of the
sample index, which would only copy the first sample to all samples in the
destination image. After that multisample ima
54 matches
Mail list logo
