On Thu, Jul 05, 2012 at 10:34:10AM +0200, Henrik Rydberg wrote:
On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote:
Thanks for tracking down the source of this corruption. I don't have
any such hardware, so until someone can figure it out, I think we
should apply this patch.
On Mon, Jul 9, 2012 at 6:41 AM, Christian König deathsim...@vodafone.de wrote:
It's not critical, but the current code isn't
100% correct.
Signed-off-by: Christian König deathsim...@vodafone.de
---
drivers/gpu/drm/radeon/ni.c | 133
++-
1 file
On Mon, 2012-07-09 at 12:42 +0200, Christian König wrote:
Try to save whatever is on the rings when
we encounter an lockup.
Signed-off-by: Christian König deathsim...@vodafone.de
[...]
@@ -1005,20 +1010,43 @@ int radeon_gpu_reset(struct radeon_device *rdev)
resched =
On Mon, 2012-07-09 at 12:42 +0200, Christian König wrote:
Making it easier to controlwhen it is executed.
Signed-off-by: Christian König deathsim...@vodafone.de
[...]
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 254fdb4..bbd0971
On 09.07.2012 16:43, Jerome Glisse wrote:
On Mon, Jul 9, 2012 at 6:41 AM, Christian König deathsim...@vodafone.de wrote:
It's not critical, but the current code isn't
100% correct.
Signed-off-by: Christian König deathsim...@vodafone.de
---
drivers/gpu/drm/radeon/ni.c | 133
On 09.07.2012 17:06, Michel Dänzer wrote:
On Mon, 2012-07-09 at 12:42 +0200, Christian König wrote:
Making it easier to controlwhen it is executed.
Signed-off-by: Christian König deathsim...@vodafone.de
[...]
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
On 09.07.2012 17:06, Michel Dänzer wrote:
On Mon, 2012-07-09 at 12:42 +0200, Christian König wrote:
Try to save whatever is on the rings when
we encounter an lockup.
Signed-off-by: Christian König deathsim...@vodafone.de
[...]
@@ -1005,20 +1010,43 @@ int radeon_gpu_reset(struct radeon_device
On Mon, Jul 9, 2012 at 6:42 AM, Christian König deathsim...@vodafone.de wrote:
Signed-off-by: Christian König deathsim...@vodafone.de
Bit too complex to my taste, what about attached patch, it's lot
simpler. (Haven't tested
the patch but it should work)
Cheers,
Jerome
---
On Mon, 2012-07-09 at 17:22 +0200, Christian König wrote:
On 09.07.2012 17:06, Michel Dänzer wrote:
On Mon, 2012-07-09 at 12:42 +0200, Christian König wrote:
Making it easier to controlwhen it is executed.
Signed-off-by: Christian König deathsim...@vodafone.de
[...]
diff --git
On 09.07.2012 17:36, Jerome Glisse wrote:
On Mon, Jul 9, 2012 at 6:42 AM, Christian König deathsim...@vodafone.de wrote:
Signed-off-by: Christian König deathsim...@vodafone.de
Bit too complex to my taste, what about attached patch, it's lot
simpler. (Haven't tested
the patch but it should
On Mon, 2012-07-09 at 12:41 +0200, Christian König wrote:
Hi,
The following patchset tries to save and restore the not yet processed
commands
from the rings in case of a lockup and with that should make a userspace
problem with a single application far less problematic.
The first four
On Mon, Jul 9, 2012 at 11:59 AM, Michel Dänzer mic...@daenzer.net wrote:
On Mon, 2012-07-09 at 12:41 +0200, Christian König wrote:
Hi,
The following patchset tries to save and restore the not yet processed
commands
from the rings in case of a lockup and with that should make a userspace
On Mon, Jul 9, 2012 at 11:48 AM, Christian König
deathsim...@vodafone.de wrote:
On 09.07.2012 17:36, Jerome Glisse wrote:
On Mon, Jul 9, 2012 at 6:42 AM, Christian König deathsim...@vodafone.de
wrote:
Signed-off-by: Christian König deathsim...@vodafone.de
Bit too complex to my taste, what
I've done benchmarks and comparison between proprietary drivers and
Mesa, Mesa seems to be up to 200x slower compiling the same shader,
since i understand optimizing such part of code may take months or even
more, i have thought to solve it this way:
Upon calling glLinkProgram , an
Tiziano Bacocco tizi...@tizbac.dyndns.org writes:
I've done benchmarks and comparison between proprietary drivers and
Mesa, Mesa seems to be up to 200x slower compiling the same shader,
since i understand optimizing such part of code may take months or even
more, i have thought to solve it
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #63 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-07-10
00:21:56 PDT ---
Now running latest drm-next just in case. Always the same error, but with a
little something new: with regular kernel, once the GPU crashed, it stays
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #64 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-07-10
00:22:55 PDT ---
Created attachment 64052
-- https://bugs.freedesktop.org/attachment.cgi?id=64052
dmesg drm-next
dmesg with latest drm-next branch
--
Configure
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #65 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-07-10
00:23:46 PDT ---
Created attachment 64053
-- https://bugs.freedesktop.org/attachment.cgi?id=64053
xsession with drm-next
.xsession with drm-next branch
--
Presumably there needs to be a api-level mechanism to wait for the
background optimization to finish, so that piglit etc can validate the
behavior of the optimized shader?
-- Chris
On Tue, Jul 10, 2012 at 5:17 AM, Eric Anholt e...@anholt.net wrote:
Tiziano Bacocco tizi...@tizbac.dyndns.org
101 - 119 of 119 matches
Mail list logo
