[Bug 27192] [BISECTED]boot fail on kernel drm-radeon-testing/add NI pci ids
https://bugzilla.kernel.org/show_bug.cgi?id=27192 Alan changed: What|Removed |Added Component|Video(Other)|Video(DRI - non Intel) Assignee|drivers_video-other at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
radeon testing
On Tue, Aug 21, 2012 at 09:51:46AM -0400, Alex Deucher wrote:
> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti
> wrote:
> > Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
> > the machine. The likely culprit is commit 023e188e:
>
> yeah, vram is locked out at that point. I guess we probably need to
> block anyone from trying to access it.
I see; the 2 dev_warn would probably lock up the machine as well right?
> > I haven't tried backing out the commit yet, but looking at the diff I
> > see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
> > but evergreen_mc_program is called way before IRQ is set up. Is the
> > vblank counter running? Looks like we just hitting the timeout here...
>
> We aren't waiting for an interrupt, just polling the current crtc
> status until it enters the vblank region. The status and counters
> should be working as we only wait on displays that are enabled.
It appears that all the crtcs are considered active:
[4.260766] crtc 0 enabled 272696081 (this is the value of crtc_enabled)
[4.260766] crtc 0 wait for vblank 0x1 (0x1 means no timeout)
[4.260766] crtc 0: waited 33 [10] (number of loops of
radeon_get_vblank_counter)
[4.260766] crtc 1 enabled 272630544
[4.260766] crtc 1 wait for vblank 0x1
[4.260766] crtc 1: waited 10 [10]
[4.260766] crtc 2 enabled 4195088
[4.260766] crtc 2 wait for vblank 0x1
[4.260766] crtc 2: waited 10 [10]
[4.260766] crtc 3 enabled 4195088
[4.260766] crtc 3 wait for vblank 0x1
[4.260766] crtc 3: waited 10 [10]
[4.260766] crtc 4 enabled 4195088
[4.260766] crtc 4 wait for vblank 0x1
[4.260766] crtc 4: waited 10 [10]
[4.260766] crtc 5 enabled 4195088
[4.260766] crtc 5 wait for vblank 0x1
[4.260766] crtc 5: waited 10 [10]
Maybe the code should be checking EVERGREEN_CRTC_MASTER_EN?
I'm testing this patch and the boot is fast again:
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 2308c7d..72bf721 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1251,7 +1251,8 @@ void evergreen_mc_stop(struct radeon_device *rdev, struct
evergreen_mc_save *sav
WREG32(VGA_RENDER_CONTROL, 0);
/* blank the display controllers */
for (i = 0; i < rdev->num_crtc; i++) {
- crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
+ crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i])
&
+ EVERGREEN_CRTC_MASTER_EN;
if (crtc_enabled) {
save->crtc_enabled[i] = true;
if (ASIC_IS_DCE6(rdev)) {
Luca
radeon testing
On Tue, Aug 21, 2012 at 4:33 PM, Luca Tettamanti wrote:
> On Tue, Aug 21, 2012 at 09:51:46AM -0400, Alex Deucher wrote:
>> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti
>> wrote:
>> > Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
>> > the machine. The likely culprit is commit 023e188e:
>>
>> yeah, vram is locked out at that point. I guess we probably need to
>> block anyone from trying to access it.
>
> I see; the 2 dev_warn would probably lock up the machine as well right?
>
>> > I haven't tried backing out the commit yet, but looking at the diff I
>> > see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
>> > but evergreen_mc_program is called way before IRQ is set up. Is the
>> > vblank counter running? Looks like we just hitting the timeout here...
>>
>> We aren't waiting for an interrupt, just polling the current crtc
>> status until it enters the vblank region. The status and counters
>> should be working as we only wait on displays that are enabled.
>
> It appears that all the crtcs are considered active:
>
> [4.260766] crtc 0 enabled 272696081 (this is the value of crtc_enabled)
> [4.260766] crtc 0 wait for vblank 0x1 (0x1 means no timeout)
> [4.260766] crtc 0: waited 33 [10] (number of loops of
> radeon_get_vblank_counter)
> [4.260766] crtc 1 enabled 272630544
> [4.260766] crtc 1 wait for vblank 0x1
> [4.260766] crtc 1: waited 10 [10]
> [4.260766] crtc 2 enabled 4195088
> [4.260766] crtc 2 wait for vblank 0x1
> [4.260766] crtc 2: waited 10 [10]
> [4.260766] crtc 3 enabled 4195088
> [4.260766] crtc 3 wait for vblank 0x1
> [4.260766] crtc 3: waited 10 [10]
> [4.260766] crtc 4 enabled 4195088
> [4.260766] crtc 4 wait for vblank 0x1
> [4.260766] crtc 4: waited 10 [10]
> [4.260766] crtc 5 enabled 4195088
> [4.260766] crtc 5 wait for vblank 0x1
> [4.260766] crtc 5: waited 10 [10]
>
> Maybe the code should be checking EVERGREEN_CRTC_MASTER_EN?
>
> I'm testing this patch and the boot is fast again:
Yes, that's correct. I'll fix that up.
Alex
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 2308c7d..72bf721 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1251,7 +1251,8 @@ void evergreen_mc_stop(struct radeon_device *rdev,
> struct evergreen_mc_save *sav
> WREG32(VGA_RENDER_CONTROL, 0);
> /* blank the display controllers */
> for (i = 0; i < rdev->num_crtc; i++) {
> - crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL +
> crtc_offsets[i]);
> + crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL +
> crtc_offsets[i]) &
> + EVERGREEN_CRTC_MASTER_EN;
> if (crtc_enabled) {
> save->crtc_enabled[i] = true;
> if (ASIC_IS_DCE6(rdev)) {
>
>
> Luca
radeon testing
On 21.08.2012 15:51, Alex Deucher wrote:
> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti
> wrote:
>> On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
I just tested the rebased acpi_patches branch: ACPI part works fine, but
I see a big slow down during radeon driver initialization when the
screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
screen just flickers during boot). With initcall_debug I see:
[2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
...
[5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
3102147 usecs
For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not
very
informative, I'll try and get more info...
>>> Can you bisect?
>> I've put in some printk, this is the result:
>>
>> [2.403138] evergreen_mc_program
>> [2.403196] evergreen_mc_stop
>> ...
>> [4.268491] evergreen_mc_resume done
>> [4.268548] evergreen_mc_program done
>>
>> This is the patch:
>>
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
>> u32 tmp;
>> int i, j;
>>
>> + printk(KERN_INFO "%s\n", __func__);
>> +
>> /* Initialize HDP */
>> for (i = 0, j = 0; i < 32; i++, j += 0x18) {
>> WREG32((0x2c14 + j), 0x);
>> @@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
>> }
>> WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
>>
>> + printk(KERN_INFO "evergreen_mc_stop\n");
>> evergreen_mc_stop(rdev, );
>> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
>> if (evergreen_mc_wait_for_idle(rdev)) {
>> dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
>> }
>> +// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n");
>> +
>> /* Lockout access through VGA aperture*/
>> WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
>> /* Update configuration */
>> @@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
>> WREG32(MC_VM_AGP_TOP, 0x0FFF);
>> WREG32(MC_VM_AGP_BOT, 0x0FFF);
>> }
>> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
>> if (evergreen_mc_wait_for_idle(rdev)) {
>> dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
>> }
>> +// printk(KERN_INFO "evergreen_mc_resume\n");
>> evergreen_mc_resume(rdev, );
>> + printk(KERN_INFO "evergreen_mc_resume done\n");
>> /* we need to own VRAM, so turn off the VGA renderer here
>> * to stop it overwriting our objects */
>> rv515_vga_render_disable(rdev);
>>
>>
>> Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
>> the machine. The likely culprit is commit 023e188e:
> yeah, vram is locked out at that point. I guess we probably need to
> block anyone from trying to access it.
IIRC we have a rw-semaphore that you can writelock to prevent anything
from accessing vram.
But if you try to access VRAM from within the critical section (by using
a printk that tries to write something to the console) you probably end
up deadlocking the kernel.
Christian.
>
>> commit 023e188ec102330eb05ad264f675e869637478eb
>> Author: Alex Deucher
>> Date: Wed Aug 15 17:18:42 2012 -0400
>>
>> drm/radeon: properly handle mc_stop/mc_resume on evergreen+
>>
>> - Stop the displays from accessing the FB
>> - Block CPU access
>> - Turn off MC client access
>>
>> This should fix issues some users have seen, especially
>> with UEFI, when changing the MC FB location that result
>> in hangs or display corruption.
>>
>>
>>
>> I haven't tried backing out the commit yet, but looking at the diff I
>> see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
>> but evergreen_mc_program is called way before IRQ is set up. Is the
>> vblank counter running? Looks like we just hitting the timeout here...
>>
> We aren't waiting for an interrupt, just polling the current crtc
> status until it enters the vblank region. The status and counters
> should be working as we only wait on displays that are enabled. I'll
> double check the code however. Thanks for testing.
>
> Alex
>
>>
>>
>>
>> Luca
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
radeon testing
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
> On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
>> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
>> > I see a big slow down during radeon driver initialization when the
>> > screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
>> > screen just flickers during boot). With initcall_debug I see:
>> >
>> > [2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
>> > ...
>> > [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
>> > 3102147 usecs
>> >
>> > For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not
>> > very
>> > informative, I'll try and get more info...
>>
>> Can you bisect?
>
> I've put in some printk, this is the result:
>
> [2.403138] evergreen_mc_program
> [2.403196] evergreen_mc_stop
> ...
> [4.268491] evergreen_mc_resume done
> [4.268548] evergreen_mc_program done
>
> This is the patch:
>
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
> u32 tmp;
> int i, j;
>
> + printk(KERN_INFO "%s\n", __func__);
> +
> /* Initialize HDP */
> for (i = 0, j = 0; i < 32; i++, j += 0x18) {
> WREG32((0x2c14 + j), 0x);
> @@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
> }
> WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
>
> + printk(KERN_INFO "evergreen_mc_stop\n");
> evergreen_mc_stop(rdev, );
> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
> if (evergreen_mc_wait_for_idle(rdev)) {
> dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
> }
> +// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n");
> +
> /* Lockout access through VGA aperture*/
> WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
> /* Update configuration */
> @@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
> WREG32(MC_VM_AGP_TOP, 0x0FFF);
> WREG32(MC_VM_AGP_BOT, 0x0FFF);
> }
> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
> if (evergreen_mc_wait_for_idle(rdev)) {
> dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
> }
> +// printk(KERN_INFO "evergreen_mc_resume\n");
> evergreen_mc_resume(rdev, );
> + printk(KERN_INFO "evergreen_mc_resume done\n");
> /* we need to own VRAM, so turn off the VGA renderer here
> * to stop it overwriting our objects */
> rv515_vga_render_disable(rdev);
>
>
> Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
> the machine. The likely culprit is commit 023e188e:
yeah, vram is locked out at that point. I guess we probably need to
block anyone from trying to access it.
>
> commit 023e188ec102330eb05ad264f675e869637478eb
> Author: Alex Deucher
> Date: Wed Aug 15 17:18:42 2012 -0400
>
> drm/radeon: properly handle mc_stop/mc_resume on evergreen+
>
> - Stop the displays from accessing the FB
> - Block CPU access
> - Turn off MC client access
>
> This should fix issues some users have seen, especially
> with UEFI, when changing the MC FB location that result
> in hangs or display corruption.
>
>
>
> I haven't tried backing out the commit yet, but looking at the diff I
> see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
> but evergreen_mc_program is called way before IRQ is set up. Is the
> vblank counter running? Looks like we just hitting the timeout here...
>
We aren't waiting for an interrupt, just polling the current crtc
status until it enters the vblank region. The status and counters
should be working as we only wait on displays that are enabled. I'll
double check the code however. Thanks for testing.
Alex
>
>
>
> Luca
Re: radeon testing
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti kronos...@gmail.com wrote:
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
I just tested the rebased acpi_patches branch: ACPI part works fine, but
I see a big slow down during radeon driver initialization when the
screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
screen just flickers during boot). With initcall_debug I see:
[2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
...
[5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
3102147 usecs
For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not
very
informative, I'll try and get more info...
Can you bisect?
I've put in some printk, this is the result:
[2.403138] evergreen_mc_program
[2.403196] evergreen_mc_stop
...
[4.268491] evergreen_mc_resume done
[4.268548] evergreen_mc_program done
This is the patch:
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
u32 tmp;
int i, j;
+ printk(KERN_INFO %s\n, __func__);
+
/* Initialize HDP */
for (i = 0, j = 0; i 32; i++, j += 0x18) {
WREG32((0x2c14 + j), 0x);
@@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
}
WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
+ printk(KERN_INFO evergreen_mc_stop\n);
evergreen_mc_stop(rdev, save);
+// printk(KERN_INFO evergreen_mc_wait_for_idle\n);
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
}
+// printk(KERN_INFO evergreen_mc_wait_for_idle done\n);
+
/* Lockout access through VGA aperture*/
WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
/* Update configuration */
@@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(MC_VM_AGP_TOP, 0x0FFF);
WREG32(MC_VM_AGP_BOT, 0x0FFF);
}
+// printk(KERN_INFO evergreen_mc_wait_for_idle\n);
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
}
+// printk(KERN_INFO evergreen_mc_resume\n);
evergreen_mc_resume(rdev, save);
+ printk(KERN_INFO evergreen_mc_resume done\n);
/* we need to own VRAM, so turn off the VGA renderer here
* to stop it overwriting our objects */
rv515_vga_render_disable(rdev);
Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
the machine. The likely culprit is commit 023e188e:
yeah, vram is locked out at that point. I guess we probably need to
block anyone from trying to access it.
commit 023e188ec102330eb05ad264f675e869637478eb
Author: Alex Deucher alexander.deuc...@amd.com
Date: Wed Aug 15 17:18:42 2012 -0400
drm/radeon: properly handle mc_stop/mc_resume on evergreen+
- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access
This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.
i don't know what i'm talking about
I haven't tried backing out the commit yet, but looking at the diff I
see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
but evergreen_mc_program is called way before IRQ is set up. Is the
vblank counter running? Looks like we just hitting the timeout here...
We aren't waiting for an interrupt, just polling the current crtc
status until it enters the vblank region. The status and counters
should be working as we only wait on displays that are enabled. I'll
double check the code however. Thanks for testing.
Alex
/i don't know what i'm talking about
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon testing
On 21.08.2012 15:51, Alex Deucher wrote:
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti kronos...@gmail.com wrote:
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
I just tested the rebased acpi_patches branch: ACPI part works fine, but
I see a big slow down during radeon driver initialization when the
screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
screen just flickers during boot). With initcall_debug I see:
[2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
...
[5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
3102147 usecs
For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not very
informative, I'll try and get more info...
Can you bisect?
I've put in some printk, this is the result:
[2.403138] evergreen_mc_program
[2.403196] evergreen_mc_stop
...
[4.268491] evergreen_mc_resume done
[4.268548] evergreen_mc_program done
This is the patch:
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
u32 tmp;
int i, j;
+ printk(KERN_INFO %s\n, __func__);
+
/* Initialize HDP */
for (i = 0, j = 0; i 32; i++, j += 0x18) {
WREG32((0x2c14 + j), 0x);
@@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
}
WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
+ printk(KERN_INFO evergreen_mc_stop\n);
evergreen_mc_stop(rdev, save);
+// printk(KERN_INFO evergreen_mc_wait_for_idle\n);
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
}
+// printk(KERN_INFO evergreen_mc_wait_for_idle done\n);
+
/* Lockout access through VGA aperture*/
WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
/* Update configuration */
@@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(MC_VM_AGP_TOP, 0x0FFF);
WREG32(MC_VM_AGP_BOT, 0x0FFF);
}
+// printk(KERN_INFO evergreen_mc_wait_for_idle\n);
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
}
+// printk(KERN_INFO evergreen_mc_resume\n);
evergreen_mc_resume(rdev, save);
+ printk(KERN_INFO evergreen_mc_resume done\n);
/* we need to own VRAM, so turn off the VGA renderer here
* to stop it overwriting our objects */
rv515_vga_render_disable(rdev);
Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
the machine. The likely culprit is commit 023e188e:
yeah, vram is locked out at that point. I guess we probably need to
block anyone from trying to access it.
IIRC we have a rw-semaphore that you can writelock to prevent anything
from accessing vram.
But if you try to access VRAM from within the critical section (by using
a printk that tries to write something to the console) you probably end
up deadlocking the kernel.
Christian.
commit 023e188ec102330eb05ad264f675e869637478eb
Author: Alex Deucher alexander.deuc...@amd.com
Date: Wed Aug 15 17:18:42 2012 -0400
drm/radeon: properly handle mc_stop/mc_resume on evergreen+
- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access
This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.
i don't know what i'm talking about
I haven't tried backing out the commit yet, but looking at the diff I
see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
but evergreen_mc_program is called way before IRQ is set up. Is the
vblank counter running? Looks like we just hitting the timeout here...
We aren't waiting for an interrupt, just polling the current crtc
status until it enters the vblank region. The status and counters
should be working as we only wait on displays that are enabled. I'll
double check the code however. Thanks for testing.
Alex
/i don't know what i'm talking about
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon testing
On Tue, Aug 21, 2012 at 09:51:46AM -0400, Alex Deucher wrote:
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti kronos...@gmail.com wrote:
Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
the machine. The likely culprit is commit 023e188e:
yeah, vram is locked out at that point. I guess we probably need to
block anyone from trying to access it.
I see; the 2 dev_warn would probably lock up the machine as well right?
I haven't tried backing out the commit yet, but looking at the diff I
see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
but evergreen_mc_program is called way before IRQ is set up. Is the
vblank counter running? Looks like we just hitting the timeout here...
We aren't waiting for an interrupt, just polling the current crtc
status until it enters the vblank region. The status and counters
should be working as we only wait on displays that are enabled.
It appears that all the crtcs are considered active:
[4.260766] crtc 0 enabled 272696081 (this is the value of crtc_enabled)
[4.260766] crtc 0 wait for vblank 0x1 (0x1 means no timeout)
[4.260766] crtc 0: waited 33 [10] (number of loops of
radeon_get_vblank_counter)
[4.260766] crtc 1 enabled 272630544
[4.260766] crtc 1 wait for vblank 0x1
[4.260766] crtc 1: waited 10 [10]
[4.260766] crtc 2 enabled 4195088
[4.260766] crtc 2 wait for vblank 0x1
[4.260766] crtc 2: waited 10 [10]
[4.260766] crtc 3 enabled 4195088
[4.260766] crtc 3 wait for vblank 0x1
[4.260766] crtc 3: waited 10 [10]
[4.260766] crtc 4 enabled 4195088
[4.260766] crtc 4 wait for vblank 0x1
[4.260766] crtc 4: waited 10 [10]
[4.260766] crtc 5 enabled 4195088
[4.260766] crtc 5 wait for vblank 0x1
[4.260766] crtc 5: waited 10 [10]
Maybe the code should be checking EVERGREEN_CRTC_MASTER_EN?
I'm testing this patch and the boot is fast again:
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 2308c7d..72bf721 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1251,7 +1251,8 @@ void evergreen_mc_stop(struct radeon_device *rdev, struct
evergreen_mc_save *sav
WREG32(VGA_RENDER_CONTROL, 0);
/* blank the display controllers */
for (i = 0; i rdev-num_crtc; i++) {
- crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
+ crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i])
+ EVERGREEN_CRTC_MASTER_EN;
if (crtc_enabled) {
save-crtc_enabled[i] = true;
if (ASIC_IS_DCE6(rdev)) {
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon testing
On Tue, Aug 21, 2012 at 4:33 PM, Luca Tettamanti kronos...@gmail.com wrote:
On Tue, Aug 21, 2012 at 09:51:46AM -0400, Alex Deucher wrote:
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti kronos...@gmail.com wrote:
Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
the machine. The likely culprit is commit 023e188e:
yeah, vram is locked out at that point. I guess we probably need to
block anyone from trying to access it.
I see; the 2 dev_warn would probably lock up the machine as well right?
I haven't tried backing out the commit yet, but looking at the diff I
see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
but evergreen_mc_program is called way before IRQ is set up. Is the
vblank counter running? Looks like we just hitting the timeout here...
We aren't waiting for an interrupt, just polling the current crtc
status until it enters the vblank region. The status and counters
should be working as we only wait on displays that are enabled.
It appears that all the crtcs are considered active:
[4.260766] crtc 0 enabled 272696081 (this is the value of crtc_enabled)
[4.260766] crtc 0 wait for vblank 0x1 (0x1 means no timeout)
[4.260766] crtc 0: waited 33 [10] (number of loops of
radeon_get_vblank_counter)
[4.260766] crtc 1 enabled 272630544
[4.260766] crtc 1 wait for vblank 0x1
[4.260766] crtc 1: waited 10 [10]
[4.260766] crtc 2 enabled 4195088
[4.260766] crtc 2 wait for vblank 0x1
[4.260766] crtc 2: waited 10 [10]
[4.260766] crtc 3 enabled 4195088
[4.260766] crtc 3 wait for vblank 0x1
[4.260766] crtc 3: waited 10 [10]
[4.260766] crtc 4 enabled 4195088
[4.260766] crtc 4 wait for vblank 0x1
[4.260766] crtc 4: waited 10 [10]
[4.260766] crtc 5 enabled 4195088
[4.260766] crtc 5 wait for vblank 0x1
[4.260766] crtc 5: waited 10 [10]
Maybe the code should be checking EVERGREEN_CRTC_MASTER_EN?
I'm testing this patch and the boot is fast again:
Yes, that's correct. I'll fix that up.
Alex
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 2308c7d..72bf721 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1251,7 +1251,8 @@ void evergreen_mc_stop(struct radeon_device *rdev,
struct evergreen_mc_save *sav
WREG32(VGA_RENDER_CONTROL, 0);
/* blank the display controllers */
for (i = 0; i rdev-num_crtc; i++) {
- crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL +
crtc_offsets[i]);
+ crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL +
crtc_offsets[i])
+ EVERGREEN_CRTC_MASTER_EN;
if (crtc_enabled) {
save-crtc_enabled[i] = true;
if (ASIC_IS_DCE6(rdev)) {
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon testing
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
> > I see a big slow down during radeon driver initialization when the
> > screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
> > screen just flickers during boot). With initcall_debug I see:
> >
> > [2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
> > ...
> > [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
> > 3102147 usecs
> >
> > For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not
> > very
> > informative, I'll try and get more info...
>
> Can you bisect?
I've put in some printk, this is the result:
[2.403138] evergreen_mc_program
[2.403196] evergreen_mc_stop
...
[4.268491] evergreen_mc_resume done
[4.268548] evergreen_mc_program done
This is the patch:
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
u32 tmp;
int i, j;
+ printk(KERN_INFO "%s\n", __func__);
+
/* Initialize HDP */
for (i = 0, j = 0; i < 32; i++, j += 0x18) {
WREG32((0x2c14 + j), 0x);
@@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
}
WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
+ printk(KERN_INFO "evergreen_mc_stop\n");
evergreen_mc_stop(rdev, );
+// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n");
+
/* Lockout access through VGA aperture*/
WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
/* Update configuration */
@@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(MC_VM_AGP_TOP, 0x0FFF);
WREG32(MC_VM_AGP_BOT, 0x0FFF);
}
+// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+// printk(KERN_INFO "evergreen_mc_resume\n");
evergreen_mc_resume(rdev, );
+ printk(KERN_INFO "evergreen_mc_resume done\n");
/* we need to own VRAM, so turn off the VGA renderer here
* to stop it overwriting our objects */
rv515_vga_render_disable(rdev);
Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
the machine. The likely culprit is commit 023e188e:
commit 023e188ec102330eb05ad264f675e869637478eb
Author: Alex Deucher
Date: Wed Aug 15 17:18:42 2012 -0400
drm/radeon: properly handle mc_stop/mc_resume on evergreen+
- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access
This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.
I haven't tried backing out the commit yet, but looking at the diff I
see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
but evergreen_mc_program is called way before IRQ is set up. Is the
vblank counter running? Looks like we just hitting the timeout here...
Luca
radeon testing
On Thu, Aug 16, 2012 at 11:51:10AM -0400, Alex Deucher wrote: > I've gathered up the various outstanding radeon patches and put them > up in a tree for testing: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip > Some of these may end up in -fixes, but most of them are -next > material. I haven't had a chance to go through Christian's last set > of VM patches yet. > > Highlights: > - rom fetch fixes (UEFI, thunderbolt docks) > - major ACPI rework > - backlight control for newer asics Hi Alex, I just tested the rebased acpi_patches branch: ACPI part works fine, but I see a big slow down during radeon driver initialization when the screen goes black for a couple of seconds (with 3.5.0 + acpi patches the screen just flickers during boot). With initcall_debug I see: [2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552 ... [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 3102147 usecs For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not very informative, I'll try and get more info... Luca -- next part -- [0.00] BIOS-e820: [mem 0xaa99f000-0xaf2befff] usable [0.00] BIOS-e820: [mem 0xaf2bf000-0xaf6befff] reserved [0.00] BIOS-e820: [mem 0xaf6bf000-0xaf7befff] ACPI NVS [0.00] BIOS-e820: [mem 0xaf7bf000-0xaf7fefff] ACPI data [0.00] BIOS-e820: [mem 0xaf7ff000-0xaf7f] usable [0.00] BIOS-e820: [mem 0xaf80-0xafff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffd8-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001ceff] usable [0.00] NX (Execute Disable) protection: active [0.00] DMI 2.7 present. [0.00] DMI: TOSHIBA SATELLITE L855/Portable PC, BIOS 1.60 04/20/2012 [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x1cf000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-E7FFF write-protect [0.00] E8000-E write-combining [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 08000 mask FC000 write-back [0.00] 2 base 0AF80 mask FFF80 uncachable [0.00] 3 base 0B000 mask FF000 uncachable [0.00] 4 base 0FFC0 mask FFFC0 write-protect [0.00] 5 base 1 mask F write-back [0.00] 6 base 1CF00 mask FFF00 uncachable [0.00] 7 base 1D000 mask FF000 uncachable [0.00] 8 base 1E000 mask FE000 uncachable [0.00] 9 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: last_pfn = 0xaf800 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fe1b0-0x000fe1bf] mapped at [880fe1b0] [0.00] initial memory mapped: [mem 0x-0x1fff] [0.00] Base memory trampoline at [88097000] 97000 size 24576 [0.00] init_memory_mapping: [mem 0x-0xaf7f] [0.00] [mem 0x-0xaf7f] page 2M [0.00] kernel direct mapping tables up to 0xaf7f @ [mem 0x1fa8-0x1fff] [0.00] init_memory_mapping: [mem 0x1-0x1ceff] [0.00] [mem 0x1-0x1ceff] page 2M [0.00] kernel direct mapping tables up to 0x1ceff @ [mem 0xaf2b6000-0xaf2befff] [0.00] RAMDISK: [mem 0x3763c000-0x37b15fff] [0.00] ACPI: RSDP 000fe020 00024 (v02 TOSINV) [0.00] ACPI: XSDT af7fe210 0009C (v01 TOSINV TOSINV00 0001 0113) [0.00] ACPI: FACP af7fb000 0010C (v05 TOSINV TOSINV00 0001 ACPI 0004) [0.00] ACPI: DSDT af7f 07F66 (v01 TOSINV TOSINV00 ACPI 0004) [0.00] ACPI: FACS af7bb000 00040 [0.00] ACPI: UEFI af7fd000 00236 (v01 TOSINV TOSINV00 0001 ACPI 0004) [0.00] ACPI: ASF! af7fc000 000A5 (v32 TOSINV TOSINV00 0001 ACPI 0004) [0.00]
radeon testing
On Mon, Aug 20, 2012 at 8:30 AM, Luca Tettamanti wrote: > On Thu, Aug 16, 2012 at 11:51:10AM -0400, Alex Deucher wrote: >> I've gathered up the various outstanding radeon patches and put them >> up in a tree for testing: >> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip >> Some of these may end up in -fixes, but most of them are -next >> material. I haven't had a chance to go through Christian's last set >> of VM patches yet. >> >> Highlights: >> - rom fetch fixes (UEFI, thunderbolt docks) >> - major ACPI rework >> - backlight control for newer asics > > Hi Alex, > I just tested the rebased acpi_patches branch: ACPI part works fine, but > I see a big slow down during radeon driver initialization when the > screen goes black for a couple of seconds (with 3.5.0 + acpi patches the > screen just flickers during boot). With initcall_debug I see: > > [2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552 > ... > [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after > 3102147 usecs > > For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not > very > informative, I'll try and get more info... Can you bisect? Alex
Re: radeon testing
On Mon, Aug 20, 2012 at 8:30 AM, Luca Tettamanti kronos...@gmail.com wrote: On Thu, Aug 16, 2012 at 11:51:10AM -0400, Alex Deucher wrote: I've gathered up the various outstanding radeon patches and put them up in a tree for testing: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip Some of these may end up in -fixes, but most of them are -next material. I haven't had a chance to go through Christian's last set of VM patches yet. Highlights: - rom fetch fixes (UEFI, thunderbolt docks) - major ACPI rework - backlight control for newer asics Hi Alex, I just tested the rebased acpi_patches branch: ACPI part works fine, but I see a big slow down during radeon driver initialization when the screen goes black for a couple of seconds (with 3.5.0 + acpi patches the screen just flickers during boot). With initcall_debug I see: [2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552 ... [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 3102147 usecs For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not very informative, I'll try and get more info... Can you bisect? Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon testing
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
I just tested the rebased acpi_patches branch: ACPI part works fine, but
I see a big slow down during radeon driver initialization when the
screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
screen just flickers during boot). With initcall_debug I see:
[2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
...
[5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
3102147 usecs
For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not
very
informative, I'll try and get more info...
Can you bisect?
I've put in some printk, this is the result:
[2.403138] evergreen_mc_program
[2.403196] evergreen_mc_stop
...
[4.268491] evergreen_mc_resume done
[4.268548] evergreen_mc_program done
This is the patch:
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
u32 tmp;
int i, j;
+ printk(KERN_INFO %s\n, __func__);
+
/* Initialize HDP */
for (i = 0, j = 0; i 32; i++, j += 0x18) {
WREG32((0x2c14 + j), 0x);
@@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
}
WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
+ printk(KERN_INFO evergreen_mc_stop\n);
evergreen_mc_stop(rdev, save);
+// printk(KERN_INFO evergreen_mc_wait_for_idle\n);
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
}
+// printk(KERN_INFO evergreen_mc_wait_for_idle done\n);
+
/* Lockout access through VGA aperture*/
WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
/* Update configuration */
@@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(MC_VM_AGP_TOP, 0x0FFF);
WREG32(MC_VM_AGP_BOT, 0x0FFF);
}
+// printk(KERN_INFO evergreen_mc_wait_for_idle\n);
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
}
+// printk(KERN_INFO evergreen_mc_resume\n);
evergreen_mc_resume(rdev, save);
+ printk(KERN_INFO evergreen_mc_resume done\n);
/* we need to own VRAM, so turn off the VGA renderer here
* to stop it overwriting our objects */
rv515_vga_render_disable(rdev);
Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
the machine. The likely culprit is commit 023e188e:
commit 023e188ec102330eb05ad264f675e869637478eb
Author: Alex Deucher alexander.deuc...@amd.com
Date: Wed Aug 15 17:18:42 2012 -0400
drm/radeon: properly handle mc_stop/mc_resume on evergreen+
- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access
This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.
i don't know what i'm talking about
I haven't tried backing out the commit yet, but looking at the diff I
see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
but evergreen_mc_program is called way before IRQ is set up. Is the
vblank counter running? Looks like we just hitting the timeout here...
/i don't know what i'm talking about
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon testing
I've gathered up the various outstanding radeon patches and put them up in a tree for testing: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip Some of these may end up in -fixes, but most of them are -next material. I haven't had a chance to go through Christian's last set of VM patches yet. Highlights: - rom fetch fixes (UEFI, thunderbolt docks) - major ACPI rework - backlight control for newer asics Alex
radeon testing
I've gathered up the various outstanding radeon patches and put them up in a tree for testing: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip Some of these may end up in -fixes, but most of them are -next material. I haven't had a chance to go through Christian's last set of VM patches yet. Highlights: - rom fetch fixes (UEFI, thunderbolt docks) - major ACPI rework - backlight control for newer asics Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Is drm-radeon-testing broken for anyone else?
Oh I wasn't aware anyone still used it, I just pushed a branch for Jerome the other day to test something, its known broken. Oh, boy... sorry for the noise, then. This was caused by the way I am using git: I cloned the Linus Torvalds tree, and then used 'git add' to include several trees, like Ingo's tip, Greg's stable kernels, and (of course) drm-airlied. When you added that patch to d-r-testing, then some output was caused when I ran 'git remote update', and I assumed there was something happening there that might be interesting. I cherry pick commits from drm-fixes and drm-next into my own branch off of the latest GregKH stable kernel; this prevents me from facing consequences in other areas due to merge window insanity, but gives me early warning if radeon-related stuff is going to cause me problems in the future. Sorry about this, Dave! Dave Witbrodt ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Is drm-radeon-testing broken for anyone else?
On Tue, Jul 3, 2012 at 6:02 PM, David Witbrodt wrote: > Maybe I'm doing something wrong, but my cloned repo of > drm-radeon-testing is giving build errors. What I'm > seeing is Oh I wasn't aware anyone still used it, I just pushed a branch for Jerome the other day to test something, its known broken. Dave.
Is drm-radeon-testing broken for anyone else?
> Oh I wasn't aware anyone still used it, I just pushed a branch for > Jerome the other day to test something, its known broken. Oh, boy... sorry for the noise, then. This was caused by the way I am using git: I cloned the Linus Torvalds tree, and then used 'git add' to include several trees, like Ingo's "tip", Greg's stable kernels, and (of course) "drm-airlied". When you added that patch to d-r-testing, then some output was caused when I ran 'git remote update', and I assumed there was something happening there that might be interesting. I cherry pick commits from drm-fixes and drm-next into my own branch off of the latest GregKH stable kernel; this prevents me from facing consequences in other areas due to merge window insanity, but gives me early warning if radeon-related stuff is going to cause me problems in the future. Sorry about this, Dave! Dave Witbrodt
Is drm-radeon-testing broken for anyone else?
Maybe I'm doing something wrong, but my cloned repo of
drm-radeon-testing is giving build errors. What I'm
seeing is
[...]
CC drivers/gpu/drm/radeon/radeon_gem.o
drivers/gpu/drm/radeon/radeon_gem.c: In function ?radeon_gem_create_ioctl?:
drivers/gpu/drm/radeon/radeon_gem.c:221:3: error: implicit declaration of
function ?radeon_mutex_lock? [-Werror=implicit-function-declaration]
drivers/gpu/drm/radeon/radeon_gem.c:221:26: error: ?struct radeon_device?
has no member named ?cs_mutex?
drivers/gpu/drm/radeon/radeon_gem.c:222:3: error: implicit declaration of
function ?radeon_mutex_unlock? [-Werror=implicit-function-declaration]
drivers/gpu/drm/radeon/radeon_gem.c:222:28: error: ?struct radeon_device?
has no member named ?cs_mutex?
drivers/gpu/drm/radeon/radeon_gem.c: In function
?radeon_gem_set_domain_ioctl?:
drivers/gpu/drm/radeon/radeon_gem.c:268:26: error: ?struct radeon_device?
has no member named ?cs_mutex?
drivers/gpu/drm/radeon/radeon_gem.c:269:28: error: ?struct radeon_device?
has no member named ?cs_mutex?
cc1: some warnings being treated as errors
make[6]: *** [drivers/gpu/drm/radeon/radeon_gem.o] Error 1
Looking around a bit, I find this commit
commit 36ff39c4045ee71cd306f8af5f8c2a1c6e998eba
Author: Christian K?nig
Date: Wed May 9 10:07:08 2012 +0200
drm/radeon: replace cs_mutex with vm_mutex v3
replaces radeon_mutex_lock()/radeon_mutex_unlock() with
mutex_lock()/mutex_unlock()
in most places, eliminating it in others. A more recent commit
commit 0a01063d5fd7417175512f0f916629008c0a842e
Author: Jerome Glisse
Date: Wed Jun 27 14:14:21 2012 -0400
drm/radeon: disable any GPU activity after unrecovered lockup v5
introduces this hunk:
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index f28bd4b..74176c5 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -217,6 +217,22 @@ int radeon_gem_create_ioctl(struct drm_device *dev,
void *data,
uint32_t handle;
int r;
+ /* if in middle of gpu reset wait on the mutex, if reset
+* failed don't do anything, otherwise proceed.
+*/
+ if (!rdev->accel_working) {
+ /* lockup situation wait for cs mutex to be droped */
+ radeon_mutex_lock(>cs_mutex);
+ radeon_mutex_unlock(>cs_mutex);
+ /* we are after a gpu reset */
+ if (!rdev->accel_working) {
+ /* gpu reset failed, don't create anymore GPU
+* object
+*/
+ return -EBUSY;
+ }
+ }
+
If it's not just something stupid I've done on my local
machine, then it looks like the 0a01063d patch was
applied without noticing the changes made in 36ff39c4.
(If the problem is really just me, sorry for the spam/
noise.)
Dave W.
Is drm-radeon-testing broken for anyone else?
Maybe I'm doing something wrong, but my cloned repo of
drm-radeon-testing is giving build errors. What I'm
seeing is
[...]
CC drivers/gpu/drm/radeon/radeon_gem.o
drivers/gpu/drm/radeon/radeon_gem.c: In function ‘radeon_gem_create_ioctl’:
drivers/gpu/drm/radeon/radeon_gem.c:221:3: error: implicit declaration of
function ‘radeon_mutex_lock’ [-Werror=implicit-function-declaration]
drivers/gpu/drm/radeon/radeon_gem.c:221:26: error: ‘struct radeon_device’
has no member named ‘cs_mutex’
drivers/gpu/drm/radeon/radeon_gem.c:222:3: error: implicit declaration of
function ‘radeon_mutex_unlock’ [-Werror=implicit-function-declaration]
drivers/gpu/drm/radeon/radeon_gem.c:222:28: error: ‘struct radeon_device’
has no member named ‘cs_mutex’
drivers/gpu/drm/radeon/radeon_gem.c: In function
‘radeon_gem_set_domain_ioctl’:
drivers/gpu/drm/radeon/radeon_gem.c:268:26: error: ‘struct radeon_device’
has no member named ‘cs_mutex’
drivers/gpu/drm/radeon/radeon_gem.c:269:28: error: ‘struct radeon_device’
has no member named ‘cs_mutex’
cc1: some warnings being treated as errors
make[6]: *** [drivers/gpu/drm/radeon/radeon_gem.o] Error 1
Looking around a bit, I find this commit
commit 36ff39c4045ee71cd306f8af5f8c2a1c6e998eba
Author: Christian König deathsim...@vodafone.de
Date: Wed May 9 10:07:08 2012 +0200
drm/radeon: replace cs_mutex with vm_mutex v3
replaces radeon_mutex_lock()/radeon_mutex_unlock() with
mutex_lock()/mutex_unlock()
in most places, eliminating it in others. A more recent commit
commit 0a01063d5fd7417175512f0f916629008c0a842e
Author: Jerome Glisse jgli...@redhat.com
Date: Wed Jun 27 14:14:21 2012 -0400
drm/radeon: disable any GPU activity after unrecovered lockup v5
introduces this hunk:
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index f28bd4b..74176c5 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -217,6 +217,22 @@ int radeon_gem_create_ioctl(struct drm_device *dev,
void *data,
uint32_t handle;
int r;
+ /* if in middle of gpu reset wait on the mutex, if reset
+* failed don't do anything, otherwise proceed.
+*/
+ if (!rdev-accel_working) {
+ /* lockup situation wait for cs mutex to be droped */
+ radeon_mutex_lock(rdev-cs_mutex);
+ radeon_mutex_unlock(rdev-cs_mutex);
+ /* we are after a gpu reset */
+ if (!rdev-accel_working) {
+ /* gpu reset failed, don't create anymore GPU
+* object
+*/
+ return -EBUSY;
+ }
+ }
+
If it's not just something stupid I've done on my local
machine, then it looks like the 0a01063d patch was
applied without noticing the changes made in 36ff39c4.
(If the problem is really just me, sorry for the spam/
noise.)
Dave W.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Is drm-radeon-testing broken for anyone else?
On Tue, Jul 3, 2012 at 6:02 PM, David Witbrodt dawit...@sbcglobal.net wrote: Maybe I'm doing something wrong, but my cloned repo of drm-radeon-testing is giving build errors. What I'm seeing is Oh I wasn't aware anyone still used it, I just pushed a branch for Jerome the other day to test something, its known broken. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #11 from Andy Furniss 2011-02-28 08:17:35 PST --- (In reply to comment #8) > can you test with latest -ati master? > > I've got a 1080p video playing here now. Fixed for me on rv790. Can't see any jerkyness that isn't also present with old d-r-t + ddx without the fix. AFAIK no linux player will vsync properly so nothing is ever perfect. Generally xv wait for vline is much worse than gl unless full height of the screen is used (and then it will fall apart in the case of fps = refresh unless mplayer -nodouble is used). I've also found that cpufreq on_demand does not play well with mplayer and HD. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 Jan Buecken changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Jan Buecken 2011-02-28 05:30:17 PST --- Thanks, works with newest xf86-video-ati git (and d-r-t) on my rv630. Cannot confirm that it looks jerky... Greetings Jan B?cken. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #9 from Michael Lothian 2011-02-28 01:55:33 PST --- I quickly tested it before leaving the house this morning. Seems to be working, though it did look jerky -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #9 from Michael Lothian m...@fireburn.co.uk 2011-02-28 01:55:33 PST --- I quickly tested it before leaving the house this morning. Seems to be working, though it did look jerky -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 Jan Buecken jb@gmx.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Jan Buecken jb@gmx.de 2011-02-28 05:30:17 PST --- Thanks, works with newest xf86-video-ati git (and d-r-t) on my rv630. Cannot confirm that it looks jerky... Greetings Jan Bücken. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #11 from Andy Furniss li...@andyfurniss.entadsl.com 2011-02-28 08:17:35 PST --- (In reply to comment #8) can you test with latest -ati master? I've got a 1080p video playing here now. Fixed for me on rv790. Can't see any jerkyness that isn't also present with old d-r-t + ddx without the fix. AFAIK no linux player will vsync properly so nothing is ever perfect. Generally xv wait for vline is much worse than gl unless full height of the screen is used (and then it will fall apart in the case of fps = refresh unless mplayer -nodouble is used). I've also found that cpufreq on_demand does not play well with mplayer and HD. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #8 from Dave Airlie 2011-02-27 20:08:27 PST --- can you test with latest -ati master? I've got a 1080p video playing here now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #8 from Dave Airlie airl...@freedesktop.org 2011-02-27 20:08:27 PST --- can you test with latest -ati master? I've got a 1080p video playing here now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #7 from Andy Furniss 2011-02-23 02:28:40 PST --- (In reply to comment #6) > Does this commit to the ddx fix the issue? > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=91070cfd75d5607c4a72ace780f830f0ddb40e84 No. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #7 from Andy Furniss li...@andyfurniss.entadsl.com 2011-02-23 02:28:40 PST --- (In reply to comment #6) Does this commit to the ddx fix the issue? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=91070cfd75d5607c4a72ace780f830f0ddb40e84 No. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #6 from Alex Deucher 2011-02-22 22:05:12 PST --- Does this commit to the ddx fix the issue? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=91070cfd75d5607c4a72ace780f830f0ddb40e84 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #5 from Alex Deucher 2011-02-22 18:51:02 PST --- (In reply to comment #4) > > I don't test this yet, but is it necessary? Because it is maybe more important > that I just reverted > (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=6ee3727feedf15da9c776efca3c65519cf7bb10b) > and testet this d-r-t. And this kernel works ok. Thus this is the failing > patch > at the kernel side. > > But which patch / branch is wrong in reality? The d-r-t branch needs to be fixed up to not reject the linear aligned buffers from the ddx. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #4 from Jan Buecken 2011-02-22 18:33:48 PST --- (In reply to comment #3) > Is this still an issue with the latest commits in xf86-video-ati? Yes. Sorry, my git bisect log is misunderstanding: Ofcourse I tested xf86-video-ati from today, but I began with the bisect at the XV patches (I first thought they are the first failing patches, but after the problem holds without these patches, I began bisecting from the stable release). > This is > probably be related to the CS block size checking changes in d-r-t > (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=6ee3727feedf15da9c776efca3c65519cf7bb10b). Yes. > Does 2.6.38-rc6 or drm-fixes work ok? I don't test this yet, but is it necessary? Because it is maybe more important that I just reverted (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=6ee3727feedf15da9c776efca3c65519cf7bb10b) and testet this d-r-t. And this kernel works ok. Thus this is the failing patch at the kernel side. But which patch / branch is wrong in reality? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #3 from Alex Deucher 2011-02-22 08:25:33 PST --- Is this still an issue with the latest commits in xf86-video-ati? This is probably be related to the CS block size checking changes in d-r-t (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=6ee3727feedf15da9c776efca3c65519cf7bb10b). Does 2.6.38-rc6 or drm-fixes work ok? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #2 from Andy Furniss 2011-02-22 07:35:34 PST --- (In reply to comment #1) > The commit 7ac3a2e0bcdadff7c7172a9f833f526b526da16b belongs to the > xf86-video-ati git. (To make clear it does not belong to the > drm-radeon-testing > git branch). I also see this bug with on my rv790 32bit build. I notice that using d-r-t from January works OK with current git ddx. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 Jan Buecken changed: What|Removed |Added Summary|xf86-video-ati git and |xf86-video-ati git and |drm-radeon-testing git: CS |drm-radeon-testing git: CS |checker leads mplayer / vlc |checker let mplayer / vlc |to fail with xv |to fail with xv -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker leads mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 --- Comment #1 from Jan Buecken 2011-02-22 05:53:57 PST --- The commit 7ac3a2e0bcdadff7c7172a9f833f526b526da16b belongs to the xf86-video-ati git. (To make clear it does not belong to the drm-radeon-testing git branch). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34567] New: xf86-video-ati git and drm-radeon-testing git: CS checker leads mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 Summary: xf86-video-ati git and drm-radeon-testing git: CS checker leads mplayer / vlc to fail with xv Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: jb.faq at gmx.de With xf86-video-ati git and Dave Airlieds drm-radeon-testing branch I get a black or no image with some videos using mplayer (using xv and not gl). The cs checker breaks it. I can reproduce this problem with 1080p (not 720p) HD videos. This problem does not appear with the 2.6.37 kernel. This bug was introduced with 7ac3a2e0bcdadff7c7172a9f833f526b526da16b (I bisected this) I did the following: $mplayer -vo xv 1080pvideo.mp4 MPlayer SVN-r32624-4.4.4 (C) 2000-2010 MPlayer Team Spiele 1080pvideo.mp4. libavformat-Dateiformat erkannt! [lavf] stream 0: video (h264), -vid 0 [lavf] stream 1: audio (aac), -aid 0, -alang und VIDEO: [H264] 1920x1080 24bpp 25.000 fps 3710.3 kbps (452.9 kbyte/s) Clip-Info: major_brand: mp42 minor_version: 0 compatible_brands: isommp42 == ?ffne Videodecoder: [ffmpeg] FFmpeg's libavcodec codec family Ausgew?hlter Videocodec: [ffh264] vfm: ffmpeg (FFmpeg H.264) == == ?ffne Audiodecoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 15999->176400) Ausgew?hlter Audiocodec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) == AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starte Wiedergabe... Film-Aspekt ist 1.78:1 - Vorskalierung zur Korrektur der Seitenverh?ltnisse. VO: [xv] 1920x1080 => 1920x1080 Planar YV12 A: 1.9 V: 1.9 A-V: -0.000 ct: 0.000 0/ 0 73% 6% 1.9% 23 0 Beenden... (Ende) $tail /var/log/kernel/current Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Feb 22 12:48:02 [kernel] radeon :01:00.0: texture bo too small (960 540 1 2764800 -> 557056 have 3317760) Feb 22 12:48:02 [kernel] radeon :01:00.0: alignments 1024 256 8 256 Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Feb 22 12:48:02 [kernel] radeon :01:00.0: texture bo too small (960 540 1 2764800 -> 557056 have 3317760) Feb 22 12:48:02 [kernel] radeon :01:00.0: alignments 1024 256 8 256 Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Feb 22 12:48:02 [kernel] radeon :01:00.0: texture bo too small (960 540 1 2764800 -> 557056 have 3317760) Feb 22 12:48:02 [kernel] radeon :01:00.0: alignments 1024 256 8 256 Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! 7ac3a2e0bcdadff7c7172a9f833f526b526da16b is the first bad commit commit 7ac3a2e0bcdadff7c7172a9f833f526b526da16b Author: Alex Deucher Date: Thu Feb 10 14:24:50 2011 -0500 6xx+: switch to linear aligned rather than linear general linear aligned is supposedly more performant, but more importantly, linear general only works on the CB without slices. The texture blocks technically don't support linear general although, I think linear general gets upgraded to linear aligned in the hw which is why it currently works. Signed-off-by: Alex Deucher :04 04 8f830d90157a00f05dc79cd48b4daded8831119a 9fb173e14af75e2a88b2982d0925ab1da2d56671 M src $git bisect log git bisect start # good: [0a1a0513a61f392580bde39cca4880f2c19abc8d] bump version for release git bisect good 0a1a0513a61f392580bde39cca4880f2c19abc8d # bad: [3d10278ce511f5dabb68ed86ee43eaaf43585983] Xv: fix textured video alignment harder git bisect bad 3d10278ce511f5dabb68ed86ee43eaaf43585983 # good: [be67ded05621aff9c85525372fd119071d3278ec] 6xx/7xx: consolidate spi setup git bisect good be67ded05621aff9c85525372fd119071d3278ec # bad: [39104c6e8461cf49c1bb03a18858ad75a9d98b46] remove EVERGREENSetAccelState() git bisect bad 39104c6e8461cf49c1bb03a18858ad75a9d98b46 # bad: [7ac3a2e0bcdadff7c7172a9f833f526b526da16b] 6xx+: switch to linear aligned rather than linear general git bisect bad 7ac3a2e0bcdadff7c7172a9f833f526b526da16b # good: [e3145801b80fd4be4cf770128876e86e89bda66f] evergreen/NI: consolidate spi setup git bisect good e3145801b80fd4be4cf770128876e86e89bda66f -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You a
[Bug 34567] New: xf86-video-ati git and drm-radeon-testing git: CS checker leads mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 Summary: xf86-video-ati git and drm-radeon-testing git: CS checker leads mplayer / vlc to fail with xv Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: jb@gmx.de With xf86-video-ati git and Dave Airlieds drm-radeon-testing branch I get a black or no image with some videos using mplayer (using xv and not gl). The cs checker breaks it. I can reproduce this problem with 1080p (not 720p) HD videos. This problem does not appear with the 2.6.37 kernel. This bug was introduced with 7ac3a2e0bcdadff7c7172a9f833f526b526da16b (I bisected this) I did the following: $mplayer -vo xv 1080pvideo.mp4 MPlayer SVN-r32624-4.4.4 (C) 2000-2010 MPlayer Team Spiele 1080pvideo.mp4. libavformat-Dateiformat erkannt! [lavf] stream 0: video (h264), -vid 0 [lavf] stream 1: audio (aac), -aid 0, -alang und VIDEO: [H264] 1920x1080 24bpp 25.000 fps 3710.3 kbps (452.9 kbyte/s) Clip-Info: major_brand: mp42 minor_version: 0 compatible_brands: isommp42 == Öffne Videodecoder: [ffmpeg] FFmpeg's libavcodec codec family Ausgewählter Videocodec: [ffh264] vfm: ffmpeg (FFmpeg H.264) == == Öffne Audiodecoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 15999-176400) Ausgewählter Audiocodec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) == AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starte Wiedergabe... Film-Aspekt ist 1.78:1 - Vorskalierung zur Korrektur der Seitenverhältnisse. VO: [xv] 1920x1080 = 1920x1080 Planar YV12 A: 1.9 V: 1.9 A-V: -0.000 ct: 0.000 0/ 0 73% 6% 1.9% 23 0 Beenden... (Ende) $tail /var/log/kernel/current Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Feb 22 12:48:02 [kernel] radeon :01:00.0: texture bo too small (960 540 1 2764800 - 557056 have 3317760) Feb 22 12:48:02 [kernel] radeon :01:00.0: alignments 1024 256 8 256 Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Feb 22 12:48:02 [kernel] radeon :01:00.0: texture bo too small (960 540 1 2764800 - 557056 have 3317760) Feb 22 12:48:02 [kernel] radeon :01:00.0: alignments 1024 256 8 256 Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Feb 22 12:48:02 [kernel] radeon :01:00.0: texture bo too small (960 540 1 2764800 - 557056 have 3317760) Feb 22 12:48:02 [kernel] radeon :01:00.0: alignments 1024 256 8 256 Feb 22 12:48:02 [kernel] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! 7ac3a2e0bcdadff7c7172a9f833f526b526da16b is the first bad commit commit 7ac3a2e0bcdadff7c7172a9f833f526b526da16b Author: Alex Deucher alexdeuc...@gmail.com Date: Thu Feb 10 14:24:50 2011 -0500 6xx+: switch to linear aligned rather than linear general linear aligned is supposedly more performant, but more importantly, linear general only works on the CB without slices. The texture blocks technically don't support linear general although, I think linear general gets upgraded to linear aligned in the hw which is why it currently works. Signed-off-by: Alex Deucher alexdeuc...@gmail.com :04 04 8f830d90157a00f05dc79cd48b4daded8831119a 9fb173e14af75e2a88b2982d0925ab1da2d56671 M src $git bisect log git bisect start # good: [0a1a0513a61f392580bde39cca4880f2c19abc8d] bump version for release git bisect good 0a1a0513a61f392580bde39cca4880f2c19abc8d # bad: [3d10278ce511f5dabb68ed86ee43eaaf43585983] Xv: fix textured video alignment harder git bisect bad 3d10278ce511f5dabb68ed86ee43eaaf43585983 # good: [be67ded05621aff9c85525372fd119071d3278ec] 6xx/7xx: consolidate spi setup git bisect good be67ded05621aff9c85525372fd119071d3278ec # bad: [39104c6e8461cf49c1bb03a18858ad75a9d98b46] remove EVERGREENSetAccelState() git bisect bad 39104c6e8461cf49c1bb03a18858ad75a9d98b46 # bad: [7ac3a2e0bcdadff7c7172a9f833f526b526da16b] 6xx+: switch to linear aligned rather than linear general git bisect bad 7ac3a2e0bcdadff7c7172a9f833f526b526da16b # good: [e3145801b80fd4be4cf770128876e86e89bda66f] evergreen/NI: consolidate spi setup git bisect good e3145801b80fd4be4cf770128876e86e89bda66f -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because
[Bug 34567] xf86-video-ati git and drm-radeon-testing git: CS checker let mplayer / vlc to fail with xv
https://bugs.freedesktop.org/show_bug.cgi?id=34567 Jan Buecken jb@gmx.de changed: What|Removed |Added Summary|xf86-video-ati git and |xf86-video-ati git and |drm-radeon-testing git: CS |drm-radeon-testing git: CS |checker leads mplayer / vlc |checker let mplayer / vlc |to fail with xv |to fail with xv -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28342] When cold-booting gfx is messed up with latest drm-radeon-testing kernel
https://bugs.freedesktop.org/show_bug.cgi?id=28342 Fabio Pedretti changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #31 from Fabio Pedretti 2010-11-05 07:03:37 PDT --- The patch was merged to ddx. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28342] When cold-booting gfx is messed up with latest drm-radeon-testing kernel
https://bugs.freedesktop.org/show_bug.cgi?id=28342 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #31 from Fabio Pedretti fabio@libero.it 2010-11-05 07:03:37 PDT --- The patch was merged to ddx. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26635] [drm-radeon-testing] warning message that can't be true
https://bugs.freedesktop.org/show_bug.cgi?id=26635 Tobias Jakobi changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Jakobi 2010-10-15 17:03:38 PDT --- Can no longer reproduce this. Seems to be fixed! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30025] r600 kms, massave slowdown with latest drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=30025 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Andy Furniss 2010-09-05 05:33:47 PDT --- More info + patch in https://bugs.freedesktop.org/show_bug.cgi?id=29972 *** This bug has been marked as a duplicate of bug 29972 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30025] r600 kms, massave slowdown with latest drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=30025 --- Comment #2 from aaron 2010-09-05 05:05:55 PDT --- yep passing radeon.no_wb=1 to the kernel fixes it @glxgears i kinda expected that but i don't think im using it for one... im just trying to show the difference between reported and apparent frame-rate in certain situations - it just seems odd... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30025] r600 kms, massave slowdown with latest drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=30025 --- Comment #1 from Tobias Jakobi 2010-09-05 04:06:47 PDT --- I think this one is well knows, have you tried disabling writeback with no_wb=1 as radeon module parameter? Also note that gears is _not_ a benchmark. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30025] New: r600 kms, massave slowdown with latest drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=30025 Summary: r600 kms, massave slowdown with latest drm-radeon-testing Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: chainsawbike at gmail.com ive bisected to this commit: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=8b8d01dff630e9725828689d001ec9bc5baba0b7 odd thing i noted: if i run compiz with vblank_mode=0 and run glxgears it reports a frame-rate of about 1500 fps ( being the same as i get when running the previous revision kernel) but its still looks as slow as molasses if i unset vblank_mode then run it it reports about 5 fps but looks the same as before -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30025] New: r600 kms, massave slowdown with latest drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=30025 Summary: r600 kms, massave slowdown with latest drm-radeon-testing Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: chainsawb...@gmail.com ive bisected to this commit: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=8b8d01dff630e9725828689d001ec9bc5baba0b7 odd thing i noted: if i run compiz with vblank_mode=0 and run glxgears it reports a frame-rate of about 1500 fps ( being the same as i get when running the previous revision kernel) but its still looks as slow as molasses if i unset vblank_mode then run it it reports about 5 fps but looks the same as before -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30025] r600 kms, massave slowdown with latest drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=30025 --- Comment #1 from Tobias Jakobi liquid.a...@gmx.net 2010-09-05 04:06:47 PDT --- I think this one is well knows, have you tried disabling writeback with no_wb=1 as radeon module parameter? Also note that gears is _not_ a benchmark. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30025] r600 kms, massave slowdown with latest drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=30025 --- Comment #2 from aaron chainsawb...@gmail.com 2010-09-05 05:05:55 PDT --- yep passing radeon.no_wb=1 to the kernel fixes it @glxgears i kinda expected that but i don't think im using it for one... im just trying to show the difference between reported and apparent frame-rate in certain situations - it just seems odd... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30025] r600 kms, massave slowdown with latest drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=30025 Andy Furniss li...@andyfurniss.entadsl.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Andy Furniss li...@andyfurniss.entadsl.com 2010-09-05 05:33:47 PDT --- More info + patch in https://bugs.freedesktop.org/show_bug.cgi?id=29972 *** This bug has been marked as a duplicate of bug 29972 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Glitch in newer drm-next/drm-radeon-testing
On Mon, Aug 2, 2010 at 8:12 PM, Marius Gr?ger wrote: > Am 07.06.2010 00:15, wrote Dave Airlie: >> >> On Mon, Jun 7, 2010 at 3:52 AM, Marius Gr?ger >> ?wrote: >>> >>> Am 06.06.2010 18:47, schrieb James Simmons: >> Apologies for such an unspecific description, and for what almost >> seems >> like a support request for MythTV. I wouldn't post here if I were not >> 100% sure it must be related with the recent drm changes. > > Note that the DRM APIs are intended for use by userspace components of > graphics drivers / API libraries, not applications directly. MythTV > shouldn't use the DRM directly for synchronization but rather use GLX > synchronization APIs. Tho not the case for MythTV on a embedded device requiring apps to use GLX wuld be to heavy. I would agree libdrm should be used. >>> >>> I have found the cause for the glitch and just filed >>> http://bugs.freedesktop.org/show_bug.cgi?id=28411. >> >> Okay I can see the problem, now I have to think of a good solution, >> >> I probably need to break down the locking a bit further which is a bit >> messy. > > Is there any news on this issue? I didn't notice any commits to d-r-t or d-n > WRT this, but then again those repos aren't updated very frequently anyway > (how come?) > Should be fixed in 2.6.35 final, 29508eb66bfacdef324d2199eeaea31e0cdfaa29 drm/radeon/kms: drop taking lock around crtc lookup. Generally regression fixes go via the drm-fixes tree, the other trees get rebased/updated as patches arrive, we didn't really have much for d-r-t this cycle. Dave.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Mario Kleiner changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #30 from Mario Kleiner 2010-08-02 12:11:45 PDT --- Patch with fix now in mesa master. Closing as resolved. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Glitch in newer drm-next/drm-radeon-testing
Am 07.06.2010 00:15, wrote Dave Airlie: On Mon, Jun 7, 2010 at 3:52 AM, Marius Gröger marius.groe...@googlemail.com wrote: Am 06.06.2010 18:47, schrieb James Simmons: Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs. Tho not the case for MythTV on a embedded device requiring apps to use GLX wuld be to heavy. I would agree libdrm should be used. I have found the cause for the glitch and just filed http://bugs.freedesktop.org/show_bug.cgi?id=28411. Okay I can see the problem, now I have to think of a good solution, I probably need to break down the locking a bit further which is a bit messy. Is there any news on this issue? I didn't notice any commits to d-r-t or d-n WRT this, but then again those repos aren't updated very frequently anyway (how come?) Thanks T Regards, Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Glitch in newer drm-next/drm-radeon-testing
On Mon, Aug 2, 2010 at 8:12 PM, Marius Gröger marius.groe...@googlemail.com wrote: Am 07.06.2010 00:15, wrote Dave Airlie: On Mon, Jun 7, 2010 at 3:52 AM, Marius Gröger marius.groe...@googlemail.com wrote: Am 06.06.2010 18:47, schrieb James Simmons: Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs. Tho not the case for MythTV on a embedded device requiring apps to use GLX wuld be to heavy. I would agree libdrm should be used. I have found the cause for the glitch and just filed http://bugs.freedesktop.org/show_bug.cgi?id=28411. Okay I can see the problem, now I have to think of a good solution, I probably need to break down the locking a bit further which is a bit messy. Is there any news on this issue? I didn't notice any commits to d-r-t or d-n WRT this, but then again those repos aren't updated very frequently anyway (how come?) Should be fixed in 2.6.35 final, 29508eb66bfacdef324d2199eeaea31e0cdfaa29 drm/radeon/kms: drop taking lock around crtc lookup. Generally regression fixes go via the drm-fixes tree, the other trees get rebased/updated as patches arrive, we didn't really have much for d-r-t this cycle. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Mario Kleiner mario.klei...@tuebingen.mpg.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #30 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2010-08-02 12:11:45 PDT --- Patch with fix now in mesa master. Closing as resolved. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Mario Kleiner mario.klei...@tuebingen.mpg.de changed: What|Removed |Added Attachment #37401|0 |1 is obsolete|| Attachment #37414|0 |1 is obsolete|| --- Comment #29 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2010-08-01 19:55:22 PDT --- Created an attachment (id=37513) View: https://bugs.freedesktop.org/attachment.cgi?id=37513 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37513 radeon: Add DRI2 flush extension support so we synchronize properly to bufferswaps. Ok, i've merged all previous working patches into this patch and retested on current mesa master. I'll send this one to mesa-devel for inclusion. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #28 from Andy Furniss 2010-07-27 11:30:10 PDT --- (In reply to comment #27) > Created an attachment (id=37414) View: https://bugs.freedesktop.org/attachment.cgi?id=37414 Review: https://bugs.freedesktop.org/review?bug=28341=37414 > Fix frontbuffer rendering, avoid segfault in singlebuffer demo. > > This patch on top of the other patch works for me Also fixes for me. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #27 from Mario Kleiner 2010-07-27 10:50:26 PDT --- Created an attachment (id=37414) View: https://bugs.freedesktop.org/attachment.cgi?id=37414 Review: https://bugs.freedesktop.org/review?bug=28341=37414 Fix frontbuffer rendering, avoid segfault in singlebuffer demo. This patch on top of the other patch works for me with mesa's singlebuffer demo. It translants a little bit more logic from the intel driver to handle frontbuffer flushing and avoid infinite recursion which caused the segfault. I had to do radeon->front_buffer_dirty = GL_FALSE before calling flushFrontBuffer to avoid infinite recursion, whereas intel does it the other way round. Either i'm missing something (very likely), or intel does something subtile differently (likely), or the intel driver should have the same infinite recursion bug and segfault in singlebuffer demo. Anybody with an intel gpu to test singlebuffer demo? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #26 from Andy Furniss 2010-07-27 06:47:43 PDT --- (In reply to comment #25) > (In reply to comment #22) > > Created an attachment (id=37401) View: https://bugs.freedesktop.org/attachment.cgi?id=37401 Review: https://bugs.freedesktop.org/review?bug=28341=37401 > > Fix dri2 swap > > > > Can you confirm that the attach patch fix the issue for you (i have tested > > it > > on r200,r300,r600 and it seems to work UMS/KMS while also fixing what i > > believe > > is the issue you reported on KMS+DRI2) > > It fixes my test cases (ipers and sauerbraten) testing with rv770. I've found a regression caused by the patch, the mesa demo singlebuffer segfaults. singlebuffer[9]: segfault at bf634ff0 ip b77e2b97 sp bf634fd0 error 6 in libGL.so.1.2[b77a7000+4e000] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #25 from Andy Furniss 2010-07-27 03:26:58 PDT --- (In reply to comment #22) > Created an attachment (id=37401) View: https://bugs.freedesktop.org/attachment.cgi?id=37401 Review: https://bugs.freedesktop.org/review?bug=28341=37401 > Fix dri2 swap > > Can you confirm that the attach patch fix the issue for you (i have tested it > on r200,r300,r600 and it seems to work UMS/KMS while also fixing what i > believe > is the issue you reported on KMS+DRI2) It fixes my test cases (ipers and sauerbraten) testing with rv770. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #25 from Andy Furniss li...@andyfurniss.entadsl.com 2010-07-27 03:26:58 PDT --- (In reply to comment #22) Created an attachment (id=37401) View: https://bugs.freedesktop.org/attachment.cgi?id=37401 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37401 Fix dri2 swap Can you confirm that the attach patch fix the issue for you (i have tested it on r200,r300,r600 and it seems to work UMS/KMS while also fixing what i believe is the issue you reported on KMS+DRI2) It fixes my test cases (ipers and sauerbraten) testing with rv770. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #26 from Andy Furniss li...@andyfurniss.entadsl.com 2010-07-27 06:47:43 PDT --- (In reply to comment #25) (In reply to comment #22) Created an attachment (id=37401) View: https://bugs.freedesktop.org/attachment.cgi?id=37401 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37401 Fix dri2 swap Can you confirm that the attach patch fix the issue for you (i have tested it on r200,r300,r600 and it seems to work UMS/KMS while also fixing what i believe is the issue you reported on KMS+DRI2) It fixes my test cases (ipers and sauerbraten) testing with rv770. I've found a regression caused by the patch, the mesa demo singlebuffer segfaults. singlebuffer[9]: segfault at bf634ff0 ip b77e2b97 sp bf634fd0 error 6 in libGL.so.1.2[b77a7000+4e000] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #28 from Andy Furniss li...@andyfurniss.entadsl.com 2010-07-27 11:30:10 PDT --- (In reply to comment #27) Created an attachment (id=37414) View: https://bugs.freedesktop.org/attachment.cgi?id=37414 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37414 Fix frontbuffer rendering, avoid segfault in singlebuffer demo. This patch on top of the other patch works for me Also fixes for me. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #24 from Mario Kleiner 2010-07-26 17:31:53 PDT --- Jerome, your Improved patch works on R600 for me as well, thanks for improving it and teaching me about the proper draw functions for non-r600 gpu's :-). It took me half a day to initially find r700DrawPrim() as the proper location for R600. Looking at the code and comparing with the intel driver i think we should also add a radeon_prepare_render() to radeonReadPixels() in radeon_pixel_read.c, and the "copy from colorbuffer" path inside do_copy_texsubimage() in radeon_tex_copy.c ? Reading/Copying from the backbuffer/frontbuffer must also make sure it operates on the post-swap buffers, therefore wait for swap completion. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #23 from Andrew Randrianasulu 2010-07-26 14:30:28 PDT --- (In reply to comment #22) > Created an attachment (id=37401) View: https://bugs.freedesktop.org/attachment.cgi?id=37401 Review: https://bugs.freedesktop.org/review?bug=28341=37401 > Fix dri2 swap > > Can you confirm that the attach patch fix the issue for you (i have tested it > on r200,r300,r600 and it seems to work UMS/KMS while also fixing what i > believe > is the issue you reported on KMS+DRI2) Works for me on RV280 (DRI2 + xserver git, 1.9.0 RC 5, kernel 2.6.35-rc5+). Tested with wine 1.2 and 3DMark2001, DeusEx_demo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Jerome Glisse changed: What|Removed |Added Attachment #37366|0 |1 is obsolete|| Attachment #37368|0 |1 is obsolete|| --- Comment #22 from Jerome Glisse 2010-07-26 12:26:20 PDT --- Created an attachment (id=37401) View: https://bugs.freedesktop.org/attachment.cgi?id=37401 Review: https://bugs.freedesktop.org/review?bug=28341=37401 Fix dri2 swap Can you confirm that the attach patch fix the issue for you (i have tested it on r200,r300,r600 and it seems to work UMS/KMS while also fixing what i believe is the issue you reported on KMS+DRI2) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #23 from Andrew Randrianasulu rand...@mail.ru 2010-07-26 14:30:28 PDT --- (In reply to comment #22) Created an attachment (id=37401) View: https://bugs.freedesktop.org/attachment.cgi?id=37401 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37401 Fix dri2 swap Can you confirm that the attach patch fix the issue for you (i have tested it on r200,r300,r600 and it seems to work UMS/KMS while also fixing what i believe is the issue you reported on KMS+DRI2) Works for me on RV280 (DRI2 + xserver git, 1.9.0 RC 5, kernel 2.6.35-rc5+). Tested with wine 1.2 and 3DMark2001, DeusEx_demo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #24 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2010-07-26 17:31:53 PDT --- Jerome, your Improved patch works on R600 for me as well, thanks for improving it and teaching me about the proper draw functions for non-r600 gpu's :-). It took me half a day to initially find r700DrawPrim() as the proper location for R600. Looking at the code and comparing with the intel driver i think we should also add a radeon_prepare_render() to radeonReadPixels() in radeon_pixel_read.c, and the copy from colorbuffer path inside do_copy_texsubimage() in radeon_tex_copy.c ? Reading/Copying from the backbuffer/frontbuffer must also make sure it operates on the post-swap buffers, therefore wait for swap completion. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #21 from Shlomi Steinberg 2010-07-25 13:07:54 PDT --- Confirmed. Both patches fix etracer for me. r600, HD 3850. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #20 from Mario Kleiner 2010-07-25 08:26:41 PDT --- Created an attachment (id=37368) View: https://bugs.freedesktop.org/attachment.cgi?id=37368 Review: https://bugs.freedesktop.org/review?bug=28341=37368 Proof of concept "fix" for R600/R700. Act on dri2InvalidateDrawable(). This patch together with the previous patch applied to current mesa git master eliminates the flicker problem on my tested apps with a R600 card. A new function radeon_prepare_render() checks the timestamps that get updated by dri2InvalidateDrawable() to find out if a swap is in progress / buffers are invalidated. If so, it uses radeon_update_buffers() to get "new" buffers. That function will also throttle the client if a swap is still in progress. We'd need to add a call to radeon_prepare_render() to various places in the driver. This is what the intel driver does with intel_prepare_render() to avoid artifacts. I've only added a check to r700DrawPrims() to see if it works at all. I don't know at which other locations such calls would be needed (and i'm a bloody beginner), so this is a pretty sketchy start. -mario -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Mario Kleiner changed: What|Removed |Added Attachment #37317|0 |1 is obsolete|| --- Comment #19 from Mario Kleiner 2010-07-25 08:15:20 PDT --- Created an attachment (id=37366) View: https://bugs.freedesktop.org/attachment.cgi?id=37366 Review: https://bugs.freedesktop.org/review?bug=28341=37366 Add flush, invalidate on dri2 swap, fixed. Fixed version of Jerome's patch. The flush, invalidate extension was added at the wron place, therefore never called by the driver at dri2InvalidateBuffer() time. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Mario Kleiner mario.klei...@tuebingen.mpg.de changed: What|Removed |Added Attachment #37317|0 |1 is obsolete|| --- Comment #19 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2010-07-25 08:15:20 PDT --- Created an attachment (id=37366) View: https://bugs.freedesktop.org/attachment.cgi?id=37366 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37366 Add flush, invalidate on dri2 swap, fixed. Fixed version of Jerome's patch. The flush, invalidate extension was added at the wron place, therefore never called by the driver at dri2InvalidateBuffer() time. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #20 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2010-07-25 08:26:41 PDT --- Created an attachment (id=37368) View: https://bugs.freedesktop.org/attachment.cgi?id=37368 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37368 Proof of concept fix for R600/R700. Act on dri2InvalidateDrawable(). This patch together with the previous patch applied to current mesa git master eliminates the flicker problem on my tested apps with a R600 card. A new function radeon_prepare_render() checks the timestamps that get updated by dri2InvalidateDrawable() to find out if a swap is in progress / buffers are invalidated. If so, it uses radeon_update_buffers() to get new buffers. That function will also throttle the client if a swap is still in progress. We'd need to add a call to radeon_prepare_render() to various places in the driver. This is what the intel driver does with intel_prepare_render() to avoid artifacts. I've only added a check to r700DrawPrims() to see if it works at all. I don't know at which other locations such calls would be needed (and i'm a bloody beginner), so this is a pretty sketchy start. -mario -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #18 from Mario Kleiner 2010-07-22 13:23:07 PDT --- Jerome, as far as i can see, your flush, invalidate patch is in the right direction, but the dri2InvalidateDrawable() call just increments drawable->dri2.stamp and the current radeon dri driver in current mesa isn't checking the drawable->dri2.stamp for changes. The intel driver has checks like... if (drawable->lastStamp != drawable->dri2.stamp) intel_update_renderbuffers(driContext, drawable); ... in various places. Similar checks and calls to radeon_update_renderbuffers() would probably do the trick, because that would call DRI2GetBuffersWithFormat() etc. which will throttle properly until a swap is completed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #17 from Shlomi Steinberg 2010-07-22 11:09:51 PDT --- Patched today's mesa git. Still need vblank_mode=0. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #16 from Jerome Glisse 2010-07-22 10:00:00 PDT --- Created an attachment (id=37317) View: https://bugs.freedesktop.org/attachment.cgi?id=37317 Review: https://bugs.freedesktop.org/review?bug=28341=37317 Add flush,invalidate on swap with msc Please try if attached patch fix the issue for you (apply against mesa no change needed in ddx) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #16 from Jerome Glisse gli...@freedesktop.org 2010-07-22 10:00:00 PDT --- Created an attachment (id=37317) View: https://bugs.freedesktop.org/attachment.cgi?id=37317 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37317 Add flush,invalidate on swap with msc Please try if attached patch fix the issue for you (apply against mesa no change needed in ddx) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Shlomi Steinberg changed: What|Removed |Added CC||ssteinberg at gmail.com --- Comment #15 from Shlomi Steinberg 2010-07-16 08:16:32 PDT --- *** Bug 29098 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #14 from Andy Furniss 2010-07-16 06:02:09 PDT --- (In reply to comment #13) > (In reply to comment #12) > > Created an attachment (id=37035) View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341=37035 > > Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505 > > That fixes my two test cases - ipers and sauerbraten. I see that with today's mesa master another workaround is possible. vblank_mode=0 as an env (~/.drirc doesn't work for me) when running my test cases will fix the issue without the patch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Shlomi Steinberg ssteinb...@gmail.com changed: What|Removed |Added CC||ssteinb...@gmail.com --- Comment #15 from Shlomi Steinberg ssteinb...@gmail.com 2010-07-16 08:16:32 PDT --- *** Bug 29098 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #13 from Andy Furniss 2010-07-14 05:04:35 PDT --- (In reply to comment #12) > Created an attachment (id=37035) View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341=37035 > Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505 That fixes my two test cases - ipers and sauerbraten. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #12 from Michel D?nzer 2010-07-14 04:22:20 PDT --- Created an attachment (id=37035) View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341=37035 Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341
--- Comment #11 from Andy Furniss 2010-07-14
04:03:15 PDT ---
(In reply to comment #10)
> Does reverting xf86-video-ati Git commit
> 30591320ec46e491ba20904cc64f3405b51c6505 ('kms: add support for the MSC swap &
> sync API') fix this problem?
It doesn't revert on master for me.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341
--- Comment #10 from Michel D?nzer 2010-07-14 02:30:55
PDT ---
Does reverting xf86-video-ati Git commit
30591320ec46e491ba20904cc64f3405b51c6505 ('kms: add support for the MSC swap &
sync API') fix this problem?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341
--- Comment #10 from Michel Dänzer mic...@daenzer.net 2010-07-14 02:30:55 PDT
---
Does reverting xf86-video-ati Git commit
30591320ec46e491ba20904cc64f3405b51c6505 ('kms: add support for the MSC swap
sync API') fix this problem?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341
--- Comment #11 from Andy Furniss li...@andyfurniss.entadsl.com 2010-07-14
04:03:15 PDT ---
(In reply to comment #10)
Does reverting xf86-video-ati Git commit
30591320ec46e491ba20904cc64f3405b51c6505 ('kms: add support for the MSC swap
sync API') fix this problem?
It doesn't revert on master for me.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #12 from Michel Dänzer mic...@daenzer.net 2010-07-14 04:22:20 PDT --- Created an attachment (id=37035) View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37035 Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #13 from Andy Furniss li...@andyfurniss.entadsl.com 2010-07-14 05:04:35 PDT --- (In reply to comment #12) Created an attachment (id=37035) View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37035 Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505 That fixes my two test cases - ipers and sauerbraten. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27219] drm-radeon-testing branch bisected: Radeon xpress 200m freezes while booting
https://bugs.freedesktop.org/show_bug.cgi?id=27219 Alex Deucher changed: What|Removed |Added Blocks|29044 | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27219] drm-radeon-testing branch bisected: Radeon xpress 200m freezes while booting
https://bugs.freedesktop.org/show_bug.cgi?id=27219 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27219] drm-radeon-testing branch bisected: Radeon xpress 200m freezes while booting
https://bugs.freedesktop.org/show_bug.cgi?id=27219 Ian Romanick i...@freedesktop.org changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27219] drm-radeon-testing branch bisected: Radeon xpress 200m freezes while booting
https://bugs.freedesktop.org/show_bug.cgi?id=27219 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Blocks|29044 | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Michel D?nzer changed: What|Removed |Added CC||glisse at freedesktop.org --- Comment #9 from Michel D?nzer 2010-07-09 08:24:20 PDT --- Jerome, do you have a plan for fixing this, or should we just stop exposing DRI2 vsync again until there's a solution? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added CC||gli...@freedesktop.org --- Comment #9 from Michel Dänzer mic...@daenzer.net 2010-07-09 08:24:20 PDT --- Jerome, do you have a plan for fixing this, or should we just stop exposing DRI2 vsync again until there's a solution? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Mario Kleiner changed: What|Removed |Added CC||mario.kleiner at tuebingen.mpg ||.de --- Comment #8 from Mario Kleiner 2010-06-15 04:32:49 PDT --- Seems that some synchronisation in the radeon kernel drm driver is missing, which wasn't needed for the old synchronous vsync code; Old glXSwapbuffers code was synchronous: glXSwapBuffers blocked until swap completion. The new code just schedules a vblank event, then returns control to the client. The client submits further rendering commands into the command stream before the swap has completed, so you have a race-condition between the client submitting new commands for the post-swap backbuffer and the vblank event triggering submission of the "bufferswap blit" command buffer into the cs a couple of milliseconds after the glXSwapbuffers call. Depending on the relative timeing, it can happen that *new* rendering commands, e.g., glClear() get executed on the *old* backbuffer before it has been copied to the frontbuffer. Would result in random flickering or half-rendered frames overdrawn on top of old rendered frame. The solution would be to add some synchronisation to the kernel driver: If a swapbuffers is pending and a client tries to submit command buffers for that drawable, block it until swap completion. This is what the intel drivers apparently do and what seems to be missing fromt the radeon driver. Michel Daenzer confirmed my suspicion with some patch (conversation on dri-devel): "The ideal solution would probably be to make the kernel block in the command stream (CS) submission ioctl if the CS renders to (and from?) a buffer object (BO) which is involved in a pending swap. Meanwhile, the attached hacks for xf86-video-ati and Mesa seem to help here, YMMV." He added this patch to mesa inside the Dri2Swapbuffers submission code, after the swap has been scheduled: + +/* Make sure we call to the server before rendering again, in case we need + * to block for the swap */ +dri2InvalidateBuffers(dpyPriv->dpy, pdraw->drawable); This is what i found (also posted on dri-devel): "I saw a similar flickering with latest Xorg stack (mesa master, xserver, ddx etc. master) and the 2.6.34 tree from radeon testing with my own toolkit on a R600 gpu. This setup uses the new dri sync & swap bits and changes how glXSwapbuffers works. This shows flickering, but load and timing dependent... glXXX rendering commands to draw image. glXSwapBuffers(); glBegin(GL_POINTS); glVertex2i(10,10); glEnd(); glFinish(); Take a swap completion timestamp here. glClear(); ...more rendering commands -> I use this glVertex2i, glFinish() sequence to wait for swap completion and get a timestamp. This works on any os/gpu combo ever tested, but doesn't seem to work reliably anymore with the new radeon sync & swap bits in place. Display flickers, presumably because the glClear() executes almost immediately after the glXSwapBuffers is scheduled, and before the bufferswap has actually taken place -> Clear the backbuffer before swapping. This however: glXXX rendering commands to draw image. glXSwapBuffers(); glXWaitForSbcOML(...); glClear(); ... does work, because the new glXWaitForSbcOML() blocks the client until swap completion, so glClear() can only get submitted to the gpu after the swap completed." -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 Mario Kleiner mario.klei...@tuebingen.mpg.de changed: What|Removed |Added CC||mario.klei...@tuebingen.mpg ||.de --- Comment #8 from Mario Kleiner mario.klei...@tuebingen.mpg.de 2010-06-15 04:32:49 PDT --- Seems that some synchronisation in the radeon kernel drm driver is missing, which wasn't needed for the old synchronous vsync code; Old glXSwapbuffers code was synchronous: glXSwapBuffers blocked until swap completion. The new code just schedules a vblank event, then returns control to the client. The client submits further rendering commands into the command stream before the swap has completed, so you have a race-condition between the client submitting new commands for the post-swap backbuffer and the vblank event triggering submission of the bufferswap blit command buffer into the cs a couple of milliseconds after the glXSwapbuffers call. Depending on the relative timeing, it can happen that *new* rendering commands, e.g., glClear() get executed on the *old* backbuffer before it has been copied to the frontbuffer. Would result in random flickering or half-rendered frames overdrawn on top of old rendered frame. The solution would be to add some synchronisation to the kernel driver: If a swapbuffers is pending and a client tries to submit command buffers for that drawable, block it until swap completion. This is what the intel drivers apparently do and what seems to be missing fromt the radeon driver. Michel Daenzer confirmed my suspicion with some patch (conversation on dri-devel): The ideal solution would probably be to make the kernel block in the command stream (CS) submission ioctl if the CS renders to (and from?) a buffer object (BO) which is involved in a pending swap. Meanwhile, the attached hacks for xf86-video-ati and Mesa seem to help here, YMMV. He added this patch to mesa inside the Dri2Swapbuffers submission code, after the swap has been scheduled: + +/* Make sure we call to the server before rendering again, in case we need + * to block for the swap */ +dri2InvalidateBuffers(dpyPriv-dpy, pdraw-drawable); This is what i found (also posted on dri-devel): I saw a similar flickering with latest Xorg stack (mesa master, xserver, ddx etc. master) and the 2.6.34 tree from radeon testing with my own toolkit on a R600 gpu. This setup uses the new dri sync swap bits and changes how glXSwapbuffers works. This shows flickering, but load and timing dependent... glXXX rendering commands to draw image. glXSwapBuffers(); glBegin(GL_POINTS); glVertex2i(10,10); glEnd(); glFinish(); Take a swap completion timestamp here. glClear(); ...more rendering commands - I use this glVertex2i, glFinish() sequence to wait for swap completion and get a timestamp. This works on any os/gpu combo ever tested, but doesn't seem to work reliably anymore with the new radeon sync swap bits in place. Display flickers, presumably because the glClear() executes almost immediately after the glXSwapBuffers is scheduled, and before the bufferswap has actually taken place - Clear the backbuffer before swapping. This however: glXXX rendering commands to draw image. glXSwapBuffers(); glXWaitForSbcOML(...); glClear(); ... does work, because the new glXWaitForSbcOML() blocks the client until swap completion, so glClear() can only get submitted to the gpu after the swap completed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #7 from Andy Furniss 2010-06-14 16:56:56 PDT --- (In reply to comment #6) > possibly also related to bug 28383 and bug 28410. I am currently running with a patch that fixes 28383 but have just noticed that the mesa demo ipers does not render properly (with or without patch) - it's flashing until I reduce the LOD enough that the fps gets capped to refresh rate when it then renders OK. It renders OK with swrast and if I boot an older kernel that uses the old vsync. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
