dri-devel April 2011

dri-devel@lists.freedesktop.org

93 participants
440 discussions

[Bug 36099] New: Vertex distortion bug in the game Xonotic
by bugzilla-daemon＠freedesktop.org 06 May '11

06 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=36099 Summary: Vertex distortion bug in the game Xonotic Product: Mesa Version: 7.10 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: vand2(a)gmx.de In the Mesa versions 7.9.0 - 7.10.2 I get strange triangle distortion bugs in the game Xonotic. They don't appear in 7.8.2. http://xwmw.org/misc/triangle_bug_01.jpg http://xwmw.org/misc/triangle_bug_02.jpg glxinfo | grep string server glx vendor string: SGI server glx version string: 1.2 client glx vendor string: Mesa Project and SGI client glx version string: 1.4 OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RV570 OpenGL version string: 2.1 Mesa 7.10.2 OpenGL shading language version string: 1.20 Sebastian H. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 8

[Bug 35367] New: RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes
by bugzilla-daemon＠freedesktop.org 06 May '11

06 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=35367 Summary: RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: lists(a)andyfurniss.entadsl.com rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box. kernel d-r-t, git ddx with tiling enabled in xorg.conf. Does not affect my PCIE RV790 box. Mesa demo lodbias does not work normally since commit bdf103894026238c7e896eccb995b141161bfb70 Author: Marek OlÅ¡Ã¡k <maraeo(a)gmail.com> Date: Tue Mar 8 00:28:33 2011 +0100 st/mesa: remove unnecessary flushes The framebuffer cache flush should be implicit when calling set_framebuffer_state. There is no need to flush the command stream either. It disappears to black too quickly between 1.5 and 2.5 and the image is corrupt rather than blurring gradually during this time. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 34709] New: with r300 (rv530) kms loaded cannot suspend kernel 2.6.37+ with uswsusp
by bugzilla-daemon＠freedesktop.org 05 May '11

05 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=34709 Summary: with r300 (rv530) kms loaded cannot suspend kernel 2.6.37+ with uswsusp Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: hramrach(a)gmail.com After upgrading from kernel 2.6.36 to 2.6.37 I can no longer suspend the system with uswsusp. The suspend operation hangs with displays blanked before the part when "Saving image to disk" takes place. Suspending with "echo disk > /sys/power/state" works but is obviously useless as the system cannot be resumed. Upgrading to 2.6.38 does not help, not loading the radeon module allows to suspend as usual. A pointer to a repo with Radeon changesets between 2.6.36 and 2.6.37 without needlessly intermingled changes to other kernel parts would be appreciated. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 22

[Bug 35969] New: with linux 2.6.38 and later resume from suspend (uswsusp) lockups on rv530 kms
by bugzilla-daemon＠freedesktop.org 05 May '11

05 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=35969 Summary: with linux 2.6.38 and later resume from suspend (uswsusp) lockups on rv530 kms Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: hramrach(a)gmail.com Depends on: 34709 With the patch from bug 34709 system suspends and resumes on linux 2.6.37 and lockups on resume on 2.6.38 and linus head (2.6.39-rc1+) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

Re: Linux 2.6.39-rc5
by Melchior FRANZ 04 May '11

04 May '11

* Linus Torvalds -- Wednesday 27 April 2011: > Go forth and test, Doesn't work on my notebook with i915/KMS. But then again, neither did 2.6.38 or any of its stable releases. The last working version was 2.6.38-rc8. The problem has been reported[1], but the bug got closed in the wrong assumption that the bug is fixed. I reported that, too. No reactions to that. The bug was introduced with commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0 by Takashi Iwai. The result is that when using KMS my notebook's[2] screen remains dark, because the backlight isn't turned on. Reverting commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0 makes my notebook work correctly again as it used to in 2.6.38-rc8 and before. m. [1] https://bugzilla.kernel.org/show_bug.cgi?id=31522 [2] Acer TravelMate 5735Z-452G32Mnss, using Intel GM45

3 12

