A resume of a ThinkPad T440s brought this probably simialr to an earlier
repoeted trace):
Dec 14 11:34:17 t44 kernel: [drm:intel_dp_start_link_train] *ERROR* too many
full retries, give up
Dec 14 11:34:18 t44 kernel: [drm:intel_dp_start_link_train] *ERROR* too many
full retries, give up
Dec 14
|incorrect hair rendering|incorrect hair rendering
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141214/14df2
dri-devel/attachments/20141214/7176f64f/attachment.html>
On 12/14/2014 4:59 AM, Chris Wilson wrote:
> One of the things wbinvd is considered evil for is that it blocks the
> CPU for an indeterminate amount of time - upsetting latency critcial
> aspects of the OS. For example, the x86/mm has similar code to use
> wbinvd for large clflushes that caused a b
m 2 X3 720
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141214/3539154a/attachment.html>
From: Ben Goz
Original code sent always 0 as the index number of the node. This patch fixes
this bug by sending a variable which is incremented per node.
Signed-off-by: Ben Goz
Reviewed-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 del
When an ioctl function returns -EAGAIN, don't print error in kfd_ioctl()
v2: Also don't print an error if the ioctl function returns -ERESTARTSYS
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/g
From: Ben Goz
This patch passes the correct queue type to pqm_create_queue() instead of a
fixed KFD_QUEUE_TYPE_COMPUTE type.
Signed-off-by: Ben Goz
Reviewed-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dri
From: Ben Goz
This patch adds a check to the create queue ioctl path, which identifies SDMA
queue type that is sent by userspace.
Signed-off-by: Ben Goz
Reviewed-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/
From: Ben Goz
This patch adds support for SDMA user-mode queues to the QCM - the Queue
management system that manages queues-per-device and queues-per-process.
Signed-off-by: Ben Goz
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 167 +++--
.../gpu/drm/amd/amdkfd/kfd_
From: Ben Goz
This patch adds support for SDMA mqd operations:
- init_mqd_sdma
- uninit_mqd_sdma
- load_mqd_sdma
- update_mqd_sdma
- destroy_mqd_sdma
- is_occupied_sdma
It also adds SDMA queue information to some private structures of amdkfd.
Signed-off-by: Ben Goz
---
drivers/gpu/drm/amd/amd
From: Ben Goz
This patch implements the new SDMA interface functions. It also adds defines
and structures related to SDMA registers.
Signed-off-by: Ben Goz
---
drivers/gpu/drm/radeon/cik_reg.h| 200 +++-
drivers/gpu/drm/radeon/radeon_kfd.c | 132
From: Ben Goz
This patch adds four new functions to the kfd2kgd interface:
1. init_sdma_engines() - Initializes the SDMA engines through GPU registers.
2. hqd_sdma_load() - Loads SDMA mqd to a H/W SDMA hqd slot. Used only in no HWS
mode.
3. hqd_sdma_is_occupied() - Checks
This patch-set enables amdkfd to provide the ability to HSA processes to
create SDMA user-mode queues.
The queues can be scheduled on either one of Kaveri's two SDMA engines. The
assignment is done during the creation of the queue and it is alternating
between the first engine and the second. e.g.
On 12/14/2014 04:10 PM, Christian König wrote:
> Am 14.12.2014 um 14:35 schrieb Oded Gabbay:
>> When an ioctl function returns -EAGAIN, don't print error in kfd_ioctl()
>
> You most likely want to handle -ERESTARTSYS the same way.
>
> Christian.
Thanks, will fix and resend.
Oded
>
>>
>
On Sun, Dec 14, 2014 at 03:12:21PM +0200, Ville Syrjälä wrote:
> On Sat, Dec 13, 2014 at 07:08:24PM -0800, Ben Widawsky wrote:
> > If we're moving a bunch of buffers from the CPU domain to the GPU domain,
> > and
> > we've already blown out the entire cache via a wbinvd, there is nothing
> > mo
From: Alexey Skidanov
This patch splits the current kfd_get_process_device_data() to two
functions, one that specifically creates a pdd and another one which
just do lookup.
This is done to enhance the readability and maintainability of the code.
Signed-off-by: Alexey Skidanov
Reviewed-by: Ode
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 69c5fe7..4083dbc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/driver
From: Alexey Skidanov
This patch adds the number of watch points to the node capabilities in the
topology module
Reviewed-by: Oded Gabbay
Signed-off-by: Alexey Skidanov
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 +
drivers/gpu/drm/amd/
When an ioctl function returns -EAGAIN, don't print error in kfd_ioctl()
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.
On Sat, Dec 13, 2014 at 07:08:24PM -0800, Ben Widawsky wrote:
> If we're moving a bunch of buffers from the CPU domain to the GPU domain, and
> we've already blown out the entire cache via a wbinvd, there is nothing more
> to
> do.
>
> With this and the previous patches, I am seeing a 3x FPS incr
Am 14.12.2014 um 14:35 schrieb Oded Gabbay:
> When an ioctl function returns -EAGAIN, don't print error in kfd_ioctl()
You most likely want to handle -ERESTARTSYS the same way.
Christian.
>
> Signed-off-by: Oded Gabbay
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
> 1 file changed
This should be [PATCH v2 x/3] for all three patches.
Sorry.
Oded
On 12/14/2014 02:29 PM, Oded Gabbay wrote:
> This patch adds a new interface to the kfd-->kgd interface.
> The new interface function retrieves the firmware version that is currently in
> use by the MEC engine. The firmware
This patch displays the firmware version of the microcode that is currently
running in the MEC.
This is needed for the HSA RT, so it could differentiate its behavior based on
fw version. e.g. workarounds for bugs in fw
v2: Send the KGD_ENGINE_MEC1 as a parameter to the get_fw_version()
Signed-off
This patch implements a new interface that was added to the kfd-->kgd interface.
The new interface function retrieves the firmware version that is currently
in use by a specific engine. The firmware was uploaded to the engine by the
radeon driver.
v2: Returns the fw version of the specific engine,
This patch adds a new interface to the kfd-->kgd interface.
The new interface function retrieves the firmware version that is currently in
use by the MEC engine. The firmware was uploaded to the MEC engine by the kgd
(radeon).
v2: Added parameter of engine type to interface function
Signed-off-by
https://bugzilla.kernel.org/show_bug.cgi?id=89731
--- Comment #1 from Andrea ---
A few details on the machine:
Acer 5820TG, it's got an Intel HD first gen + AMD radeon HD5650.
It is a muxed switchable graphics system as far as I know
--
You are receiving this mail because:
You are watching th
https://bugzilla.kernel.org/show_bug.cgi?id=89731
Bug ID: 89731
Summary: System doesn't boot on muxed IntelHD + HD5650
Product: Drivers
Version: 2.5
Kernel Version: 3.17.4-301.fc21.x86_64
Hardware: All
OS: Linux
On Sat, Dec 13, 2014 at 07:08:22PM -0800, Ben Widawsky wrote:
> Any GEM driver which has very large objects and a slow CPU is subject to very
> long waits simply for clflushing incoherent objects. Generally, each
> individual
> object is not a problem, but if you have very large objects, or very m
Hi,
since kernel 3.18 I'm no longer able to run X on my machine. While
3.17.6 is fine, 3.18 leaves me with a black screen when starting
X. Booting into runlevel 1/3 is fine.
I did a "git bisect", and the offending commit is this one:
[root at kiera linux-git]# git bisect bad
83f45fc360c8e16a3304
On Sat, Dec 13, 2014 at 07:08:21PM -0800, Ben Widawsky wrote:
> When the original drm code was written there were no centralized functions for
> doing a coordinated wbinvd across all CPUs. Now (since 2010) there are, so use
> them instead of rolling a new one.
>
> Cc: Intel GFX
> Signed-off-by: B
On 12/10/2014 11:57 PM, Alex Deucher wrote:
> On Wed, Dec 10, 2014 at 8:13 AM, Oded Gabbay wrote:
>> From: Alexey Skidanov
>>
>> This patch implements a new interface that was added to the kfd-->kgd
>> interface.
>> The new interface function retrieves the firmware version that is currently
>>
Hi Daniel,
> On Mon, Nov 10, 2014 at 10:19 PM, Daniel Vetter
> wrote:
>> Adding relevant mailing lists.
>>
>>
>> On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Benisty
>> wrote:
>>> Hi,
>>>
>>> The following commit permanently turns my screen off when x server is
>>> started (i3 330M Ironlake):
>>>
33 matches
Mail list logo
