> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> Joonas Lahtinen
> Sent: Monday, August 7, 2017 4:24 PM
> To: Zhang, Tina ; intel-...@lists.freedesktop.org;
> intel-
> gvt-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>
On Tue, Aug 8, 2017 at 11:46 PM, David Niklas wrote:
> BTW: I'm on list, no need to CC.
>
> On Wed, 9 Aug 2017 10:38:23 +0900
> Michel Dänzer wrote:
>
>> On 09/08/17 05:12 AM, David Niklas wrote:
>> > I know that currently some form of headless support already exists,
>> > but then I'd have to us
On Tue, Aug 8, 2017 at 11:46 PM, David Niklas wrote:
> BTW: I'm on list, no need to CC.
>
> On Tue, 8 Aug 2017 20:30:02 +
> "Deucher, Alexander" wrote:
>> > From: David Niklas [mailto:do...@mail.com]
>> > Hello,
>> > I'm not seeking any secret info.
>> > I'm a Gentoo Linux user who wants to r
Do not leak framebuffer if client provided crtc id found invalid.
Signed-off-by: Nikhil Mahale
---
drivers/gpu/drm/drm_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 5dc8c43..e40c12f 100644
--- a/drivers/gpu/drm/drm_pla
BTW: I'm on list, no need to CC.
On Tue, 8 Aug 2017 20:30:02 +
"Deucher, Alexander" wrote:
> > From: David Niklas [mailto:do...@mail.com]
> > Hello,
> > I'm not seeking any secret info.
> > I'm a Gentoo Linux user who wants to run some massively parallel
> > experiments.
> > I'm unwilling to
BTW: I'm on list, no need to CC.
On Wed, 9 Aug 2017 10:38:23 +0900
Michel Dänzer wrote:
> On 09/08/17 05:12 AM, David Niklas wrote:
> > I know that currently some form of headless support already exists,
> > but then I'd have to use crossfire (which does not work with the
> > opensource driver A
On 09/08/17 05:12 AM, David Niklas wrote:
> I know that currently some form of headless support already exists, but
> then I'd have to use crossfire (which does not work with the opensource
> driver AFAIK).
You don't need CrossFire to make use of a GPU in a headless fashion.
OpenCL should support
https://bugs.freedesktop.org/show_bug.cgi?id=91375
--- Comment #11 from Alex Perez ---
I also get the same message with 4.13.0-rc3
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.free
https://bugs.freedesktop.org/show_bug.cgi?id=91375
--- Comment #10 from Alex Perez ---
I also get the "[drm:.si_dpm_set_power_state] *ERROR*
si_restrict_performance_levels_before_switch failed"
...with 4.12.4, on Big Endian based powerpc64 machine (debian sid userland)
--
You are receiving thi
Default config value for all other drivers is N.
Signed-off-by: Michał Mirosław
---
drivers/gpu/drm/stm/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index 4b88223f9aed..5071df28532f 100644
--- a/drivers/gpu/drm/stm/Kconfig
+
On 2017-08-07 11:21, Daniel Vetter wrote:
> On Fri, Aug 04, 2017 at 12:45:06PM +0200, Peter Rosin wrote:
>> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
>> no longer used. Remove the dead code that was not doing anything
>> sensible anyway.
>>
>> Signed-off-by: Peter Rosin
>>
On 9 August 2017 at 09:42, Joe Kniss wrote:
> Because all drivers currently use gem objects for framebuffer planes,
> the virtual create_handle() is not required. This change adds a
> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
> create_handle() function pointer from drm_f
https://bugs.freedesktop.org/show_bug.cgi?id=101325
--- Comment #21 from Matt ---
Can confirm this bug on multiple cards / drivers / kernels / Mesa versions
starting with Unreal 4.15.
Radeon 7870
Radeon R7 360
Radeon R9 380 (Using amdgpu)
with anything greater than Mesa 17. Mesa 13 works fine.
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #17 from Dave Airlie ---
Enabling the UE4 linker script fixes this also. (It got disabled for 4.17).
It appears that versions the symbols on the UE side.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #16 from Timothee Besset ---
Thanks for the help and thorough investigation! I will follow up from there
with Epic to get this addressed UE4 side.
--
You are receiving this mail because:
You are the assignee for the bug.___
2017년 08월 08일 22:33에 Marek Szyprowski 이(가) 쓴 글:
> Hi all,
>
> On 2017-07-12 12:09, Marek Szyprowski wrote:
>> Add a check if the framebuffer described by the provided drm_mode_fb_cmd2
>> structure fits into provided GEM buffers. Without this check it is
>> possible to create a framebuffer object
https://bugs.freedesktop.org/show_bug.cgi?id=101977
Marek Olšák changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
dma_fence_wait_any_timeout only relies on two things to work correctly:
1) The SIGNALED flag to be set upon fence signal
2) The callback list to get called upon fence signal
Both of these are part of the core dma-fence API so it should work fine
even with a non-default wait function.
Signed-of
It is useful in certain circumstances to know when the fence is replaced
in a syncobj. Specifically, it may be useful to know when the fence
goes from NULL to something valid. This does make syncobj_replace_fence
a little more expensive because it has to take a lock but, in the common
case where
This just resets the dma_fence to NULL so it looks like it's never been
signaled. This will be useful once we add the new wait API for allowing
wait on "submit and signal" behavior.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 2 ++
Vulkan VkFence semantics require that the application be able to perform
a CPU wait on work which may not yet have been submitted. This is
perfectly safe because the CPU wait has a timeout which will get
triggered eventually if no work is ever submitted. This behavior is
advantageous for multi-th
It's completely unused.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +--
drivers/gpu/drm/drm_syncobj.c | 5 ++---
include/drm/drm_syncobj.h | 3 +--
3 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/am
From: Dave Airlie
This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.
v2: accept relative timeout, pass remaining time back
to userspace.
v3: return to absolute timeouts.
v4: absolute
This commit adds support for waiting on or signaling DRM syncobjs as
part of execbuf. It does so by hijacking the currently unused cliprects
pointer to instead point to an array of i915_gem_exec_fence structs
which containe a DRM syncobj and a flags parameter which specifies
whether to wait on it
The atomic exchange operation we were doing before in replace_fence was
sufficient for the case where it raced with itself. However, if you
have a race between a replace_fence and dma_fence_get(syncobj->fence),
you may end up with the entire replace_fence happening between the point
in time where
The function has far more in common with drm_syncobj_find than with
any in the get/put functions.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 10 +-
include/drm/drm_syncobj.h | 6 +++---
3 files
This series contains the drm and i915 bits required to implement the
VK_KHR_external_semaphore and VK_KHR_external_fence extensions on top of
DRM sync objects.
Patches 1-3 are cleanups and fixes for the core syncobj APIs.
Patch 4 is the i915 patch that adds support for syncobj in the i915 driver.
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #14 from Dave Airlie ---
Yup once I hid the libelf symbols, it all works.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lis
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #13 from Dave Airlie ---
llvm seems fine, it seems to be libelf that is broken.
I've noticed UE4 exports it's own libelf symbols but I haven't determined that
is the problem yet.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=97861
--- Comment #11 from Alex Deucher ---
Is this still an issue with a newer kernel? Audio support was added to SI
recently.
--
You are receiving this mail because:
You are the assignee for the bug.___
Hey Harry,
Harry Wentland wrote on 08.08.2017 22:25:
> upstream kernels currently have only headless support. We're still
> working on getting our display driver accepted upstream but in the
> meantime you can compile it yourself from
> https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-4.12.
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #12 from Marek Olšák ---
.AMDGPU.config coming from LLVM is empty with UE4Editor. This assertion fails:
diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
index 618b5cf..2fbb575 100644
--- a/src/amd/common/ac_binar
Hi David,
upstream kernels currently have only headless support. We're still
working on getting our display driver accepted upstream but in the
meantime you can compile it yourself from
https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-4.12. With this
you should have no issues booting to de
> -Original Message-
> From: David Niklas [mailto:do...@mail.com]
> Sent: Tuesday, August 08, 2017 4:13 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Deucher, Alexander; Bridgman, John; Deucher, Alexander; Cheng, Tony;
> Koenig, Christian; Wentland, Harry
> Subject: Planned Vega support in
https://bugzilla.kernel.org/show_bug.cgi?id=196615
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
Hi Dave,
a few fixes for 4.13..
The following changes since commit 16f73eb02d7e1765ccab3d2018e0bd98eb93d973:
Linux 4.13-rc3 (2017-07-30 12:40:36 -0700)
are available in the git repository at:
git://people.freedesktop.org/~robclark/linux msm-fixes-4.13-rc3
for you to fetch changes up to 8f
https://bugzilla.kernel.org/show_bug.cgi?id=196125
--- Comment #6 from Peter Spiess-Knafl (p...@autistici.org) ---
Forgot to mention that I am using the displayport connector. So it does not
only affect HDMI.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
Hello,
I'm not seeking any secret info.
I'm a Gentoo Linux user who wants to run some massively parallel
experiments.
I'm unwilling to wait and see what kind of support Linux gets because
the annoying bitcoin miners tend to cause the price to go through the roof
quickly.
My current card is an AMD S
https://bugzilla.kernel.org/show_bug.cgi?id=196615
Peter Spiess-Knafl (p...@autistici.org) changed:
What|Removed |Added
URL||https://git.kern
https://bugzilla.kernel.org/show_bug.cgi?id=196615
Peter Spiess-Knafl (p...@autistici.org) changed:
What|Removed |Added
CC||p...@autistici.o
https://bugs.freedesktop.org/show_bug.cgi?id=101160
--- Comment #5 from mercuriete ---
ping?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.
https://bugzilla.kernel.org/show_bug.cgi?id=196615
Bug ID: 196615
Summary: amdgpu - resume from suspend is no longer working on
rx480
Product: Drivers
Version: 2.5
Kernel Version: >= 4.11.3
Hardware: Intel
https://bugzilla.kernel.org/show_bug.cgi?id=196125
Peter Spiess-Knafl (p...@autistici.org) changed:
What|Removed |Added
CC||p...@autistici.o
Hi Dave,
Here's the pull for the last week and a bit. It's rather large as I was on
vacation/moving last week. Although the patch count/diffstat is higher than
normal, we have a lot of medium-large sets included. That also explains why the
summary might seem a bit light.
Among the aforementioned s
platform_get_irq() returns an error code, but the host1x driver
ignores it and always returns -ENXIO. This is not correct and,
prevents -EPROBE_DEFER from being propagated properly.
Notice that platform_get_irq() no longer returns 0 on error:
https://git.kernel.org/pub/scm/linux/kernel/git/torvald
Hi David,
Thanks for the feedback. I'm not as familiar with the FB Dev infrastructure.
Thanks for bringing this to my attention.
Jeff
-Original Message-
From: David Lechner [mailto:da...@lechnology.com]
Sent: Monday, August 07, 2017 2:17 PM
To: Philipp Zabel ; Jeff Mouroux
Cc: d
Make these structures const as they are only stored in the funcs field
of drm_bridge structure, which is of type const.
Done using Coccinelle.
Signed-off-by: Bhumika Goyal
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +-
2 files chan
Make these const as they are only passed to the function
drm_connector_init and the corresponding argument is of type const.
Done using Coccinelle
@match disable optional_qualifier@
identifier s;
@@
static struct drm_connector_funcs s = {...};
@ref@
position p;
identifier match.s;
@@
s@p
@good1@
Make these const as they are only passed to the function
drm_connector_init and the corresponding argument is of type const.
Done using Coccinelle
@match disable optional_qualifier@
identifier s;
@@
static struct drm_connector_funcs s = {...};
@ref@
position p;
identifier match.s;
@@
s@p
@good1@
Make these structures const as they are only stored in the funcs field
of a drm_mode_config structure which is of type const.
Done using Coccinelle:
@match disable optional_qualifier@
identifier s;
@@
static struct drm_mode_config_funcs s = {...};
@ref@
position p;
identifier match.s;
@@
s@p
@go
Make these structures const as they are only passed to the function
drm_fb_helper_prepare and the corresponding argument is of type const.
Done using Coccinelle
@match disable optional_qualifier@
identifier s;
@@
static struct drm_fb_helper_funcs s = {...};
@ref@
position p;
identifier match.s;
@
Make these const as they are only passed to the function
drm_connector_init and the corresponding argument is of type const.
Done using Coccinelle
@match disable optional_qualifier@
identifier s;
@@
static struct drm_connector_funcs s = {...};
@ref@
position p;
identifier match.s;
@@
s@p
@good1@
On 8/7/2017 11:13 PM, Alex Williamson wrote:
> On Mon, 7 Aug 2017 08:11:43 +
> "Zhang, Tina" wrote:
>
>> After going through the previous discussions, here are some summaries may be
>> related to the current discussion:
>> 1. How does user mode figure the device capabilities between region
Declare drm_connector_funcs structures as const.
Bhumika Goyal (3):
drm/bridge: make drm_connector_funcs structures const
drm/sun4i: make drm_connector_funcs structures const
drm/rockchip: make drm_connector_funcs structures const
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
driver
On Tue, 8 Aug 2017 14:18:07 +0530
Kirti Wankhede wrote:
> On 8/7/2017 11:13 PM, Alex Williamson wrote:
> > On Mon, 7 Aug 2017 08:11:43 +
> > "Zhang, Tina" wrote:
> >
> >> After going through the previous discussions, here are some summaries may
> >> be related to the current discussion:
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #11 from Marek Olšák ---
Samuel, can you share here what you found out when you were looking into the
issue? Thanks.
--
You are receiving this mail because:
You are the assignee for the bug._
The IN_FORMATS blob allows the kernel to advertise to userspace which
format/modifier combinations are supported, per plane. Use this to
advertise that we support both T_TILED and linear.
v2:
- Only advertise T_TILED for RGB (Eric)
- Actually turn on allow_fb_modifiers (Eric)
Signed-off-by: D
https://bugs.freedesktop.org/show_bug.cgi?id=101377
--- Comment #12 from j...@dev1ce.com ---
I've continued testing with a separate Sapphire Radeon R9 380 graphics card,
and cannot reproduce the hardware issue. the latest kernel 4.12.1 through
4.12.5 all load the driver properly as a module with
The IN_FORMATS blob allows the kernel to advertise to userspace which
format/modifier combinations are supported, per plane. Use this to
advertise that we support both T_TILED and linear.
v2:
- Only advertise T_TILED for RGB (Eric)
- Actually turn on allow_fb_modifiers (Eric)
Signed-off-by: D
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #10 from Timothee Besset ---
A similar crash happens if UE4 is started in Vulkan mode:
https://gist.github.com/TTimo/28fa434142fb59e66ae469ed7f7ef034
SIGFPE happens because pipeline->shaders[4]->config.num_vgprs == 0, which is
cons
Hi,
On 3 August 2017 at 12:00, Daniel Stone wrote:
> On 1 August 2017 at 17:58, Ben Widawsky wrote:
>> @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private
>> *dev_priv,
>> plane_formats = skl_plane_formats;
>> num_plane_formats = ARRAY_SIZE(s
Hi Bhumika,
Thank you for the patch.
On Tuesday 08 Aug 2017 21:24:10 Bhumika Goyal wrote:
> Make these structures const as they are only stored in the funcs field
> of drm_bridge structure, which is of type const.
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal
Reviewed-by: Laurent P
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, August 08, 2017 7:57 AM
> To: Alex Deucher
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> sumit.sem...@linaro.org; Koenig, Christian; Deucher, Al
https://bugs.freedesktop.org/show_bug.cgi?id=101787
--- Comment #22 from 247 ---
at the end i just gave up and done a fresh install...problem solved now...
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=101484
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #17 from
https://bugs.freedesktop.org/show_bug.cgi?id=101881
--- Comment #19 from Mike Lothian ---
So I tried dropping the -march=native and now it all works no matter what
version of GCC I use. So it looks like GCC 7+ is miscompiling 32bit apps with
-march=native
I then added in -mbmi which broke thing
https://bugs.freedesktop.org/show_bug.cgi?id=101382
--- Comment #6 from cosiek...@o2.pl ---
17.1.4-1 crash(core dump)
17.1.5-1 crash(core dump)
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-deve
Hi Dave,
a single etnaviv fix. Not really a regression fix, as the issue has been
present since day one, but as it's stable material I still think it
qualifies.
Regards,
Lucas
The following changes since commit 5669b9989eaa664cacbad6a85631550bccdad963:
Merge branch 'drm-fixes-4.13' of git://p
Hello Marek,
I have a similar patch in my tree, so this one is
Reviewed-by: Tobias Jakobi
- Tobias
Marek Szyprowski wrote:
> Add a check if the framebuffer described by the provided drm_mode_fb_cmd2
> structure fits into provided GEM buffers. Without this check it is
> possible to create a fr
Hi all,
On 2017-07-12 12:09, Marek Szyprowski wrote:
Add a check if the framebuffer described by the provided drm_mode_fb_cmd2
structure fits into provided GEM buffers. Without this check it is
possible to create a framebuffer object from a small buffer and set it to
the hardware, what results i
The stub functions returns -ENODEV when trying to register the cooling device,
thus failing the GPU bind, rendering the GPU subsystem unusable when
CONFIG_THERMAL isn't enabled.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 8 +---
1 file changed, 5 insertions(+), 3
Hi Tomi,
On Tuesday 08 Aug 2017 16:04:57 Tomi Valkeinen wrote:
> On 08/08/17 16:02, Laurent Pinchart wrote:
> >> Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not
> >> defined.
> >
> > I might have forgotten to compile-test all patches individually after
> > reordering them,
On 08/08/17 16:02, Laurent Pinchart wrote:
>> Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not
>> defined.
>
> I might have forgotten to compile-test all patches individually after
> reordering them, I'm sorry for that. I'm fixing that now. If you can push
> your
> -next
Hi Tomi,
On Tuesday 08 Aug 2017 15:56:10 Tomi Valkeinen wrote:
> On 05/08/17 01:43, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch series is a third version of the code previously posted as
> > "[PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform
> > code".
> >
> > The o
Hi Laurent,
On 05/08/17 01:43, Laurent Pinchart wrote:
> Hello,
>
> This patch series is a third version of the code previously posted as
> "[PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code".
>
> The omapdss/omapdrm initialization code is quite a mess. The physical devi
https://bugs.freedesktop.org/show_bug.cgi?id=101881
--- Comment #18 from Mike Lothian ---
So with llvm only compiled with debugging switched on I get these stack traces
when trying to launch glxgears (32bit)
fireburn@axion ~ $ DISPLAY=:0 DRI_PRIME=1 glxgears-x86
*** Error in `glxgears-x86': mall
Hi Daniel,
Thank you for the patch.
On Tuesday 25 Jul 2017 10:01:19 Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_plane_set_property.
I assume you meant drm_atomic_plane_set_property. With that fixed,
Reviewed-
On 02/07/17 09:19, Arvind Yadav wrote:
> dma_buf_ops are not supposed to change at runtime. All functions
> working with dma_buf_ops provided by work with
> const dma_buf_ops. So mark the non-const structs as const.
>
> File size before:
>text data bss dec hex filename
>
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #9 from Timothee Besset ---
(In reply to Samuel Pitoiset from comment #6)
> The issue can't be reproduced with the traces here as well. But if you build
> the UE4 editor from github, the issue can be reproduced with LLVM6.0svn.
Have
On 07/08/17 13:20, Maarten Lankhorst wrote:
> I want/need to rework the core property handling, and this hack is
> getting in the way. But since it's a non-standard propety only used by
> legacy userspace we know that this will only every be called from
> ioctl code. And never on some other free-s
Hi Bhumika,
Thank you for the patch.
On Tuesday 08 Aug 2017 16:58:30 Bhumika Goyal wrote:
> Make these const as they are only passed to the function
> drm_connector_init and the corresponding argument is of type const.
> Done using Coccinelle
>
> @match disable optional_qualifier@
> identifier s
On Mon, Aug 07, 2017 at 05:32:20PM -0400, Alex Deucher wrote:
> We have some changes in ttm and amdgpu that depend on these patches.
> Sumit, can you pull these in via dma-buf or should I roll them up
> through my amdgpu tree?
We could just throw them all into drm-misc too, that's kinda what it's
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #8 from Samuel Pitoiset ---
Yes for both.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #7 from Marek Olšák ---
Does the issue occur with any of these:
R600_DEBUG=mono
R600_DEBUG=nooptvariant
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #6 from Samuel Pitoiset ---
The issue can't be reproduced with the traces here as well. But if you build
the UE4 editor from github, the issue can be reproduced with LLVM6.0svn.
--
You are receiving this mail because:
You are the a
Hi Arnd,
Am Mittwoch, den 26.07.2017, 15:53 +0200 schrieb Arnd Bergmann:
> When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is
> built-in, we get a link error:
>
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
> etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34):
https://bugs.freedesktop.org/show_bug.cgi?id=101977
--- Comment #5 from Marek Olšák ---
This can't be reproduce with LLVM 6.0svn and Radeon Fury. Trying LLVM 3.9...
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
Am Samstag, den 22.07.2017, 11:53 +0200 schrieb Christian Gmeiner:
> With 'sync points' we can sample the reqeustes perform signals
> before and/or after the submited command buffer.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 106
> +
Den 07.08.2017 17.02, skrev Daniel Vetter:
On Sun, Aug 06, 2017 at 05:41:00PM +0200, Noralf Trønnes wrote:
drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
so no need to set it.
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
We ha
Den 07.08.2017 22.12, skrev Alex Deucher:
On Sun, Aug 6, 2017 at 11:41 AM, Noralf Trønnes wrote:
drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
so no need to set it.
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Noralf Trønnes
Acked-by: Alex Deucher
Thanks, applie
Den 07.08.2017 15.29, skrev Vincent ABRIOU:
Hi Noralf,
Thanks for the patch.
Acked-by: Vincent Abriou
Thanks, applied to drm-misc.
Noralf.
On 08/06/2017 05:40 PM, Noralf Trønnes wrote:
This driver can use the drm_driver.dumb_destroy and
drm_driver.dumb_map_offset defaults, so no need to
Am Samstag, den 22.07.2017, 11:53 +0200 schrieb Christian Gmeiner:
> In order to support performance counters in a sane way we need to provide
> a method to sync the GPU with the CPU. The GPU can process multpile command
> buffers/events per irq. With the help of a 'sync point' we can trigger an
>
Am Samstag, den 22.07.2017, 11:53 +0200 schrieb Christian Gmeiner:
> Changes from v1 -> v2:
> - renamed submit_perfmon_request() to submit_perfmon_validate()
> - extended flags validation
> - added comment about offset 0
> - moved assigment of cmdbuf->nr_pmrs below the copy_from_user of the pmrs.
>
On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now.
>
> The only special case is nouveau and tda988x which used one function
> for both legacy modeset code and -nv50 atomic world instead of 2
> vtables. But amounts to exactly the same.
>
> v2:
On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_plane_set_property.
>
> Signed-off-by: Daniel Vetter
[...]
> drivers/gpu/drm/sti/sti_cursor.c| 1 -
> drivers/gpu/drm/
On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_connector_set_property.
>
> The only special case is nouveau which used one function for both
> pre-nv50 legacy modeset code and post-nv50 at
Am Samstag, den 22.07.2017, 11:53 +0200 schrieb Christian Gmeiner:
> This makes it possible to allocate multiple events under the event
> spinlock. This change is needed to support 'sync'-points.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 31
https://bugs.freedesktop.org/show_bug.cgi?id=101881
--- Comment #17 from Mike Lothian ---
What arch would you recommend testing with?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.f
Ack-by: Monk.Liu
From: amd-gfx on behalf of Christian
König
Sent: Tuesday, August 8, 2017 4:14:46 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Dave
Airlie; Gerd Hoffmann
Subject: Re: [PATCH 2/7] drm/qxl: fix incorrect use of the lru_l
Hi,
On 08/08/2017 12:35 PM, Mark yao wrote:
On 2017年07月07日 23:47, Jose Abreu wrote:
Hi Archit,
Ping, Any update for this patch? Can it be landed?
This patch actually needed for rk3399 hdmi support
Sorry, missed this one.
There was a comment from Laurent mentioning whether we'd want to
pu
1 - 100 of 106 matches
Mail list logo