[RFC] swap event handling fixes
by Jesse Barnes 02 May '11

02 May '11

I obviously failed to count the swap event structure size after adding and removing fields a few times, and didn't even account for padding. The end result is that clients today won't receive the sbc_lo field at all, and so will likely stuff junk into that field on the client side (or zero at best). This patchset fixes up the structure definitions, bumps the proto levels, and adds server and client handling code for it all. It should be forward and backward compatible, but as always review and testing appreciated. I think the event_type checking on the client side still needs work; the field is split now so I need to check the right one on old servers. I'll also add swap support for the new requests in case people ever want to run this stuff between big and little endian machines. Thanks, Jesse

6 14

[Bug 32318] New: [r300g] Titan's atmosphere in celestia is blue with OpenGL 2.0 rendering path.
by bugzilla-daemon＠freedesktop.org 02 May '11

02 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=32318 Summary: [r300g] Titan's atmosphere in celestia is blue with OpenGL 2.0 rendering path. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: rankincj(a)googlemail.com Created an attachment (id=41009) --> (https://bugs.freedesktop.org/attachment.cgi?id=41009) Titan, as seen with OpenGL 2.0 rendering path Celestia 1.5.1, with r300g from git, RV350 card. When viewing Saturn's moon Titan with atmospheres enabled (Ctrl-A), the atmosphere appears orange for basic, multitexture and OpenGL vertex program rendering paths, but blue for OpenGL 2.0 rendering path. (Cycle through available rendering paths using Ctrl-V.) This inconsistency is suspicious - I suspect a bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 5

[PATCH 1/3] drm: Send pending vblank events before disabling vblank.
by christopher.halse.rogers＠canonical.com 02 May '11

02 May '11

From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> This is the least-bad behaviour. It means that we signal the vblank event before it actually happens, but since we're disabling vblanks there's no guarantee that it will *ever* happen otherwise. This prevents GL applications which use WaitMSC from hanging indefinitely. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> --- drivers/gpu/drm/drm_irq.c | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 741457b..a1f12cb 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -932,11 +932,34 @@ EXPORT_SYMBOL(drm_vblank_put); void drm_vblank_off(struct drm_device *dev, int crtc) { + struct drm_pending_vblank_event *e, *t; + struct timeval now; unsigned long irqflags; + unsigned int seq; spin_lock_irqsave(&dev->vbl_lock, irqflags); vblank_disable_and_save(dev, crtc); DRM_WAKEUP(&dev->vbl_queue[crtc]); + + /* Send any queued vblank events, lest the natives grow disquiet */ + seq = drm_vblank_count_and_time(dev, crtc, &now); + list_for_each_entry_safe(e, t, &dev->vblank_event_list, base.link) { + if (e->pipe != crtc) + continue; + DRM_DEBUG("Sending premature vblank event on disable: \ + wanted %d, current %d\n", + e->event.sequence, seq); + + e->event.sequence = seq; + e->event.tv_sec = now.tv_sec; + e->event.tv_usec = now.tv_usec; + drm_vblank_put(dev, e->pipe); + list_move_tail(&e->base.link, &e->base.file_priv->event_list); + wake_up_interruptible(&e->base.file_priv->event_wait); + trace_drm_vblank_event_delivered(e->base.pid, e->pipe, + e->event.sequence); + } + spin_unlock_irqrestore(&dev->vbl_lock, irqflags); } EXPORT_SYMBOL(drm_vblank_off); -- 1.7.4.1

5 21

[Bug 36256] New: Return to tty after leaving X problematic if using multiple cards since 2.6.32
by bugzilla-daemon＠freedesktop.org 01 May '11

