[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #17 from Vadim 2011-06-15 22:28:20 PDT --- (In reply to comment #16) > 2) water in-game is no longer rendered correctly, now only black blobs appear > where water should be. I hope the patch from bug 38280 will fix it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #16 from Brian Paterni 2011-06-15 21:43:42 PDT --- (In reply to comment #15) > Created an attachment (id=48019) View: https://bugs.freedesktop.org/attachment.cgi?id=48019 Review: https://bugs.freedesktop.org/review?bug=35434=48019 > patch > > Does this patch help? It does, broken ground textures do seem to be rendering correctly now for me! :) Although, it looks like some more problems have popped up since I last tested quake wars: 1) screen artifacts (image [2] originally cited in this bug) apparently have not been fixed within r600g/mesa as I had assumed. I only managed to work around the issue by setting r_useIndexBuffers=1 (game variable). Artifacts are still present when r_useIndexBuffers=0 (which is default) 2) water in-game is no longer rendered correctly, now only black blobs appear where water should be. 3) Some game scenery is not being rendered (some trees in refinery is all I've noticed so far) **Note: I tested ETQW both before and after applying your patch, Vadim, and I can say that your patch is *not* the cause of regressions 2 & 3 I will try and bisect 2 & 3 at some point in the future. It's a little too late for me to do it tonight yet. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #15 from Vadim 2011-06-15 20:13:00 PDT --- Created an attachment (id=48019) View: https://bugs.freedesktop.org/attachment.cgi?id=48019 Review: https://bugs.freedesktop.org/review?bug=35434=48019 patch Does this patch help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
CPU and GPU cache-coherence
On Mit, 2011-06-15 at 16:58 +0200, Michel D?nzer wrote: > On Die, 2011-06-07 at 21:42 +0800, Donnie Fang wrote: > > 3D render image on WC AGP aperture BO and then CPU fetch the image > > from this bo, in order to achieve performance, after 3D finished > > rendering, validate this bo into cached system memory and then read it > > from system memory. But I always get garbage from there. > > After check TTM bo validate codes, it has dealt with cache coherence > > properly, i wonder whether there is something I misunderstand or it is > > not allowed to move the WC bo from AGP to system memory for reading? > > Can you post patches showing what you've tried? Moving to the new dri-devel list at freedesktop.org, please only follow up there. -- Earthling Michel D?nzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
r600g TXD opcode (was: ... translation from TGSI failed / missing vertex shader)
On Wed, Jun 15, 2011 at 4:09 AM, Sven Arvidsson wrote: > On Tue, 2011-06-14 at 19:09 +0200, David Lamparter wrote: >> On Sun, Jun 05, 2011 at 10:32:34PM -0700, bugzilla-daemon at freedesktop.org >> wrote: >> > I'm attaching a patch that has an implementation. Unfortunately I can't >> > seem to >> > get it to work entirely correctly. The piglit test looks almost correct >> > but has >> > several artifacts in random places. If someone could point me in the right >> > direction (as I'm completely clueless), I would be happy to finish it. In >> > case >> > it matters, piglit does not show any new failures from this patch. >> >> Did you make any progress? This also affects EVE Online btw. > > AFAIK, you need to use the web interface to comment on bugs. Otherwise > Mike will miss this (unless he follows dri-devel): > https://bugs.freedesktop.org/show_bug.cgi?id=37476 Should all be fixed now in master. Dave.
Oops in i915 intel_init_clock_gating
On Wed, 15 Jun 2011, Jesse Barnes wrote: > On Wed, 15 Jun 2011 16:08:51 -0400 (EDT) > Alan Stern wrote: > > > The problem of dev_priv->display.init_clock_gating not getting set is > > still present in 3.0-rc3. On my system this happens because > > intel_init_display() never gets called in the first place. > > > > AFAICT, the normal calling sequence during driver initialization is: > > > > i915_driver_load() -> i915_load_modeset_init() -> > > intel_modeset_init() -> intel_init_display(). > > > > But in my case the call to i915_load_modeset_init() doesn't occur > > because drm_core_check_feature(dev, DRIVER_MODESET) is False. > > Ouch, a non-KMS config. Any reason you can't use KMS? Normally I do use it. This was a special testing config I've been nursing along for years, since well before KMS existed. Either I never enabled KMS in the config, or else at some point it caused trouble so I removed it and never added it back. Can't remember which -- all the testing I do with this config is at a VT, never under X. > This patch should help at any rate. I confirm that the patch fixes the problem. Thanks. On a different but related note, "rmmod i915" incites a lockdep notification: [ 54.316439] INFO: trying to register non-static key. [ 54.316589] the code is fine but needs lockdep annotation. [ 54.316729] turning off the locking correctness validator. [ 54.316871] Pid: 1683, comm: rmmod Not tainted 3.0.0-rc3 #2 [ 54.317011] Call Trace: [ 54.317153] [] ? printk+0xf/0x11 [ 54.317296] [] register_lock_class+0x58/0x2d7 [ 54.317438] [] ? get_parent_ip+0xb/0x31 [ 54.317579] [] ? is_module_text_address+0x37/0x45 [ 54.317722] [] ? __kernel_text_address+0x1c/0x3e [ 54.317864] [] __lock_acquire+0xa3/0xc5a [ 54.318005] [] ? dump_trace+0x7f/0xa5 [ 54.318146] [] ? __lock_acquire+0xc4b/0xc5a [ 54.318287] [] lock_acquire+0x5e/0x75 [ 54.318427] [] ? work_on_cpu+0x96/0x96 [ 54.318567] [] wait_on_work+0x3c/0x133 [ 54.318707] [] ? work_on_cpu+0x96/0x96 [ 54.318848] [] ? lock_timer_base.clone.23+0x20/0x3e [ 54.318991] [] ? _raw_spin_unlock_irqrestore+0x36/0x5b [ 54.319134] [] ? get_parent_ip+0xb/0x31 [ 54.319275] [] ? sub_preempt_count+0x7c/0x89 [ 54.319417] [] __cancel_work_timer+0xa0/0xde [ 54.319559] [] cancel_work_sync+0xa/0xc [ 54.319714] [] i915_driver_unload+0x136/0x224 [i915] [ 54.319874] [] drm_put_dev+0xa9/0x170 [drm] [ 54.320029] [] drm_pci_exit+0x49/0x63 [drm] [ 54.320045] [] i915_exit+0x12/0x742 [i915] [ 54.320045] [] sys_delete_module+0x175/0x1c1 [ 54.320045] [] ? remove_vma+0x52/0x58 [ 54.320045] [] ? restore_all+0xf/0xf [ 54.320045] [] sysenter_do_call+0x12/0x36 [ 54.336786] [drm] Module unloaded Is this a known problem? Alan Stern
CPU and GPU cache-coherence
On Die, 2011-06-07 at 21:42 +0800, Donnie Fang wrote: > 3D render image on WC AGP aperture BO and then CPU fetch the image > from this bo, in order to achieve performance, after 3D finished > rendering, validate this bo into cached system memory and then read it > from system memory. But I always get garbage from there. > After check TTM bo validate codes, it has dealt with cache coherence > properly, i wonder whether there is something I misunderstand or it is > not allowed to move the WC bo from AGP to system memory for reading? Can you post patches showing what you've tried? -- Earthling Michel D?nzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Oops in i915 intel_init_clock_gating
The problem of dev_priv->display.init_clock_gating not getting set is
still present in 3.0-rc3. On my system this happens because
intel_init_display() never gets called in the first place.
AFAICT, the normal calling sequence during driver initialization is:
i915_driver_load() -> i915_load_modeset_init() ->
intel_modeset_init() -> intel_init_display().
But in my case the call to i915_load_modeset_init() doesn't occur
because drm_core_check_feature(dev, DRIVER_MODESET) is False.
I tested with the following patch:
Index: usb-3.0/drivers/gpu/drm/i915/intel_display.c
===
--- usb-3.0.orig/drivers/gpu/drm/i915/intel_display.c
+++ usb-3.0/drivers/gpu/drm/i915/intel_display.c
@@ -7511,6 +7511,10 @@ void intel_init_clock_gating(struct drm_
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ if (!dev_priv->display.init_clock_gating) {
+ printk(KERN_WARNING "init_clock_gating not set!\n");
+ WARN_ON(1);
+ } else
dev_priv->display.init_clock_gating(dev);
if (dev_priv->display.init_pch_clock_gating)
Index: usb-3.0/drivers/gpu/drm/i915/i915_dma.c
===
--- usb-3.0.orig/drivers/gpu/drm/i915/i915_dma.c
+++ usb-3.0/drivers/gpu/drm/i915/i915_dma.c
@@ -2078,7 +2078,9 @@ int i915_driver_load(struct drm_device *
intel_detect_pch(dev);
+printk(KERN_INFO "Testing drm_core_check_feature DRIVER_MODESET\n");
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+printk(KERN_INFO "Calling i915_load_modeset_init\n");
ret = i915_load_modeset_init(dev);
if (ret < 0) {
DRM_ERROR("failed to init modeset\n");
Here is the dmesg log showing what happens during "insmod i915.ko":
[ 908.129497] pci :00:02.0: setting latency timer to 64
[ 908.179865] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 908.180633] [drm] No driver support for vblank timestamp query.
[ 908.180804] Testing drm_core_check_feature DRIVER_MODESET
[ 908.181120] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
The first debugging message is printed but not the second.
Here is what happens during a resume from system suspend:
[ 943.013656] init_clock_gating not set!
[ 943.013790] [ cut here ]
[ 943.013954] WARNING: at drivers/gpu/drm/i915/intel_display.c:7516
intel_init_clock_gating+0x30/0x4a [i915]()
[ 943.014193] Hardware name: HP dx2000 MT (EE004AA)
[ 943.014330] Modules linked in: i915 fbcon font bitblit softcursor
drm_kms_helper drm fb fbdev i2c_algo_bit cfbcopyarea i2c_core video backlight
cfbimgblt cfbfillrect e100 ohci_hcd mii pcspkr evdev uhci_hcd ehci_hcd fan
processor thermal_sys button usbcore [last unloaded: i915]
[ 943.015825] Pid: 1678, comm: bash Not tainted 3.0.0-rc3 #2
[ 943.015966] Call Trace:
[ 943.016179] [] warn_slowpath_common+0x65/0x7a
[ 943.016342] [] ? intel_init_clock_gating+0x30/0x4a [i915]
[ 943.016487] [] warn_slowpath_null+0xf/0x13
[ 943.016644] [] intel_init_clock_gating+0x30/0x4a [i915]
[ 943.016801] [] i915_restore_state+0xf4/0x1bf [i915]
[ 943.016989] [] i915_drm_thaw+0x41/0xc1 [i915]
[ 943.017141] [] i915_resume+0x38/0x4b [i915]
[ 943.017301] [] drm_class_resume+0x39/0x3b [drm]
[ 943.017447] [] legacy_resume+0x1e/0x46
[ 943.017599] [] ? drm_class_suspend+0x3d/0x3d [drm]
[ 943.017742] [] device_resume+0x83/0xa0
[ 943.017881] [] dpm_resume+0xdc/0x156
[ 943.018020] [] dpm_resume_end+0xb/0x15
[ 943.018162] [] suspend_devices_and_enter+0x165/0x192
[ 943.018330] [] enter_state+0xd2/0x123
[ 943.018471] [] state_store+0x95/0xa1
[ 943.018610] [] ? pm_async_store+0x33/0x33
[ 943.018752] [] kobj_attr_store+0x16/0x22
[ 943.018894] [] sysfs_write_file+0xb3/0xec
[ 943.019034] [] ? sysfs_open_file+0x1c2/0x1c2
[ 943.019176] [] vfs_write+0x76/0xa2
[ 943.019315] [] sys_write+0x3b/0x5d
[ 943.019456] [] sysenter_do_call+0x12/0x36
[ 943.019625] ---[ end trace dc74bd86a8bff7da ]---
What's the right way to fix this?
Alan Stern
[PATCH] drm/i915: add check for valid init_clock_gating-pointer
On Thu, 16 Jun 2011 00:24:39 +0200
Wolfram Sang wrote:
> Commit 6067aa (drm/i915: split clock gating init into per-chipset
> functions) unconditionally calls the newly created
> init_clock_gating-pointer. There is one case, however, where it does
> not get set:
>
> if (HAS_PCH_SPLIT(dev)) {
> ...
> } else
> dev_priv->display.update_wm = NULL;
> }
We'll only hit this path on non-existent hardware. Since a clock
gating routine is required I'd rather just see the panic and add a new
routine at that time (i.e. what we normally do during bringup).
--
Jesse Barnes, Intel Open Source Technology Center
Oops in i915 intel_init_clock_gating
On Wed, 15 Jun 2011 16:08:51 -0400 (EDT)
Alan Stern wrote:
> The problem of dev_priv->display.init_clock_gating not getting set is
> still present in 3.0-rc3. On my system this happens because
> intel_init_display() never gets called in the first place.
>
> AFAICT, the normal calling sequence during driver initialization is:
>
> i915_driver_load() -> i915_load_modeset_init() ->
> intel_modeset_init() -> intel_init_display().
>
> But in my case the call to i915_load_modeset_init() doesn't occur
> because drm_core_check_feature(dev, DRIVER_MODESET) is False.
Ouch, a non-KMS config. Any reason you can't use KMS?
This patch should help at any rate.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0defd42..a1a28fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -429,6 +429,9 @@ static int i915_drm_thaw(struct drm_device *dev)
/* KMS EnterVT equivalent */
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
mutex_lock(>struct_mutex);
+
+ intel_init_clock_gating(dev);
+
dev_priv->mm.suspended = 0;
error = i915_gem_init_ringbuffer(dev);
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 60a94d2..b478d16 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -863,8 +863,6 @@ int i915_restore_state(struct drm_device *dev)
I915_WRITE(IMR, dev_priv->saveIMR);
}
- intel_init_clock_gating(dev);
-
if (IS_IRONLAKE_M(dev)) {
ironlake_enable_drps(dev);
intel_init_emon(dev);
[PATCH] DRM: clean up and document parsing of video= parameter
[Bug 37502] Kernels oops display in X leaves screen garbled
https://bugzilla.kernel.org/show_bug.cgi?id=37502 --- Comment #2 from T?r?k Edwin 2011-06-15 12:56:01 --- Created an attachment (id=62122) --> (https://bugzilla.kernel.org/attachment.cgi?id=62122) garbled screen photo -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 37502] Kernels oops display in X leaves screen garbled
https://bugzilla.kernel.org/show_bug.cgi?id=37502 --- Comment #1 from T?r?k Edwin 2011-06-15 12:54:47 --- Created an attachment (id=62112) --> (https://bugzilla.kernel.org/attachment.cgi?id=62112) Xorg.0.log.old -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 37502] New: Kernels oops display in X leaves screen garbled
https://bugzilla.kernel.org/show_bug.cgi?id=37502 Summary: Kernels oops display in X leaves screen garbled Product: Drivers Version: 2.5 Kernel Version: 3.0.0-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: edwintorok at gmail.com Regression: No Created an attachment (id=62102) --> (https://bugzilla.kernel.org/attachment.cgi?id=62102) dmesg I got some BUG_ONs/warnings from the kernel, and every time it happened I ended up with a garbled screen (see attached photo). Switching to a virtual console, and back to X (twice) restored my desktop. I don't know if the kernel is trying to switch to a text console to display the Oops, or if it tries to display the oops on the graphical console, but apparently its not working well. The first time I get an Oops after a reboot I get to see the Oops text on a black background (and my mouse cursor, which makes me believe this is the graphical KMS console), but everything after that just leaves me with a garbled screen. The oops displayed is: https://lkml.org/lkml/2011/6/15/50 I don't know if this is a regression or not, I rarely get Oopses, and last time I got a panic message I was able to see it (although I was in X at the time), but then so can I for the 1st Oops message. My graphics card is: 01:00.0 VGA compatible controller: ATI Technologies Inc RV730 PRO [Radeon HD 4650] I use KMS, Xorg 1.10.2, and Mesa 7.10.2-3. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 38353] r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 --- Comment #4 from XoD 2011-06-15 12:12:33 PDT --- Created an attachment (id=48013) --> (https://bugs.freedesktop.org/attachment.cgi?id=48013) Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38353] r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 --- Comment #3 from XoD 2011-06-15 12:11:49 PDT --- Created an attachment (id=48012) --> (https://bugs.freedesktop.org/attachment.cgi?id=48012) dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38353] r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 --- Comment #2 from Alex Deucher 2011-06-15 12:04:42 PDT --- Also what hardware are you using? Can you attach your dmesg output? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38353] r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 --- Comment #1 from Alex Deucher 2011-06-15 12:04:03 PDT --- which piglit test(s) cause this? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38353] New: r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 Summary: r600g : lock in desktop display durring piglit test Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: xoddark at gmail.com with the commit : r600g: Allow VRAM for the initial domain for every buffer binding. (b0f1767d776e2c80cab4343b4cd59553fbf5e48a) I have a "lock" in desktop display during : I can move the mouse, the cursor position is updated. But background display is not updated, and mouse don't interact with desktop. If I revert this change on git HEAD, I don't have the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] DRM: clean up and document parsing of video= parameter
The video= parameter of the DRM drivers supports some additional flags that
the normal fb drivers do not have. They also allow to limit these flags to
specific outputs. Both things were previously undocumented.
Also the parsing of the line had some oddities:
-A lot of misplaced options were silently ignored or partly rejected instead
of stopping the parsing immediately
-The 'R' option is documented to follow the 'M' option if specified. It is not
documented that 'M' is needed to specify 'R' (also this is the case for normal
fb drivers). In fact the code is correct for normal fb drivers but wrong for
DRM ones.
The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only
if 'M' is given at all which is not needed for the DRM drivers.
-the margins option ('m') was parsed but later ignored even if the later
functions support it.
-specifying multiple enable options at the same time did not lead to an error.
-specifying something bogus for horizontal resolution (i.e. other things as
digits) did not lead to an error but an invalid resolution was used.
If any errors are encountered the position of the faulting string is now
printed to the user and the complete mode is ignored. This gives much
more consistent error behaviour.
I also removed some useless assignments and changed the local flag variables
to be bool.
Signed-off-by: Rolf Eike Beer
---
Documentation/fb/modedb.txt | 21 +-
drivers/gpu/drm/drm_modes.c | 87 +-
2 files changed, 78 insertions(+), 30 deletions(-)
diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt
index ec4dee7..16aa084 100644
--- a/Documentation/fb/modedb.txt
+++ b/Documentation/fb/modedb.txt
@@ -20,7 +20,7 @@ in a video= option, fbmem considers that to be a global video
mode option.
Valid mode specifiers (mode_option argument):
-x[M][R][-][@][i][m]
+x[M][R][-][@][i][m][eDd]
[-][@]
with , , and decimal numbers and a string.
@@ -36,6 +36,21 @@ pixels and 1.8% of yres).
Sample usage: 1024x768M at 60m - CVT timing with margins
+DRM drivers also add options to enable or disable outputs:
+
+'e' will force the display to be enabled, i.e. it will override the detection
+if a display is connected. 'D' will force the display to be enabled and use
+digital output. This is useful for outputs that have both analog and digital
+signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd'
+is specified the output is disabled.
+
+You can additionally specify which output the options matches to.
+To force the VGA output to be enabled and drive a specific mode say:
+video=VGA-1:1280x1024 at 60me
+
+Specifying the option multiple times for different ports is possible, e.g.:
+video=LVDS-1:d video=HDMI-1:D
+
* oOo * oOo * oOo * oOo * oOo * oOo * oOo *
What is the VESA(TM) Coordinated Video Timings (CVT)?
@@ -132,5 +147,5 @@ There may be more modes.
tridentfb - Trident (Cyber)blade chipset frame buffer
vt8623fb - VIA 8623 frame buffer
-BTW, only a few drivers use this at the moment. Others are to follow
-(feel free to send patches).
+BTW, only a few fb drivers use this at the moment. Others are to follow
+(feel free to send patches). The DRM drivers also support this.
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c2d32f2..ad74fb4 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -994,9 +994,10 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
{
const char *name;
unsigned int namelen;
- int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
+ bool res_specified = false, bpp_specified = false, refresh_specified =
false;
unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0;
- int yres_specified = 0, cvt = 0, rb = 0, interlace = 0, margins = 0;
+ bool yres_specified = false, cvt = false, rb = false;
+ bool interlace = false, margins = false, was_digit = false;
int i;
enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;
@@ -1015,54 +1016,65 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
for (i = namelen-1; i >= 0; i--) {
switch (name[i]) {
case '@':
- namelen = i;
if (!refresh_specified && !bpp_specified &&
- !yres_specified) {
+ !yres_specified && !cvt && !rb && was_digit) {
refresh = simple_strtol([i+1], NULL, 10);
- refresh_specified = 1;
- if (cvt || rb)
- cvt = 0;
+ refresh_specified = true;
+ was_digit = false;
} else
goto done;
[PATCH] drm: populate irq_by_busid-member for pci
Commit 8410ea (drm: rework PCI/platform driver interface) implemented
drm_pci_irq_by_busid() but forgot to make it available in the
drm_pci_bus-struct.
This caused a freeze on my Radeon9600-equipped laptop when executing glxgears.
Thanks to Michel for noticing the flaw.
Reported-by: Michel D?nzer
Signed-off-by: Wolfram Sang
Cc: Dave Airlie
---
stable-candidate, 2.6.39 is affected, too.
drivers/gpu/drm/drm_pci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index e1aee4f..e4e7fde 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -292,6 +292,7 @@ static struct drm_bus drm_pci_bus = {
.get_name = drm_pci_get_name,
.set_busid = drm_pci_set_busid,
.set_unique = drm_pci_set_unique,
+ .irq_by_busid = drm_pci_irq_by_busid,
.agp_init = drm_pci_agp_init,
};
--
1.7.2.5
[RFC] Updated DRM plane handling patches
On Tue, 7 Jun 2011 13:07:38 -0700
Jesse Barnes wrote:
> This patchset updates the previous one, incorporating the feedback I
> received:
> 1) uses the v4l fourcc codes to communicate pixel format
> 2) adds a new addfb ioctl that takes a format
> 3) adds working SNB support for the new code
>
> Comments welcome. I'll be pushing intel-gpu-tools testdisplay support
> for this shortly if people want to play around with it. Next step is to
> incorporate it into X and Wayland to see if the API is rich enough for
> our needs.
And here's a very early & hackish DDX patch for this code in case other
people want to test things out. I still have to update it with the
scaling stuff we talked about and support various things (disabling
planes, controlling attributes, etc) but it's enough to get bits on the
screen at least.
Jesse
diff --git a/src/Makefile.am b/src/Makefile.am
index a7f219c..2aec5a8 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -69,6 +69,7 @@ intel_drv_la_SOURCES = \
i965_reg.h \
i965_video.c \
i965_render.c \
+intel_sprite.c \
$(NULL)
if DRI
diff --git a/src/intel.h b/src/intel.h
index 2b114c3..11d911a 100644
--- a/src/intel.h
+++ b/src/intel.h
@@ -334,6 +334,7 @@ typedef struct intel_screen_private {
int colorKey;
XF86VideoAdaptorPtr adaptor;
+ XF86VideoAdaptorPtr sprite_adaptor;
ScreenBlockHandlerProcPtr BlockHandler;
Bool overlayOn;
@@ -461,6 +462,7 @@ extern void intel_mode_fini(intel_screen_private *intel);
extern int intel_get_pipe_from_crtc_id(drm_intel_bufmgr *bufmgr, xf86CrtcPtr
crtc);
extern int intel_crtc_id(xf86CrtcPtr crtc);
+extern int intel_crtc_to_sprite(xf86CrtcPtr crtc);
extern int intel_output_dpms_status(xf86OutputPtr output);
enum DRI2FrameEventType {
@@ -518,6 +520,7 @@ extern void I915EmitInvarientState(ScrnInfoPtr scrn);
extern void I830EmitFlush(ScrnInfoPtr scrn);
extern void I830InitVideo(ScreenPtr pScreen);
+extern XF86VideoAdaptorPtr intel_setup_sprite(ScreenPtr screen);
extern xf86CrtcPtr intel_covering_crtc(ScrnInfoPtr scrn, BoxPtr box,
xf86CrtcPtr desired, BoxPtr crtc_box_ret);
diff --git a/src/intel_display.c b/src/intel_display.c
index b55b110..4b032af 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -75,6 +75,7 @@ struct intel_crtc {
dri_bo *rotate_bo;
uint32_t rotate_pitch;
uint32_t rotate_fb_id;
+ uint32_t sprite_id;
xf86CrtcPtr crtc;
struct list link;
};
@@ -1564,9 +1565,50 @@ drm_wakeup_handler(pointer data, int err, pointer p)
drmHandleEvent(mode->fd, >event_context);
}
+static void intel_crtc_find_plane(ScrnInfoPtr scrn, xf86CrtcPtr crtc)
+{
+ intel_screen_private *intel = intel_get_screen_private(scrn);
+ struct intel_crtc *intel_crtc = crtc->driver_private;
+ drmModePlaneRes *plane_resources;
+ drmModePlane *ovr;
+ uint32_t id = 0;
+ int i;
+
+ plane_resources = drmModeGetPlaneResources(intel->drmSubFD);
+ if (!plane_resources) {
+ xf86DrvMsg(scrn->scrnIndex, X_ERROR,
+ "failed to get plane resources: %s\n",
+ strerror(errno));
+ goto out;
+ }
+
+ for (i = 0; i < plane_resources->count_planes; i++) {
+ ovr = drmModeGetPlane(intel->drmSubFD,
+ plane_resources->planes[i]);
+ if (!ovr) {
+ xf86DrvMsg(scrn->scrnIndex, X_ERROR,
+ "failed to get plane info: %s\n",
+ strerror(errno));
+ continue;
+ }
+
+ if (ovr->possible_crtcs & (1 << intel_crtc_to_pipe(crtc))) {
+ id = ovr->plane_id;
+ drmModeFreePlane(ovr);
+ break;
+ }
+ drmModeFreePlane(ovr);
+ }
+
+ free(plane_resources);
+out:
+ intel_crtc->sprite_id = id;
+}
+
Bool intel_mode_pre_init(ScrnInfoPtr scrn, int fd, int cpp)
{
intel_screen_private *intel = intel_get_screen_private(scrn);
+ struct intel_crtc *intel_crtc;
struct drm_i915_getparam gp;
struct intel_mode *mode;
unsigned int i;
@@ -1597,6 +1639,9 @@ Bool intel_mode_pre_init(ScrnInfoPtr scrn, int fd, int
cpp)
for (i = 0; i < mode->mode_res->count_crtcs; i++)
intel_crtc_init(scrn, mode, i);
+ list_for_each_entry(intel_crtc, >crtcs, link)
+ intel_crtc_find_plane(scrn, intel_crtc->crtc);
+
for (i = 0; i < mode->mode_res->count_connectors; i++)
intel_output_init(scrn, mode, i);
@@ -1618,6 +1663,8 @@ Bool intel_mode_pre_init(ScrnInfoPtr scrn, int fd, int
cpp)
}
intel->modes = mode;
+
+
return TRUE;
}
@@ -1687,3 +1734,9 @@ int
[Bug 37442] Radeon 9600 Mobile (RV350) freezes on glxgears - bisected
https://bugzilla.kernel.org/show_bug.cgi?id=37442 --- Comment #6 from Wolfram Sang 2011-06-15 09:33:53 --- Created an attachment (id=62092) --> (https://bugzilla.kernel.org/attachment.cgi?id=62092) Proposed fix Thanks Michel, great pointer! The attached patch fixes the issue here; also sent it to the dri-devel list a minute ago. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 30122] r600 scrambled render when using 2d texture sample for 1d texture co-ord in fragment shader
https://bugs.freedesktop.org/show_bug.cgi?id=30122 Thomas Jones changed: What|Removed |Added Component|Drivers/Gallium/r600|Drivers/DRI/R600 --- Comment #5 from Thomas Jones 2011-06-15 08:36:29 PDT --- (In reply to comment #4) > Created an attachment (id=47987) --> (https://bugs.freedesktop.org/attachment.cgi?id=47987) > r600c incorrect rendering > > Tested with HD4850 + mesa from git : > * r600g rendering is correct > * r600c rendering is still wrong (see attached image) > > Could you confirm it is fixed for you as well with r600g ? > > If it's the case, maybe this bug should be assigned to r600c ? Indeed you are correct, it does seem to be fixed on r600c in git, any idea what commit did it? It would probably be useful to point it out so whoever tries to fix r600c can see it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37442] Radeon 9600 Mobile (RV350) freezes on glxgears - bisected
https://bugzilla.kernel.org/show_bug.cgi?id=37442 --- Comment #5 from Michel D?nzer 2011-06-15 07:59:16 --- Dave, the implicated commit doesn't seem to hook up drm_pci_irq_by_busid anywhere. That's probably not intended? :) Not sure why the compiler doesn't complain about it... Not sure that can explain anything with KMS enabled though... Wolfram, does reverting just this commit fix things with KMS enabled as well? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 37442] Radeon 9600 Mobile (RV350) freezes on glxgears - bisected
https://bugzilla.kernel.org/show_bug.cgi?id=37442 --- Comment #4 from Wolfram Sang 2011-06-15 07:38:53 --- KMS works now, was a kernel misconfiguration (forgot to disable radeonfb, doh!). Interestingly, KMS does work with AGP4x while the Xorg driver can just handle AGP2x (also freezes the machine otherwise). Original bug still stands; checked the faulty commit but couldn't spot anything. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36921] Sanctuary: Rendering errors with shader quality set to high
https://bugs.freedesktop.org/show_bug.cgi?id=36921 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Sven Arvidsson 2011-06-15 05:54:25 PDT --- Fixed with current git master 40aec11. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36920] Lightsmark: not rendering correctly
https://bugs.freedesktop.org/show_bug.cgi?id=36920 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Sven Arvidsson 2011-06-15 05:50:51 PDT --- Fixed with current git master 40aec11. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37225] Penumbra: Motion blur not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=37225 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Sven Arvidsson 2011-06-15 05:46:00 PDT --- Fixed with current git master 40aec11. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36944] Family Farm: misrenders on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=36944 --- Comment #3 from Sven Arvidsson 2011-06-15 05:32:47 PDT --- Still a problem for me with git-40aec11, I guess it could be something specific to Evergreen? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38190] Amnesia / RenderFeatTest graphical glitches with refraction
https://bugs.freedesktop.org/show_bug.cgi?id=38190 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Sven Arvidsson 2011-06-15 05:28:09 PDT --- This is fixed with current git master a128355. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37261] Norsetto shadow mapping doesn't render correctly
https://bugs.freedesktop.org/show_bug.cgi?id=37261 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Sven Arvidsson 2011-06-15 05:18:19 PDT --- This is fixed with git master a128355. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36523] water reflections misrendered in sauerbraten with "shaders=high" setting
https://bugs.freedesktop.org/show_bug.cgi?id=36523 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Sven Arvidsson 2011-06-15 05:17:29 PDT --- Great! Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33371] [RADEON:KMS:R600G] zsnes output all garbage when OpenGL is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=33371 --- Comment #2 from Pierre-Eric Pelloux-Prayer 2011-06-15 03:13:53 PDT --- Works fine here using r600g + mesa 40aec11b7569fcdd2d884629b172af3db3fbaf1d (it looks fine too using Debian's mesa : "Mesa DRI R600 (RV770 9442) 20090101 TCL 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 38280] [bisected] regression : etqw tree/water wrong rendering
https://bugs.freedesktop.org/show_bug.cgi?id=38280 --- Comment #6 from Andy Furniss 2011-06-15 02:21:07 PDT --- (In reply to comment #4) > Created an attachment (id=47965) View: https://bugs.freedesktop.org/attachment.cgi?id=47965 Review: https://bugs.freedesktop.org/review?bug=38280=47965 > patch > > This patch should restore previous behaviour for r600 hw. Works for me with etqw and doom3-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 36523] water reflections misrendered in sauerbraten with "shaders=high" setting
https://bugs.freedesktop.org/show_bug.cgi?id=36523 --- Comment #5 from Stefano Teso 2011-06-15 02:16:10 PDT --- (In reply to comment #4) > This seems to be fixed with current git master, can you confirm? Yes, confirming with latest git master. Feel free to close this bug. Thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36944] Family Farm: misrenders on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=36944 --- Comment #2 from Pierre-Eric Pelloux-Prayer 2011-06-15 02:07:34 PDT --- Game renders correctly here using HD4850 (using mesa 27d3e0b25... or latest git). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38335] [r600g] Missing item/action icons in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=38335 --- Comment #1 from Chris Rankin 2011-06-15 02:05:01 PDT --- I should also point out that this does not happen with either my RV350 or M66GL (r300g). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30122] r600 scrambled render when using 2d texture sample for 1d texture co-ord in fragment shader
https://bugs.freedesktop.org/show_bug.cgi?id=30122 --- Comment #4 from Pierre-Eric Pelloux-Prayer 2011-06-15 02:04:40 PDT --- Created an attachment (id=47987) --> (https://bugs.freedesktop.org/attachment.cgi?id=47987) r600c incorrect rendering Tested with HD4850 + mesa from git : * r600g rendering is correct * r600c rendering is still wrong (see attached image) Could you confirm it is fixed for you as well with r600g ? If it's the case, maybe this bug should be assigned to r600c ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38335] New: [r600g] Missing item/action icons in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=38335 Summary: [r600g] Missing item/action icons in World of Warcraft 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: rankincj at googlemail.com Created an attachment (id=47986) --> (https://bugs.freedesktop.org/attachment.cgi?id=47986) Screenshot, showing all of my "blank" items. In World of Warcraft, the icons that represent items, actions or spells disappear over time. As a rule, everything starts off fine. The rot starts as you actually play the game. This is the only major issue left playing WoW with my HD4890. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38280] [bisected] regression : etqw tree/water wrong rendering
https://bugs.freedesktop.org/show_bug.cgi?id=38280 --- Comment #5 from Pierre-Eric Pelloux-Prayer 2011-06-15 00:27:58 PDT --- (In reply to comment #4) > This patch should restore previous behaviour for r600 hw. Just tested it on ETQW, water and trees are properly rendering. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36745] wine 1.3.19 and 3Dmark2001SE Dragothic demo upset kernel 2.6.38.4
https://bugs.freedesktop.org/show_bug.cgi?id=36745 Andrew Randrianasulu changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #20 from Andrew Randrianasulu 2011-06-14 23:31:33 PDT --- Fixed in mainline kernel (3.0.0-rc3+) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36745] wine 1.3.19 and 3Dmark2001SE Dragothic demo upset kernel 2.6.38.4
https://bugs.freedesktop.org/show_bug.cgi?id=36745 Andrew Randrianasulu rand...@mail.ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #20 from Andrew Randrianasulu rand...@mail.ru 2011-06-14 23:31:33 PDT --- Fixed in mainline kernel (3.0.0-rc3+) -- 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
Re: r600g TXD opcode (was: ... translation from TGSI failed / missing vertex shader)
On Wed, Jun 15, 2011 at 4:09 AM, Sven Arvidsson s...@whiz.se wrote: On Tue, 2011-06-14 at 19:09 +0200, David Lamparter wrote: On Sun, Jun 05, 2011 at 10:32:34PM -0700, bugzilla-dae...@freedesktop.org wrote: I'm attaching a patch that has an implementation. Unfortunately I can't seem to get it to work entirely correctly. The piglit test looks almost correct but has several artifacts in random places. If someone could point me in the right direction (as I'm completely clueless), I would be happy to finish it. In case it matters, piglit does not show any new failures from this patch. Did you make any progress? This also affects EVE Online btw. AFAIK, you need to use the web interface to comment on bugs. Otherwise Mike will miss this (unless he follows dri-devel): https://bugs.freedesktop.org/show_bug.cgi?id=37476 Should all be fixed now in master. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38280] [bisected] regression : etqw tree/water wrong rendering
https://bugs.freedesktop.org/show_bug.cgi?id=38280 --- Comment #5 from Pierre-Eric Pelloux-Prayer pell...@gmail.com 2011-06-15 00:27:58 PDT --- (In reply to comment #4) This patch should restore previous behaviour for r600r700 hw. Just tested it on ETQW, water and trees are properly rendering. -- 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 37442] Radeon 9600 Mobile (RV350) freezes on glxgears - bisected
https://bugzilla.kernel.org/show_bug.cgi?id=37442 --- Comment #4 from Wolfram Sang w.s...@pengutronix.de 2011-06-15 07:38:53 --- KMS works now, was a kernel misconfiguration (forgot to disable radeonfb, doh!). Interestingly, KMS does work with AGP4x while the Xorg driver can just handle AGP2x (also freezes the machine otherwise). Original bug still stands; checked the faulty commit but couldn't spot anything. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37442] Radeon 9600 Mobile (RV350) freezes on glxgears - bisected
https://bugzilla.kernel.org/show_bug.cgi?id=37442 --- Comment #5 from Michel Dänzer mic...@daenzer.net 2011-06-15 07:59:16 --- Dave, the implicated commit doesn't seem to hook up drm_pci_irq_by_busid anywhere. That's probably not intended? :) Not sure why the compiler doesn't complain about it... Not sure that can explain anything with KMS enabled though... Wolfram, does reverting just this commit fix things with KMS enabled as well? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38335] New: [r600g] Missing item/action icons in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=38335 Summary: [r600g] Missing item/action icons in World of Warcraft 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: ranki...@googlemail.com Created an attachment (id=47986) -- (https://bugs.freedesktop.org/attachment.cgi?id=47986) Screenshot, showing all of my blank items. In World of Warcraft, the icons that represent items, actions or spells disappear over time. As a rule, everything starts off fine. The rot starts as you actually play the game. This is the only major issue left playing WoW with my HD4890. -- 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 30122] r600 scrambled render when using 2d texture sample for 1d texture co-ord in fragment shader
https://bugs.freedesktop.org/show_bug.cgi?id=30122 --- Comment #4 from Pierre-Eric Pelloux-Prayer pell...@gmail.com 2011-06-15 02:04:40 PDT --- Created an attachment (id=47987) -- (https://bugs.freedesktop.org/attachment.cgi?id=47987) r600c incorrect rendering Tested with HD4850 + mesa from git : * r600g rendering is correct * r600c rendering is still wrong (see attached image) Could you confirm it is fixed for you as well with r600g ? If it's the case, maybe this bug should be assigned to r600c ? -- 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 36944] Family Farm: misrenders on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=36944 --- Comment #2 from Pierre-Eric Pelloux-Prayer pell...@gmail.com 2011-06-15 02:07:34 PDT --- Game renders correctly here using HD4850 (using mesa 27d3e0b25... or latest git). -- 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 38335] [r600g] Missing item/action icons in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=38335 --- Comment #1 from Chris Rankin ranki...@googlemail.com 2011-06-15 02:05:01 PDT --- I should also point out that this does not happen with either my RV350 or M66GL (r300g). -- 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 36523] water reflections misrendered in sauerbraten with shaders=high setting
https://bugs.freedesktop.org/show_bug.cgi?id=36523 --- Comment #5 from Stefano Teso stefano.t...@gmail.com 2011-06-15 02:16:10 PDT --- (In reply to comment #4) This seems to be fixed with current git master, can you confirm? Yes, confirming with latest git master. Feel free to close this bug. Thanks! -- 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 38280] [bisected] regression : etqw tree/water wrong rendering
https://bugs.freedesktop.org/show_bug.cgi?id=38280 --- Comment #6 from Andy Furniss li...@andyfurniss.entadsl.com 2011-06-15 02:21:07 PDT --- (In reply to comment #4) Created an attachment (id=47965) View: https://bugs.freedesktop.org/attachment.cgi?id=47965 Review: https://bugs.freedesktop.org/review?bug=38280attachment=47965 patch This patch should restore previous behaviour for r600r700 hw. Works for me with etqw and doom3-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 37442] Radeon 9600 Mobile (RV350) freezes on glxgears - bisected
https://bugzilla.kernel.org/show_bug.cgi?id=37442 --- Comment #6 from Wolfram Sang w.s...@pengutronix.de 2011-06-15 09:33:53 --- Created an attachment (id=62092) -- (https://bugzilla.kernel.org/attachment.cgi?id=62092) Proposed fix Thanks Michel, great pointer! The attached patch fixes the issue here; also sent it to the dri-devel list a minute ago. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: populate irq_by_busid-member for pci
Commit 8410ea (drm: rework PCI/platform driver interface) implemented
drm_pci_irq_by_busid() but forgot to make it available in the
drm_pci_bus-struct.
This caused a freeze on my Radeon9600-equipped laptop when executing glxgears.
Thanks to Michel for noticing the flaw.
Reported-by: Michel Dänzer daen...@vmware.com
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Dave Airlie airl...@redhat.com
---
stable-candidate, 2.6.39 is affected, too.
drivers/gpu/drm/drm_pci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index e1aee4f..e4e7fde 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -292,6 +292,7 @@ static struct drm_bus drm_pci_bus = {
.get_name = drm_pci_get_name,
.set_busid = drm_pci_set_busid,
.set_unique = drm_pci_set_unique,
+ .irq_by_busid = drm_pci_irq_by_busid,
.agp_init = drm_pci_agp_init,
};
--
1.7.2.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36523] water reflections misrendered in sauerbraten with shaders=high setting
https://bugs.freedesktop.org/show_bug.cgi?id=36523 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Sven Arvidsson s...@whiz.se 2011-06-15 05:17:29 PDT --- Great! Closing. -- 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 37261] Norsetto shadow mapping doesn't render correctly
https://bugs.freedesktop.org/show_bug.cgi?id=37261 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Sven Arvidsson s...@whiz.se 2011-06-15 05:18:19 PDT --- This is fixed with git master a128355. -- 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 38190] Amnesia / RenderFeatTest graphical glitches with refraction
https://bugs.freedesktop.org/show_bug.cgi?id=38190 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Sven Arvidsson s...@whiz.se 2011-06-15 05:28:09 PDT --- This is fixed with current git master a128355. -- 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 36944] Family Farm: misrenders on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=36944 --- Comment #3 from Sven Arvidsson s...@whiz.se 2011-06-15 05:32:47 PDT --- Still a problem for me with git-40aec11, I guess it could be something specific to Evergreen? -- 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 37225] Penumbra: Motion blur not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=37225 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Sven Arvidsson s...@whiz.se 2011-06-15 05:46:00 PDT --- Fixed with current git master 40aec11. -- 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 36920] Lightsmark: not rendering correctly
https://bugs.freedesktop.org/show_bug.cgi?id=36920 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Sven Arvidsson s...@whiz.se 2011-06-15 05:50:51 PDT --- Fixed with current git master 40aec11. -- 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 37502] New: Kernels oops display in X leaves screen garbled
https://bugzilla.kernel.org/show_bug.cgi?id=37502 Summary: Kernels oops display in X leaves screen garbled Product: Drivers Version: 2.5 Kernel Version: 3.0.0-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: edwinto...@gmail.com Regression: No Created an attachment (id=62102) -- (https://bugzilla.kernel.org/attachment.cgi?id=62102) dmesg I got some BUG_ONs/warnings from the kernel, and every time it happened I ended up with a garbled screen (see attached photo). Switching to a virtual console, and back to X (twice) restored my desktop. I don't know if the kernel is trying to switch to a text console to display the Oops, or if it tries to display the oops on the graphical console, but apparently its not working well. The first time I get an Oops after a reboot I get to see the Oops text on a black background (and my mouse cursor, which makes me believe this is the graphical KMS console), but everything after that just leaves me with a garbled screen. The oops displayed is: https://lkml.org/lkml/2011/6/15/50 I don't know if this is a regression or not, I rarely get Oopses, and last time I got a panic message I was able to see it (although I was in X at the time), but then so can I for the 1st Oops message. My graphics card is: 01:00.0 VGA compatible controller: ATI Technologies Inc RV730 PRO [Radeon HD 4650] I use KMS, Xorg 1.10.2, and Mesa 7.10.2-3. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36921] Sanctuary: Rendering errors with shader quality set to high
https://bugs.freedesktop.org/show_bug.cgi?id=36921 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Sven Arvidsson s...@whiz.se 2011-06-15 05:54:25 PDT --- Fixed with current git master 40aec11. -- 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 37502] Kernels oops display in X leaves screen garbled
https://bugzilla.kernel.org/show_bug.cgi?id=37502 --- Comment #1 from Török Edwin edwinto...@gmail.com 2011-06-15 12:54:47 --- Created an attachment (id=62112) -- (https://bugzilla.kernel.org/attachment.cgi?id=62112) Xorg.0.log.old -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37502] Kernels oops display in X leaves screen garbled
https://bugzilla.kernel.org/show_bug.cgi?id=37502 --- Comment #2 from Török Edwin edwinto...@gmail.com 2011-06-15 12:56:01 --- Created an attachment (id=62122) -- (https://bugzilla.kernel.org/attachment.cgi?id=62122) garbled screen photo -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM: clean up and document parsing of video= parameter
From a8163a0acef17c66521de37464732a2a4f9e50ca Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer eike-ker...@sf-tec.de
Date: Wed, 15 Jun 2011 11:27:02 +0200
Subject: [PATCH] DRM: clean up and document parsing of video= parameter
The video= parameter of the DRM drivers supports some additional flags that
the normal fb drivers do not have. They also allow to limit these flags to
specific outputs. Both things were previously undocumented.
Also the parsing of the line had some oddities:
-A lot of misplaced options were silently ignored or partly rejected instead
of stopping the parsing immediately
-The 'R' option is documented to follow the 'M' option if specified. It is not
documented that 'M' is needed to specify 'R' (also this is the case for normal
fb drivers). In fact the code is correct for normal fb drivers but wrong for
DRM ones.
The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only
if 'M' is given at all which is not needed for the DRM drivers.
-the margins option ('m') was parsed but later ignored even if the later
functions support it.
-specifying multiple enable options at the same time did not lead to an error.
-specifying something bogus for horizontal resolution (i.e. other things as
digits) did not lead to an error but an invalid resolution was used.
If any errors are encountered the position of the faulting string is now
printed to the user and the complete mode is ignored. This gives much
more consistent error behaviour.
I also removed some useless assignments and changed the local flag variables
to be bool.
Signed-off-by: Rolf Eike Beer eike-ker...@sf-tec.de
---
Documentation/fb/modedb.txt | 21 +-
drivers/gpu/drm/drm_modes.c | 87 +-
2 files changed, 78 insertions(+), 30 deletions(-)
diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt
index ec4dee7..16aa084 100644
--- a/Documentation/fb/modedb.txt
+++ b/Documentation/fb/modedb.txt
@@ -20,7 +20,7 @@ in a video= option, fbmem considers that to be a global video
mode option.
Valid mode specifiers (mode_option argument):
-xresxyres[M][R][-bpp][@refresh][i][m]
+xresxyres[M][R][-bpp][@refresh][i][m][eDd]
name[-bpp][@refresh]
with xres, yres, bpp and refresh decimal numbers and name a string.
@@ -36,6 +36,21 @@ pixels and 1.8% of yres).
Sample usage: 1024x768M@60m - CVT timing with margins
+DRM drivers also add options to enable or disable outputs:
+
+'e' will force the display to be enabled, i.e. it will override the detection
+if a display is connected. 'D' will force the display to be enabled and use
+digital output. This is useful for outputs that have both analog and digital
+signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd'
+is specified the output is disabled.
+
+You can additionally specify which output the options matches to.
+To force the VGA output to be enabled and drive a specific mode say:
+video=VGA-1:1280x1024@60me
+
+Specifying the option multiple times for different ports is possible, e.g.:
+video=LVDS-1:d video=HDMI-1:D
+
* oOo * oOo * oOo * oOo * oOo * oOo * oOo *
What is the VESA(TM) Coordinated Video Timings (CVT)?
@@ -132,5 +147,5 @@ There may be more modes.
tridentfb - Trident (Cyber)blade chipset frame buffer
vt8623fb - VIA 8623 frame buffer
-BTW, only a few drivers use this at the moment. Others are to follow
-(feel free to send patches).
+BTW, only a few fb drivers use this at the moment. Others are to follow
+(feel free to send patches). The DRM drivers also support this.
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c2d32f2..ad74fb4 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -994,9 +994,10 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
{
const char *name;
unsigned int namelen;
- int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
+ bool res_specified = false, bpp_specified = false, refresh_specified =
false;
unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0;
- int yres_specified = 0, cvt = 0, rb = 0, interlace = 0, margins = 0;
+ bool yres_specified = false, cvt = false, rb = false;
+ bool interlace = false, margins = false, was_digit = false;
int i;
enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;
@@ -1015,54 +1016,65 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
for (i = namelen-1; i = 0; i--) {
switch (name[i]) {
case '@':
- namelen = i;
if (!refresh_specified !bpp_specified
- !yres_specified) {
+ !yres_specified !cvt !rb was_digit) {
refresh = simple_strtol(name[i+1], NULL, 10);
-
Re: CPU and GPU cache-coherence
On Mit, 2011-06-15 at 16:58 +0200, Michel Dänzer wrote: On Die, 2011-06-07 at 21:42 +0800, Donnie Fang wrote: 3D render image on WC AGP aperture BO and then CPU fetch the image from this bo, in order to achieve performance, after 3D finished rendering, validate this bo into cached system memory and then read it from system memory. But I always get garbage from there. After check TTM bo validate codes, it has dealt with cache coherence properly, i wonder whether there is something I misunderstand or it is not allowed to move the WC bo from AGP to system memory for reading? Can you post patches showing what you've tried? Moving to the new dri-devel list at freedesktop.org, please only follow up there. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30122] r600 scrambled render when using 2d texture sample for 1d texture co-ord in fragment shader
https://bugs.freedesktop.org/show_bug.cgi?id=30122 Thomas Jones thomas.jo...@utoronto.ca changed: What|Removed |Added Component|Drivers/Gallium/r600|Drivers/DRI/R600 --- Comment #5 from Thomas Jones thomas.jo...@utoronto.ca 2011-06-15 08:36:29 PDT --- (In reply to comment #4) Created an attachment (id=47987) -- (https://bugs.freedesktop.org/attachment.cgi?id=47987) r600c incorrect rendering Tested with HD4850 + mesa from git : * r600g rendering is correct * r600c rendering is still wrong (see attached image) Could you confirm it is fixed for you as well with r600g ? If it's the case, maybe this bug should be assigned to r600c ? Indeed you are correct, it does seem to be fixed on r600c in git, any idea what commit did it? It would probably be useful to point it out so whoever tries to fix r600c can see it. -- 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
Re: [RFC] Updated DRM plane handling patches
On Tue, 7 Jun 2011 13:07:38 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
This patchset updates the previous one, incorporating the feedback I
received:
1) uses the v4l fourcc codes to communicate pixel format
2) adds a new addfb ioctl that takes a format
3) adds working SNB support for the new code
Comments welcome. I'll be pushing intel-gpu-tools testdisplay support
for this shortly if people want to play around with it. Next step is to
incorporate it into X and Wayland to see if the API is rich enough for
our needs.
And here's a very early hackish DDX patch for this code in case other
people want to test things out. I still have to update it with the
scaling stuff we talked about and support various things (disabling
planes, controlling attributes, etc) but it's enough to get bits on the
screen at least.
Jesse
diff --git a/src/Makefile.am b/src/Makefile.am
index a7f219c..2aec5a8 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -69,6 +69,7 @@ intel_drv_la_SOURCES = \
i965_reg.h \
i965_video.c \
i965_render.c \
+intel_sprite.c \
$(NULL)
if DRI
diff --git a/src/intel.h b/src/intel.h
index 2b114c3..11d911a 100644
--- a/src/intel.h
+++ b/src/intel.h
@@ -334,6 +334,7 @@ typedef struct intel_screen_private {
int colorKey;
XF86VideoAdaptorPtr adaptor;
+ XF86VideoAdaptorPtr sprite_adaptor;
ScreenBlockHandlerProcPtr BlockHandler;
Bool overlayOn;
@@ -461,6 +462,7 @@ extern void intel_mode_fini(intel_screen_private *intel);
extern int intel_get_pipe_from_crtc_id(drm_intel_bufmgr *bufmgr, xf86CrtcPtr
crtc);
extern int intel_crtc_id(xf86CrtcPtr crtc);
+extern int intel_crtc_to_sprite(xf86CrtcPtr crtc);
extern int intel_output_dpms_status(xf86OutputPtr output);
enum DRI2FrameEventType {
@@ -518,6 +520,7 @@ extern void I915EmitInvarientState(ScrnInfoPtr scrn);
extern void I830EmitFlush(ScrnInfoPtr scrn);
extern void I830InitVideo(ScreenPtr pScreen);
+extern XF86VideoAdaptorPtr intel_setup_sprite(ScreenPtr screen);
extern xf86CrtcPtr intel_covering_crtc(ScrnInfoPtr scrn, BoxPtr box,
xf86CrtcPtr desired, BoxPtr crtc_box_ret);
diff --git a/src/intel_display.c b/src/intel_display.c
index b55b110..4b032af 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -75,6 +75,7 @@ struct intel_crtc {
dri_bo *rotate_bo;
uint32_t rotate_pitch;
uint32_t rotate_fb_id;
+ uint32_t sprite_id;
xf86CrtcPtr crtc;
struct list link;
};
@@ -1564,9 +1565,50 @@ drm_wakeup_handler(pointer data, int err, pointer p)
drmHandleEvent(mode-fd, mode-event_context);
}
+static void intel_crtc_find_plane(ScrnInfoPtr scrn, xf86CrtcPtr crtc)
+{
+ intel_screen_private *intel = intel_get_screen_private(scrn);
+ struct intel_crtc *intel_crtc = crtc-driver_private;
+ drmModePlaneRes *plane_resources;
+ drmModePlane *ovr;
+ uint32_t id = 0;
+ int i;
+
+ plane_resources = drmModeGetPlaneResources(intel-drmSubFD);
+ if (!plane_resources) {
+ xf86DrvMsg(scrn-scrnIndex, X_ERROR,
+ failed to get plane resources: %s\n,
+ strerror(errno));
+ goto out;
+ }
+
+ for (i = 0; i plane_resources-count_planes; i++) {
+ ovr = drmModeGetPlane(intel-drmSubFD,
+ plane_resources-planes[i]);
+ if (!ovr) {
+ xf86DrvMsg(scrn-scrnIndex, X_ERROR,
+ failed to get plane info: %s\n,
+ strerror(errno));
+ continue;
+ }
+
+ if (ovr-possible_crtcs (1 intel_crtc_to_pipe(crtc))) {
+ id = ovr-plane_id;
+ drmModeFreePlane(ovr);
+ break;
+ }
+ drmModeFreePlane(ovr);
+ }
+
+ free(plane_resources);
+out:
+ intel_crtc-sprite_id = id;
+}
+
Bool intel_mode_pre_init(ScrnInfoPtr scrn, int fd, int cpp)
{
intel_screen_private *intel = intel_get_screen_private(scrn);
+ struct intel_crtc *intel_crtc;
struct drm_i915_getparam gp;
struct intel_mode *mode;
unsigned int i;
@@ -1597,6 +1639,9 @@ Bool intel_mode_pre_init(ScrnInfoPtr scrn, int fd, int
cpp)
for (i = 0; i mode-mode_res-count_crtcs; i++)
intel_crtc_init(scrn, mode, i);
+ list_for_each_entry(intel_crtc, mode-crtcs, link)
+ intel_crtc_find_plane(scrn, intel_crtc-crtc);
+
for (i = 0; i mode-mode_res-count_connectors; i++)
intel_output_init(scrn, mode, i);
@@ -1618,6 +1663,8 @@ Bool intel_mode_pre_init(ScrnInfoPtr scrn, int fd, int
cpp)
}
intel-modes = mode;
+
+
return TRUE;
}
@@ -1687,3 +1734,9 @@ int
[Bug 38353] New: r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 Summary: r600g : lock in desktop display durring piglit test Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: xodd...@gmail.com with the commit : r600g: Allow VRAM for the initial domain for every buffer binding. (b0f1767d776e2c80cab4343b4cd59553fbf5e48a) I have a lock in desktop display during : I can move the mouse, the cursor position is updated. But background display is not updated, and mouse don't interact with desktop. If I revert this change on git HEAD, I don't have the 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 38353] r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 --- Comment #1 from Alex Deucher ag...@yahoo.com 2011-06-15 12:04:03 PDT --- which piglit test(s) cause this? -- 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 38353] r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 --- Comment #3 from XoD xodd...@gmail.com 2011-06-15 12:11:49 PDT --- Created an attachment (id=48012) -- (https://bugs.freedesktop.org/attachment.cgi?id=48012) dmesg -- 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
Re: Oops in i915 intel_init_clock_gating
The problem of dev_priv-display.init_clock_gating not getting set is
still present in 3.0-rc3. On my system this happens because
intel_init_display() never gets called in the first place.
AFAICT, the normal calling sequence during driver initialization is:
i915_driver_load() - i915_load_modeset_init() -
intel_modeset_init() - intel_init_display().
But in my case the call to i915_load_modeset_init() doesn't occur
because drm_core_check_feature(dev, DRIVER_MODESET) is False.
I tested with the following patch:
Index: usb-3.0/drivers/gpu/drm/i915/intel_display.c
===
--- usb-3.0.orig/drivers/gpu/drm/i915/intel_display.c
+++ usb-3.0/drivers/gpu/drm/i915/intel_display.c
@@ -7511,6 +7511,10 @@ void intel_init_clock_gating(struct drm_
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ if (!dev_priv-display.init_clock_gating) {
+ printk(KERN_WARNING init_clock_gating not set!\n);
+ WARN_ON(1);
+ } else
dev_priv-display.init_clock_gating(dev);
if (dev_priv-display.init_pch_clock_gating)
Index: usb-3.0/drivers/gpu/drm/i915/i915_dma.c
===
--- usb-3.0.orig/drivers/gpu/drm/i915/i915_dma.c
+++ usb-3.0/drivers/gpu/drm/i915/i915_dma.c
@@ -2078,7 +2078,9 @@ int i915_driver_load(struct drm_device *
intel_detect_pch(dev);
+printk(KERN_INFO Testing drm_core_check_feature DRIVER_MODESET\n);
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+printk(KERN_INFO Calling i915_load_modeset_init\n);
ret = i915_load_modeset_init(dev);
if (ret 0) {
DRM_ERROR(failed to init modeset\n);
Here is the dmesg log showing what happens during insmod i915.ko:
[ 908.129497] pci :00:02.0: setting latency timer to 64
[ 908.179865] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 908.180633] [drm] No driver support for vblank timestamp query.
[ 908.180804] Testing drm_core_check_feature DRIVER_MODESET
[ 908.181120] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
The first debugging message is printed but not the second.
Here is what happens during a resume from system suspend:
[ 943.013656] init_clock_gating not set!
[ 943.013790] [ cut here ]
[ 943.013954] WARNING: at drivers/gpu/drm/i915/intel_display.c:7516
intel_init_clock_gating+0x30/0x4a [i915]()
[ 943.014193] Hardware name: HP dx2000 MT (EE004AA)
[ 943.014330] Modules linked in: i915 fbcon font bitblit softcursor
drm_kms_helper drm fb fbdev i2c_algo_bit cfbcopyarea i2c_core video backlight
cfbimgblt cfbfillrect e100 ohci_hcd mii pcspkr evdev uhci_hcd ehci_hcd fan
processor thermal_sys button usbcore [last unloaded: i915]
[ 943.015825] Pid: 1678, comm: bash Not tainted 3.0.0-rc3 #2
[ 943.015966] Call Trace:
[ 943.016179] [c1027315] warn_slowpath_common+0x65/0x7a
[ 943.016342] [f013e716] ? intel_init_clock_gating+0x30/0x4a [i915]
[ 943.016487] [c1027339] warn_slowpath_null+0xf/0x13
[ 943.016644] [f013e716] intel_init_clock_gating+0x30/0x4a [i915]
[ 943.016801] [f012f1f9] i915_restore_state+0xf4/0x1bf [i915]
[ 943.016989] [f0124100] i915_drm_thaw+0x41/0xc1 [i915]
[ 943.017141] [f01242c0] i915_resume+0x38/0x4b [i915]
[ 943.017301] [f00b0472] drm_class_resume+0x39/0x3b [drm]
[ 943.017447] [c116b520] legacy_resume+0x1e/0x46
[ 943.017599] [f00b0439] ? drm_class_suspend+0x3d/0x3d [drm]
[ 943.017742] [c116b7de] device_resume+0x83/0xa0
[ 943.017881] [c116bdd8] dpm_resume+0xdc/0x156
[ 943.018020] [c116bf68] dpm_resume_end+0xb/0x15
[ 943.018162] [c1053994] suspend_devices_and_enter+0x165/0x192
[ 943.018330] [c1053a93] enter_state+0xd2/0x123
[ 943.018471] [c105329f] state_store+0x95/0xa1
[ 943.018610] [c105320a] ? pm_async_store+0x33/0x33
[ 943.018752] [c1103c15] kobj_attr_store+0x16/0x22
[ 943.018894] [c10c7e5b] sysfs_write_file+0xb3/0xec
[ 943.019034] [c10c7da8] ? sysfs_open_file+0x1c2/0x1c2
[ 943.019176] [c108d793] vfs_write+0x76/0xa2
[ 943.019315] [c108d8f6] sys_write+0x3b/0x5d
[ 943.019456] [c11fb610] sysenter_do_call+0x12/0x36
[ 943.019625] ---[ end trace dc74bd86a8bff7da ]---
What's the right way to fix this?
Alan Stern
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Oops in i915 intel_init_clock_gating
On Wed, 15 Jun 2011 16:08:51 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
The problem of dev_priv-display.init_clock_gating not getting set is
still present in 3.0-rc3. On my system this happens because
intel_init_display() never gets called in the first place.
AFAICT, the normal calling sequence during driver initialization is:
i915_driver_load() - i915_load_modeset_init() -
intel_modeset_init() - intel_init_display().
But in my case the call to i915_load_modeset_init() doesn't occur
because drm_core_check_feature(dev, DRIVER_MODESET) is False.
Ouch, a non-KMS config. Any reason you can't use KMS?
This patch should help at any rate.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0defd42..a1a28fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -429,6 +429,9 @@ static int i915_drm_thaw(struct drm_device *dev)
/* KMS EnterVT equivalent */
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
mutex_lock(dev-struct_mutex);
+
+ intel_init_clock_gating(dev);
+
dev_priv-mm.suspended = 0;
error = i915_gem_init_ringbuffer(dev);
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 60a94d2..b478d16 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -863,8 +863,6 @@ int i915_restore_state(struct drm_device *dev)
I915_WRITE(IMR, dev_priv-saveIMR);
}
- intel_init_clock_gating(dev);
-
if (IS_IRONLAKE_M(dev)) {
ironlake_enable_drps(dev);
intel_init_emon(dev);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Oops in i915 intel_init_clock_gating
On Wed, 15 Jun 2011, Jesse Barnes wrote: On Wed, 15 Jun 2011 16:08:51 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: The problem of dev_priv-display.init_clock_gating not getting set is still present in 3.0-rc3. On my system this happens because intel_init_display() never gets called in the first place. AFAICT, the normal calling sequence during driver initialization is: i915_driver_load() - i915_load_modeset_init() - intel_modeset_init() - intel_init_display(). But in my case the call to i915_load_modeset_init() doesn't occur because drm_core_check_feature(dev, DRIVER_MODESET) is False. Ouch, a non-KMS config. Any reason you can't use KMS? Normally I do use it. This was a special testing config I've been nursing along for years, since well before KMS existed. Either I never enabled KMS in the config, or else at some point it caused trouble so I removed it and never added it back. Can't remember which -- all the testing I do with this config is at a VT, never under X. This patch should help at any rate. I confirm that the patch fixes the problem. Thanks. On a different but related note, rmmod i915 incites a lockdep notification: [ 54.316439] INFO: trying to register non-static key. [ 54.316589] the code is fine but needs lockdep annotation. [ 54.316729] turning off the locking correctness validator. [ 54.316871] Pid: 1683, comm: rmmod Not tainted 3.0.0-rc3 #2 [ 54.317011] Call Trace: [ 54.317153] [c11f582a] ? printk+0xf/0x11 [ 54.317296] [c1049b3f] register_lock_class+0x58/0x2d7 [ 54.317438] [c102176e] ? get_parent_ip+0xb/0x31 [ 54.317579] [c105295a] ? is_module_text_address+0x37/0x45 [ 54.317722] [c1038917] ? __kernel_text_address+0x1c/0x3e [ 54.317864] [c1049e61] __lock_acquire+0xa3/0xc5a [ 54.318005] [c1003833] ? dump_trace+0x7f/0xa5 [ 54.318146] [c104aa09] ? __lock_acquire+0xc4b/0xc5a [ 54.318287] [c104adf7] lock_acquire+0x5e/0x75 [ 54.318427] [c10364f4] ? work_on_cpu+0x96/0x96 [ 54.318567] [c1036530] wait_on_work+0x3c/0x133 [ 54.318707] [c10364f4] ? work_on_cpu+0x96/0x96 [ 54.318848] [c102fe0d] ? lock_timer_base.clone.23+0x20/0x3e [ 54.318991] [c11f7892] ? _raw_spin_unlock_irqrestore+0x36/0x5b [ 54.319134] [c102176e] ? get_parent_ip+0xb/0x31 [ 54.319275] [c11f9f99] ? sub_preempt_count+0x7c/0x89 [ 54.319417] [c1036cb2] __cancel_work_timer+0xa0/0xde [ 54.319559] [c1036d07] cancel_work_sync+0xa/0xc [ 54.319714] [f0128105] i915_driver_unload+0x136/0x224 [i915] [ 54.319874] [f00af39d] drm_put_dev+0xa9/0x170 [drm] [ 54.320029] [f00b086d] drm_pci_exit+0x49/0x63 [drm] [ 54.320045] [f01508d0] i915_exit+0x12/0x742 [i915] [ 54.320045] [c1050da5] sys_delete_module+0x175/0x1c1 [ 54.320045] [c107efb2] ? remove_vma+0x52/0x58 [ 54.320045] [c11f7ce0] ? restore_all+0xf/0xf [ 54.320045] [c11fb610] sysenter_do_call+0x12/0x36 [ 54.336786] [drm] Module unloaded Is this a known problem? Alan Stern ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: add check for valid init_clock_gating-pointer
On Thu, 16 Jun 2011 00:24:39 +0200
Wolfram Sang w.s...@pengutronix.de wrote:
Commit 6067aa (drm/i915: split clock gating init into per-chipset
functions) unconditionally calls the newly created
init_clock_gating-pointer. There is one case, however, where it does
not get set:
if (HAS_PCH_SPLIT(dev)) {
...
} else
dev_priv-display.update_wm = NULL;
}
We'll only hit this path on non-existent hardware. Since a clock
gating routine is required I'd rather just see the panic and add a new
routine at that time (i.e. what we normally do during bringup).
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #15 from Vadim pt...@yandex.ru 2011-06-15 20:13:00 PDT --- Created an attachment (id=48019) View: https://bugs.freedesktop.org/attachment.cgi?id=48019 Review: https://bugs.freedesktop.org/review?bug=35434attachment=48019 patch Does this patch help? -- 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 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #17 from Vadim pt...@yandex.ru 2011-06-15 22:28:20 PDT --- (In reply to comment #16) 2) water in-game is no longer rendered correctly, now only black blobs appear where water should be. I hope the patch from bug 38280 will fix it. -- 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