01 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=36256 Summary: Return to tty after leaving X problematic if using multiple cards since 2.6.32 Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: connor.behan(a)gmail.com Created an attachment (id=45653) --> (https://bugs.freedesktop.org/attachment.cgi?id=45653) Dmesg output This bug affects me on every kernel from 2.6.38 to 2.6.32 inclusive. It is NOT present in 2.6.31. I have two video cards, my primary card is an r128 and my secondary card is a radeon. I have X setup to *only use the radeon*. Everything works perfectly before I startx, but once I start X and then leave it, every console on the primary r128 driven monitor is unusable. It does not seem to matter how I leave X. Logging out via xfce, "sudo killall X", Ctrl+Alt+Bksp, Ctrl+Alt+F1, all of these prevent me from using VTs on the primary monitor. When I say that these VTs are unusable, I mean that no text on them is ever shown to update. I can still technically use them by silently typing commands but I cannot see myself type. Now there are four different scenarios I've tried and they suggest that this bug is not caused by KMS: 1. No framebuffer on primary r128, modeset=0 on secondary radeon: The consoles stay on the primary monitor and once I start X and kill X, all these consoles are unusable. 2. No framebuffer on primary r128, modeset=1 on secondary radeon making it /dev/fb0: As soon as the radeon module gets loaded, the framebuffer on my secondary video card steals all the consoles so that they show up on the secondary monitor. Starting X and killing X is then OK for me because the focus returns to consoles that are on the same video card. Even though this "works" it means my r128 card that I like to use for consoles is just idling this is obviously not the optimal solution. 3. Uvesafb on primary r128 making it /dev/fb0, modeset=0 on secondary radeon: The framebuffer consoles appear on the primary monitor and once I start X and kill X, all these consoles are unusable. 4. Uvesafb on primary r128 making it /dev/fb0, modeset=1 on secondary radeon making it /dev/fb1: I can now freely move ttys between the two framebuffers using the "con2fb" tool. If I start X and then kill X, I can switch between these consoles with Alt+Fn and all the ones on /dev/fb1 work while all the ones on /dev/fb0 fail to update. I hope I'm explaining this well. Attached is my dmesg. Tell me if you need anything else. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 28627] New: 2.6.31.6 is the last kernel where KMS works well on an RV515 card for regular PCI
by bugzilla-daemon＠freedesktop.org 01 May '11

01 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=28627 Summary: 2.6.31.6 is the last kernel where KMS works well on an RV515 card for regular PCI Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: All Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: connor.behan(a)gmail.com After constant regressions, I thought I would post this. dmesg.good: http://pastebin.com/kL3iXTU3 xorglog.good: http://pastebin.com/n7diwRCL glxinfo.good: http://pastebin.com/aDajgYQC dmesg.bad: http://pastebin.com/JSKSD8Dn xorglog.bad: http://pastebin.com/QdDhfknr glxinfo.bad: http://pastebin.com/AWabZKN8 dmesg.reallybad: http://pastebin.com/Jc4sqySK xorglog.reallybad: http://pastebin.com/fzMEJfZH glxinfo.reallybad: http://pastebin.com/tkJgTgKa Good is kernel 2.6.31.6 where I get glxgears frame rates of ~300fps. This is all I can expect from a slow PCI bus. Bad is kenel 2.6.33.4 where the glxgears frame rates are a little slower, maybe 250fps and quitting X fails. Logging out of my desktop environment, Ctrl+Alt+F2, Ctrl+Alt+Backspace, chvt commands, all of these freeze my system. Reallybad is kernel 2.6.33.4 where glxgears has no consistent frame rate. It jumps around between 5fps and 60fps and all graphical programs are incredibly slow. This is in addition to the zapping issue described above. I am not sure why 2.6.33.4 is sometimes bad and sometimes reallybad. It might have to do with what USB devices are connected when it boots up. Please do not tell me to upgrade my userspace programs. I have tried every combination of xorg-server, mesa, xf86-video-ati and libdrm and none of them have any effect. The kernel is the ONLY package that changes how bad this bug is. Also please do not tell me to upgrade the kernel unless you are very sure that the version you are suggesting fixes this bug and you can tell me why it fixes it. I am not looking for a kernel that works. I KNOW which kernel works. I am trying to understand WHY it is the only one that works and hopefully help you fix this. Thank-you very much. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 28

← Newer
1
...
23
24
25
26
27
28
29
...
44
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2011