[PATCH] drm: Remove the EDID blob stored in the EDID property when it is disconnected
From: Zhao Yakui yakui.z...@intel.com
Now the EDID property will be updated when the corresponding EDID can be
obtained from the external display device. But after the external device
is plugged-out, the EDID property is not updated. In such case we still
get the corresponding EDID property although it is already detected as
disconnected.
https://bugs.freedesktop.org/show_bug.cgi?id=26743
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/drm_crtc_helper.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index f2aaf39..51103aa 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -104,6 +104,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
if (connector-status == connector_status_disconnected) {
DRM_DEBUG_KMS(%s is disconnected\n,
drm_get_connector_name(connector));
+ drm_mode_connector_update_edid_property(connector, NULL);
goto prune;
}
--
1.6.3.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12282] hi cpu usage with simple 3d apps
http://bugs.freedesktop.org/show_bug.cgi?id=12282 --- Comment #4 from Dymchenko Bogdan dmboh...@gmail.com 2010-03-04 01:43:12 PST --- Hi. I have notebook, and I see that FPS of 3d applications depend on speed of cpu. When i run glxgears i see 5673 frames in 5.0 seconds = 1134.531 FPS and glxgears use over 30% cpu (and X server 20% cpu). My Cpu Amd Turion TK-57 (1.9Ghz) When i set it to 900Mhz i see 4266 frames in 5.0 seconds = 853.125 FPS 4360 frames in 5.0 seconds = 871.738 FPS So speed of 3d rendering very depend on cpu speed -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12282] hi cpu usage with simple 3d apps
http://bugs.freedesktop.org/show_bug.cgi?id=12282 --- Comment #5 from Dymchenko Bogdan dmboh...@gmail.com 2010-03-04 01:44:46 PST --- sorry, i forgot to say that my videocard is Radeon Mobility X2300 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] 2.6.33: white screen flash with i915
the whitescreen you encounter is probably a bug. to get further with debugging this: try to restart with i915 and fbcon built into the kernel and modesetting switched on (in your .config or via kernel commandline: i915.modeset=1 ) as well as the kernel commandline drm.debug=12 (probably needs some debugging option for drm turned on in your .config ) then post your resulting dmesg here and/or on dri-devel@lists.sourceforge.net (which is the list mentioned in the kernel MAINTAINERS file for the drm drivers ) Thanks for this info. Okay, I cross-post now to dri-devel. For readers there: I have an embedded device with a fixed 800x600 LCD display. Kernel is vanilla 2.6.33 from kernel.org, for the exact hardware see lspci output below. My real problem is that with an older kernel / older X11 the xserver-xorg- video-i810 used to work. But with current kernel and current X11 the xserver- xorg-video-intel driver (from Debian unstable) doesn't work at all, it hard- locks my board - i have to reset. So I first thougth about getting a framebuffer from Linux kernel. If the kernel itself can turn the intel graphics to 800x600 frame-buffer mode, I think I have the first step done. Unfortunately, modprobing i915 only yields me a totally white screen, but the white screen disappears after a short period of time. Apparently the framebuffer is now turned on, e.g. cat /sbin/init /dev/fb0 brings garbage (as expected) to the window. Now my question is if / how I can disable this white-screen. - # modprobe drm debug=12 # modprobe i915 modeset=1 ... now I have a totally white screen ... for about one second ... # lsmod Module Size Used by i915 195424 1 drm_kms_helper 20496 1 i915 drm 105440 2 i915,drm_kms_helper i2c_algo_bit3668 1 i915 button 2852 1 i915 video 12332 1 i915 backlight 1972 1 video output 848 1 video # dmesg [drm] Initialized drm 1.1.0 20060810 input: Power Button as /class/input/input2 ACPI: Power Button [PWRB] input: Power Button as /class/input/input3 ACPI: Power Button [PWRF] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 i915 :00:02.0: setting latency timer to 64 [drm] set up 31M of stolen space [drm:parse_general_definitions], crt_ddc_bus_pin: 2 [drm:parse_lfp_panel_data], Found panel mode in BIOS VBT tables: [drm:drm_mode_debug_printmodeline], Modeline 0:800x600 0 4 800 840 968 1056 600 601 605 628 0x8 0x0 [drm:parse_sdvo_device_mapping], No SDVO device info is found in VBT [drm:intel_modeset_init], 2 display pipes available. [drm:ch7xxx_init], Detected CH7301 chipset, vendor/device ID 0x95/0x17 [drm] initialized overlay support [drm:drm_helper_probe_single_connector_modes], VGA-1 [drm:intel_update_watermarks], plane A (pipe 0) clock: 31500 [drm:i9xx_get_fifo_size], FIFO size - (0x00015455) A: 85 [drm:i9xx_get_fifo_size], FIFO size - (0x00015455) B: -45 [drm:intel_calculate_wm], FIFO entries required for mode: 19 [drm:intel_calculate_wm], FIFO watermark level: 64 [drm:intel_calculate_wm], FIFO entries required for mode: 0 [drm:intel_calculate_wm], FIFO watermark level: -47 [drm:i9xx_update_wm], FIFO watermarks - A: 63, B: 1 [drm:i9xx_update_wm], Setting FIFO watermarks - A: 63, B: 1, C: 2, SR 1 [drm:intel_crtc_mode_set], Mode for pipe A: [drm:drm_mode_debug_printmodeline], Modeline 0:640x480 0 31500 640 664 704 832 480 489 491 520 0x10 0xa [drm:intel_pipe_set_base], No FB bound [drm:intel_update_watermarks], plane A (pipe 0) clock: 31500 [drm:i9xx_get_fifo_size], FIFO size - (0x00015455) A: 85 [drm:i9xx_get_fifo_size], FIFO size - (0x00015455) B: -45 [drm:intel_calculate_wm], FIFO entries required for mode: 19 [drm:intel_calculate_wm], FIFO watermark level: 64
Re: [Intel-gfx] 2.6.33: white screen flash with i915
Now my question is if / how I can disable this white-screen. I also noticed that when the screen-saver from the Linux framebuffer text console activates itself, it also turns fully white (and not black, like the pure linux text console (the non-framebuffer one). Any ideas? -- http://www.holgerschurig.de -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM split no_wait argument in 2 (no_wait_reserve, no_wait_gpu)
On Thu, Feb 25, 2010 at 05:50:10PM +0100, Jerome Glisse wrote: This patch change the TTM API to allow driver to select btw choosing to wait or not either for bo reserve or GPU wait separately. This is needed for the unmappabled VRAM work. Comments ? Cheers, Jerome Thomas any chance you review both this change and the iomap callback change ? The merge window is closing soon. Cheers, Jerome -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26347] powermanagement on rs780 not working
http://bugs.freedesktop.org/show_bug.cgi?id=26347 --- Comment #15 from Tobias Jakobi liquid.a...@gmx.net 2010-03-04 05:24:20 PST --- @Rafał Miłecki: Currently (nearly) everything in PM looks wrong to me. First of all the user has no way to configure the power management. I can't force the card into low-power mode like I can on Windows. Nor can I force the card into high-power mode if I need the performance e.g. for games (even on Windows there are situation where I don't want dynamic clock changes because I want a steady framerate). There is currently no way to tell the driver: I'm in this situation and I need that much performance. And that's (at least from my understanding) the main reason for the different power states the card offers. This problem extends to mobile systems. On these the driver has currently no knowledge about the battery/AC-adapter situation. If we want the driver to react to ACPI events (like AC unplug/plug events) (and I really think we SHOULD react to that) we need to expose power state selection to userspace. Anyway, I don't think it's really important to understand Windows driver. We may eventually need smarter reclocking algorithm. I think it very much is, because the Windows driver actually does reclocking right (no artifacts, no sudden gamespeed slowdowns when reclocking occurs) and offers the user the ability to configure the reclocking behaviour. I agree that we may need a smarter algorithm for WHEN to do reclocking, but we should adapt to the Windows driver for WHICH clock/voltage/etc. to select. The current PM implementation on linux does too much automagic, which fails in most cases. It ignores the concept of power states in the sense that the term power state doesn't really matter to the driver - it switches between them anyway. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26887] New: fence errors with rs785 and kernel 2.6.33
http://bugs.freedesktop.org/show_bug.cgi?id=26887 Summary: fence errors with rs785 and kernel 2.6.33 Product: DRI Version: DRI CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: marvi...@gmx.de I'm getting fence errors on RS785 (radeon HD 4200) in dmesg and disabled dri with vanilla 2.6.33. Error below and full dmesg attached. [6.179288] [drm] Initialized drm 1.1.0 20060810 [6.647815] [drm] radeon defaulting to kernel modesetting. [6.656630] [drm] radeon kernel modesetting enabled. [6.665470] radeon :01:05.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [6.674214] radeon :01:05.0: setting latency timer to 64 [6.675384] [drm] radeon: Initializing kernel modesetting. [6.692803] [drm] register mmio base: 0xFE9F [6.701275] [drm] register mmio size: 65536 [6.709638] HDA Intel :00:14.2: PCI INT A - GSI 16 (level, low) - IRQ 16 [6.718524] ATOM BIOS: 113 [6.726772] [drm] Clocks initialized ! [6.736928] [drm] Detected VRAM RAM=128M, BAR=128M [6.737990] [drm] RAM width 32bits DDR [6.739095] [TTM] Zone kernel: Available graphics memory: 2029616 kiB. [6.740164] [drm] radeon: 128M of VRAM memory ready [6.743646] [drm] radeon: 512M of GTT memory ready. [6.744714] [drm] radeon: irq initialized. [6.745728] [drm] GART: num cpu pages 131072, num gpu pages 131072 [6.747053] [drm] Loading RS780 Microcode [6.748054] platform radeon_cp.0: firmware: requesting radeon/RS780_pfp.bin [6.767394] hda-codec: No codec parser is available [6.788131] alloc irq_desc for 20 on node 0 [6.788133] alloc kstat_irqs on node 0 [6.788139] EMU10K1_Audigy :03:05.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [6.880352] platform radeon_cp.0: firmware: requesting radeon/RS780_me.bin [6.964294] platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin [7.059944] [drm] ring test succeeded in 1 usecs [7.061030] [drm] radeon: ib pool ready. [9.582117] [drm:radeon_fence_wait] *ERROR* fence(88011e2403c0:0x0001) 510ms timeout going to reset GPU [9.583167] radeon :01:05.0: GPU softreset [9.584211] radeon :01:05.0: R_008010_GRBM_STATUS=0xA0003030 [9.585249] radeon :01:05.0: R_008014_GRBM_STATUS2=0x0003 [9.586278] radeon :01:05.0: R_000E50_SRBM_STATUS=0x20002040 [9.792461] radeon :01:05.0: Wait for MC idle timedout ! [9.793472] radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x7FEE [9.794533] radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x0001 [9.795584] radeon :01:05.0: R_000E60_SRBM_SOFT_RESET=0x0C02 [9.796726] radeon :01:05.0: R_008010_GRBM_STATUS=0x3030 [9.797704] radeon :01:05.0: R_008014_GRBM_STATUS2=0x0003 [9.798674] radeon :01:05.0: R_000E50_SRBM_STATUS=0x2040 [9.801112] [drm:radeon_fence_wait] *ERROR* fence(88011e2403c0:0x0001) 739ms timeout [9.802083] [drm:radeon_fence_wait] *ERROR* last signaled fence(0x0001) [ 10.008268] [drm:r600_ib_test] *ERROR* radeon: ib test failed (sracth(0x8504)=0xCAFEDEAD) [ 10.009301] radeon :01:05.0: IB test failed (-22). [ 10.010248] [drm] Enabling audio support [ 10.010428] [drm] Radeon Display Connectors [ 10.012283] [drm] Connector 0: [ 10.013201] [drm] VGA [ 10.014107] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [ 10.015027] [drm] Encoders: [ 10.015932] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 10.016849] [drm] Connector 1: [ 10.017756] [drm] DVI-D [ 10.018655] [drm] HPD1 [ 10.019549] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [ 10.020451] [drm] Encoders: [ 10.021340] [drm] DFP3: INTERNAL_KLDSCP_LVTMA [ 10.206070] [drm] fb mappable at 0xF0141000 [ 10.206943] [drm] vram apper at 0xF000 [ 10.207820] [drm] size 5242880 [ 10.208682] [drm] fb depth is 24 [ 10.209530] [drm]pitch is 5120 [ 10.210447] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [ 10.211318] Console: switching to colour dummy device 80x25 [ 10.211436] Console: switching to colour frame buffer device 160x64 [ 10.217744] fb0: radeondrmfb frame buffer device [ 10.217768] registered panic notifier [ 10.217789] [drm] Initialized radeon 2.0.0 20080528 for :01:05.0 on minor 0 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel
[Bug 26887] fence errors with rs785 and kernel 2.6.33
http://bugs.freedesktop.org/show_bug.cgi?id=26887 --- Comment #1 from Marc marvi...@gmx.de 2010-03-04 07:53:12 PST --- Created an attachment (id=33759) -- (http://bugs.freedesktop.org/attachment.cgi?id=33759) full dmesg output -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Remove the EDID blob stored in the EDID property when it is disconnected
On Thu, 4 Mar 2010 16:25:55 +0800
Zhenyu Wang zhen...@linux.intel.com wrote:
From: Zhao Yakui yakui.z...@intel.com
Now the EDID property will be updated when the corresponding EDID can be
obtained from the external display device. But after the external device
is plugged-out, the EDID property is not updated. In such case we still
get the corresponding EDID property although it is already detected as
disconnected.
https://bugs.freedesktop.org/show_bug.cgi?id=26743
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/drm_crtc_helper.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index f2aaf39..51103aa 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -104,6 +104,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
if (connector-status == connector_status_disconnected) {
DRM_DEBUG_KMS(%s is disconnected\n,
drm_get_connector_name(connector));
+ drm_mode_connector_update_edid_property(connector, NULL);
goto prune;
}
I think this should be safe, and does fix a real bug. If so, it should
also be cc: sta...@kernel.org.
Dave?
--
Jesse Barnes, Intel Open Source Technology Center
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26347] powermanagement on rs780 not working
http://bugs.freedesktop.org/show_bug.cgi?id=26347 --- Comment #16 from Marc marvi...@gmx.de 2010-03-04 09:58:33 PST --- output of lspci -vnn 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon HD 3200 Graphics [1002:9610] Subsystem: ASUSTeK Computer Inc. Device [1043:82f1] Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at d000 (32-bit, prefetchable) [size=256M] I/O ports at d000 [size=256] Memory at fbef (32-bit, non-prefetchable) [size=64K] Memory at fbd0 (32-bit, non-prefetchable) [size=1M] Capabilities: [50] Power Management version 3 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Kernel driver in use: radeon Kernel modules: radeon I also updated the kernel to 2.6.33 + drm-linus from yesterday: relevant parts: [1.474500] [drm] Initialized drm 1.1.0 20060810 [1.501991] [drm] radeon defaulting to kernel modesetting. [1.502076] [drm] radeon kernel modesetting enabled. [1.502212] radeon :01:05.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [1.502302] radeon :01:05.0: setting latency timer to 64 [1.504998] [drm] radeon: Initializing kernel modesetting. [1.505230] [drm] register mmio base: 0xFBEF [1.505313] [drm] register mmio size: 65536 [1.505984] ATOM BIOS: 113 [1.506091] [drm] Clocks initialized ! [1.506175] [drm] 2 Power State(s) [1.506257] [drm] State 0 Default (default) [1.506340] [drm]1 Clock Mode(s) [1.506422] [drm]0 engine: 30 [1.506504] [drm] State 1 Performance [1.506587] [drm]1 Clock Mode(s) [1.506663] [drm]0 engine: 50 [1.506749] [drm] radeon: dynamic power management enabled [1.506830] [drm] radeon: power management initialized [1.506930] radeon :01:05.0: VRAM: 256M 0xC000 - 0xCFFF (256M used) [1.507057] radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF [1.507343] [drm] Detected VRAM RAM=256M, BAR=256M [1.507429] [drm] RAM width 32bits DDR [1.507589] [TTM] Zone kernel: Available graphics memory: 893658 kiB. [1.507687] [drm] radeon: 256M of VRAM memory ready [1.507770] [drm] radeon: 512M of GTT memory ready. [1.507879] [drm] radeon: irq initialized. [1.507962] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.509428] [drm] Loading RS780 Microcode [1.509506] platform radeon_cp.0: firmware: requesting radeon/RS780_pfp.bin [1.511192] platform radeon_cp.0: firmware: requesting radeon/RS780_me.bin [1.513200] platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin [1.551581] [drm] ring test succeeded in 0 usecs [1.551961] [drm] radeon: ib pool ready. [1.552123] [drm] ib test succeeded in 0 usecs [1.552206] [drm] Enabling audio support [1.552382] [drm] Radeon Display Connectors [1.552529] [drm] Connector 0: [1.552613] [drm] VGA [1.552690] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [1.552811] [drm] Encoders: [1.552883] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [1.552965] [drm] Connector 1: [1.553045] [drm] DVI-D [1.553126] [drm] HPD3 [1.553209] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [1.553329] [drm] Encoders: [1.553401] [drm] DFP3: INTERNAL_KLDSCP_LVTMA [1.606052]
Re: [git pull] drm request 3
Hmm. What the hell am I supposed to do about (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 (EE) NOUVEAU(0): 879: now? What happened to the whole backwards compatibility thing? I wasn't even warned that this breaks existing user space. That makes it impossible to _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid model, lots of people are just using some random distribution (F12 in my case), and you just broke it. I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Francisco Jerez curroje...@riseup.net but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. We can't just go around breaking peoples setups. This driver is, like it or not, used by Fedora-12 (and probably other distros). It may say staging, but that doesn't change the fact that it's in production use by huge distributions. Flag days aren't acceptable. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Linus Torvalds wrote: I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. Quite frankly, the more I look at that commit, the worse it looks. That commit seems to _on_purpose_ try to avoid at all cost being compatible. It not only removes some old entry-points, it literally re-numbers all the ioctl numbers as it does so, apparently entirely in order to just make it difficult to have some libdrm that can handle both versions. This all means that I literally cannot test the current -git tree. I suspect I have to revert it. Or is there a version of X that can handle _both_ the 0.0.15 and the 0.0.16 interfaces? That's absolutely required - so that it's not a flag-day any more to upgrade the kernel, and so that people (including very much me) can test and bisect other things without having to worry about basic functionality coming and going as you bisect things, Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Jesse Barnes wrote: Whoa, so breaking ABI in staging drivers isn't ok? Lots of other staging drivers are shipped by distros with compatible userspaces, but I thought the whole point of staging was to fix up ABIs before they became mainstream and had backwards compat guarantees, meaning that breakage was to be expected? If the staging driver isn't in common use, who cares? But this is a major driver, used by a major subsystem in a major distribution. It's not like Fedora-12 is some odd case. And it's not like nVidia graphics is unusual. Face it, nouveau is staging only in name. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Jesse Barnes wrote: On Thu, 4 Mar 2010 10:36:55 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... And now I see Dave did mention this, so what gives. Guidance please. Yeah, it's in the first one. My bad. I didn't notice, because that one got cancelled for other reasons and never even tested. That doesn't change the simple basic issue: how are people with Fedora-12 going to test any kernel out now? And are there libdrm versions that can handle _both_ cases, so that people can bisect things? IOW, even if you have a new libdrm, will it then work with the _old_ kernel too? Backwards compatibility is really important. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Matthew Garrett wrote: When you asked that nouveau was merged, people explicitly told you that the reason it hadn't been was because the interface was unstable and userspace would break. You asked that it be merged anyway, and now you're unhappy because the interface has changed and userspace has broken? How hard is it to understand basic kernel development rules? Nouveau was in Fedora-12. In fact, it was in Fedora-11 too afaik. People can hide behind all the staging and I asked for it things they like, but that doesn't change simple basic facts: distros should make sure drivers get merged up-stream, and people end up depending on them. Btw, I'm hoping some of this pain goes away for me, because I expect to get rid of the shitty nVidia card reasonably soon. The fact that my main box had a power supply that literally _required_ a power-sucking-piece- of-sh*t-graphics card has been painful to me. But none of that changes my basic objections. I didn't ask for nouveau to be merged as staging - I asked it to be merged because a major distro uses it. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 10:51:20 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Jesse Barnes wrote: On Thu, 4 Mar 2010 10:36:55 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... And now I see Dave did mention this, so what gives. Guidance please. Yeah, it's in the first one. My bad. I didn't notice, because that one got cancelled for other reasons and never even tested. That doesn't change the simple basic issue: how are people with Fedora-12 going to test any kernel out now? And are there libdrm versions that can handle _both_ cases, so that people can bisect things? IOW, even if you have a new libdrm, will it then work with the _old_ kernel too? Backwards compatibility is really important. Sure it is. But OTOH this is very clearly a use at your own risk driver. Dave and the nouveau guys include the driver in Fedora to get much needed test coverage, and make sure the latest bits in rawhide work together. The use at your own risk part is that you get to keep both pieces if you try to mix and match kernels and userspace until the STAGING moniker is removed. If marking the driver as staging doesn't allow them to break ABI when they need to, then it seems like they'll have no choice but to either remove the driver from upstream and only submit it when the ABI is stable, or fork the driver and submit a new one only when the ABI is stable. Neither seem particularly attractive. Of course I'm implicitly trusting their motivation for breaking ABI in this case, but that was very much a part of the merge discussion so shouldn't come as a surprise to anyone. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Linus Torvalds wrote: But none of that changes my basic objections. I didn't ask for nouveau to be merged as staging - I asked it to be merged because a major distro uses it. Put another way: the issue of whether _I_ happen to see this personally or not is kind of irrelevant. We need testers for development kernels. And any time we make that hard, we lose. That's really fundamental. The reason distributions should push their drivers upstream, and have a upstream first model in the first place is not because of _my_ hardware. It's because of the fundamental fact that if people can't test upstream kernels (because they don't work like the distro kernel does), we end up in a situations where people can't sanely test current git. And that model simply doesn't work from a development standpoint. If you make it basically impossible for people to upgrade kernels, and if you take away their ability to bisect bugs, you're going to cause the quality of development to go down. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 10:18:03 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: Hmm. What the hell am I supposed to do about (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 (EE) NOUVEAU(0): 879: now? What happened to the whole backwards compatibility thing? I wasn't even warned that this breaks existing user space. That makes it impossible to _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid model, lots of people are just using some random distribution (F12 in my case), and you just broke it. I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Francisco Jerez curroje...@riseup.net but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. We can't just go around breaking peoples setups. This driver is, like it or not, used by Fedora-12 (and probably other distros). It may say staging, but that doesn't change the fact that it's in production use by huge distributions. Flag days aren't acceptable. Whoa, so breaking ABI in staging drivers isn't ok? Lots of other staging drivers are shipped by distros with compatible userspaces, but I thought the whole point of staging was to fix up ABIs before they became mainstream and had backwards compat guarantees, meaning that breakage was to be expected? Yes, it sucks, but what else should the nouveau developers have done? They didn't want to push nouveau into mainline because they weren't happy with the ABI yet, but it ended up getting pushed anyway as a staging driver at your request, and now they're stuck? Sorry this whole thing is a bit of a wtf... Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 10:36:55 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... And now I see Dave did mention this, so what gives. Guidance please. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Jesse Barnes wrote: If marking the driver as staging doesn't allow them to break ABI when they need to, then it seems like they'll have no choice but to either remove the driver from upstream and only submit it when the ABI is stable, or fork the driver and submit a new one only when the ABI is stable. Neither seem particularly attractive. The thing is, they clearly didn't even _try_ to make anything compatible. See how all the ioctl numbers were moved around. And if you can't make if backwards compatible, at least you should make it forwards-compatible. Is it even that? I don't know. I'm kind of afraid it isn't. The new libdrm required for it certainly hasn't been pushed to Fedora-12. Will it ever be? And if it is, can you still run an old kernel on it? All of these are always possible to do. We've been _very_ good at doing them in general. I'm complaining, because let's face it, what else can I do? And btw, I'd complain about breaking backwards compatibility even if it wasn't just my own machine. I can pretty much guarantee that I'm not going to be the only one hitting this issue. So practically speaking: what _do_ you suggest we do about all the regressions this will cause? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. What kind of excuse is that? It's we did bad things, but if we didn't do those bad things, we'd have done _other_ bad things? Two wrong choices don't make a right. Nobody has even answered me whether this is _forwards_compatible. It clearly isn't backwards-compatible. IOW, is there _any_ way to move back-and-forth over that commit, even if I can find a new libdrm? IOW, we know we have a problem here. But what's the solution? I know I can revert it (I tried, I'm running that kernel now, nouveau works). That's not a good solution, I know. But can you offer me a _better_ one? One that doesn't involve upgrade all the way to rawhide, and lose the ability to bisect anything, or run plain 2.6.33. So yes, I'm complaining. But I at least have mentioned one solution. You, in contast, are just making excuses with no solutions. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26347] powermanagement on rs780 not working
http://bugs.freedesktop.org/show_bug.cgi?id=26347 --- Comment #17 from Alex Deucher ag...@yahoo.com 2010-03-04 11:23:03 PST --- (In reply to comment #16) r...@ax2-5200p:/sys/kernel/debug/dri/0# cat radeon_pm_info state: PM_STATE_ACTIVE default engine clock: 50 kHz current engine clock: 494040 kHz default memory clock: 40 kHz PCIE lanes: 0 ^^^ this one shows wrong information It's correct. The RS780 is integrated into the northbridge and is not connected via PCIE so there are no lanes to change. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 10:43:30AM -0800, Linus Torvalds wrote: Or is there a version of X that can handle _both_ the 0.0.15 and the 0.0.16 interfaces? When you asked that nouveau was merged, people explicitly told you that the reason it hadn't been was because the interface was unstable and userspace would break. You asked that it be merged anyway, and now you're unhappy because the interface has changed and userspace has broken? -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 10:51:20AM -0800, Linus Torvalds wrote: That doesn't change the simple basic issue: how are people with Fedora-12 going to test any kernel out now? And are there libdrm versions that can handle _both_ cases, so that people can bisect things? IOW, even if you have a new libdrm, will it then work with the _old_ kernel too? F-12 continues to ship the -nv driver, which will work fine with any kernel version as long as nouveau is disabled. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 10:55:57AM -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: When you asked that nouveau was merged, people explicitly told you that the reason it hadn't been was because the interface was unstable and userspace would break. You asked that it be merged anyway, and now you're unhappy because the interface has changed and userspace has broken? How hard is it to understand basic kernel development rules? Nouveau was in Fedora-12. In fact, it was in Fedora-11 too afaik. People can hide behind all the staging and I asked for it things they like, but that doesn't change simple basic facts: distros should make sure drivers get merged up-stream, and people end up depending on them. It takes a long time to work out exactly what kind of userspace interface you need when the hardware you're dealing with is entirely undocumented. The reason it's been shipped in Fedora is that it needs to be in front of actual users in order to get any testing at all, and we have the manpower to ensure that the dependencies are consistent. But most nouveau development isn't handled inside Red Hat, and we're in no position to dictate terms to the volunteers who are spending their spare time trying to write a useful driver. Btw, I'm hoping some of this pain goes away for me, because I expect to get rid of the shitty nVidia card reasonably soon. The fact that my main box had a power supply that literally _required_ a power-sucking-piece- of-sh*t-graphics card has been painful to me. You'd have hit similar issues if you'd been using Radeon KMS over the past couple of releases... But none of that changes my basic objections. I didn't ask for nouveau to be merged as staging - I asked it to be merged because a major distro uses it. It was merged as staging because the interface is unstable, which is consistent with staging's Kconfig: Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future. If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFT][PATCH] drm/radeon/kms: check for being in VBLANK on VBLANK interrupt
El mié. 03 de mar. de 2010, a las 23:35:00 +0100, Rafał Miłecki escribió: W dniu 3 marca 2010 23:33 użytkownik Rafał Miłecki zaj...@gmail.com napisał: This is supposed to check if we receive correct interrupt and if out check for VBLANK is correct. If you get warnings with patch applied, it means we have problem in at least one of mentioned places. --- To provoke VBLANK interrupt appearing, please use dynpm and start/stop for example glxgears few times. Jaime can you check this? I know you experienced warnings when using check in PM code. Here are a few tests: [ 169.696784] [drm] Requested: e: 68000 m: 8 p: 16 [ 169.696802] [drm] Setting: e: 68000 m: 8 p: 16 [ 172.700046] [drm] Requested: e: 11000 m: 40500 p: 16 [ 172.700055] [drm] Setting: e: 11000 m: 40500 p: 16 [ 179.513370] [drm] Requested: e: 68000 m: 8 p: 16 [ 179.513388] [drm] Setting: e: 68000 m: 8 p: 16 [ 180.113380] [drm] Requested: e: 11000 m: 40500 p: 16 [ 180.113389] [drm] Setting: e: 11000 m: 40500 p: 16 [ 180.115295] [drm] not in vbl for pm change 00020002 at entry [ 184.513350] [drm] Requested: e: 68000 m: 8 p: 16 [ 184.513359] [drm] Setting: e: 68000 m: 8 p: 16 [ 186.023395] [drm] Requested: e: 11000 m: 40500 p: 16 [ 186.023403] [drm] Setting: e: 11000 m: 40500 p: 16 [ 192.040034] [drm] Requested: e: 68000 m: 8 p: 16 [ 192.040054] [drm] Setting: e: 68000 m: 8 p: 16 [ 193.946734] [drm] Requested: e: 11000 m: 40500 p: 16 [ 193.946743] [drm] Setting: e: 11000 m: 40500 p: 16 [ 230.163392] [drm] Requested: e: 68000 m: 8 p: 16 [ 230.163411] [drm] Setting: e: 68000 m: 8 p: 16 [ 231.473389] [drm] Requested: e: 11000 m: 40500 p: 16 [ 231.473398] [drm] Setting: e: 11000 m: 40500 p: 16 [ 327.796715] [drm] Requested: e: 68000 m: 8 p: 16 [ 327.796734] [drm] Setting: e: 68000 m: 8 p: 16 [ 328.496738] [drm] Requested: e: 11000 m: 40500 p: 16 [ 328.496746] [drm] Setting: e: 11000 m: 40500 p: 16 [ 328.497883] [drm] not in vbl for pm change 00020002 at entry Dave: I believe you reported warnings as well? --- Personally I got following results on my machine: [ 57.981202] [drm] Requested: e: 68000 m: 8 p: 16 [ 57.981212] [drm] Setting: e: 68000 m: 8 p: 16 [ 57.982827] [drm] not in vbl for pm change 00020002 at entry [ 61.784087] [drm] Requested: e: 11000 m: 40500 p: 16 [ 61.784095] [drm] Setting: e: 11000 m: 40500 p: 16 [ 61.799187] [drm] not in vbl for pm change 00020002 at entry [ 66.799047] [drm] Requested: e: 68000 m: 8 p: 16 [ 66.799056] [drm] Setting: e: 68000 m: 8 p: 16 [ 69.916111] [drm] Requested: e: 11000 m: 40500 p: 16 [ 69.916119] [drm] Setting: e: 11000 m: 40500 p: 16 [ 69.931836] [drm] not in vbl for pm change 00020002 at entry [ 73.032037] [drm] Requested: e: 68000 m: 8 p: 16 [ 73.032046] [drm] Setting: e: 68000 m: 8 p: 16 [ 76.048056] [drm] Requested: e: 11000 m: 40500 p: 16 [ 76.048064] [drm] Setting: e: 11000 m: 40500 p: 16 [ 78.964090] [drm] Requested: e: 68000 m: 8 p: 16 [ 78.964099] [drm] Setting: e: 68000 m: 8 p: 16 [ 84.864053] [drm] Requested: e: 11000 m: 40500 p: 16 [ 84.864069] [drm] Setting: e: 11000 m: 40500 p: 16 [ 84.864102] [drm] not in vbl for pm change 00010002 at entry [ 93.165037] [drm] Requested: e: 68000 m: 8 p: 16 [ 93.165046] [drm] Setting: e: 68000 m: 8 p: 16 [ 98.080093] [drm] Requested: e: 11000 m: 40500 p: 16 [ 98.080102] [drm] Setting: e: 11000 m: 40500 p: 16 [ 101.396033] [drm] Requested: e: 68000 m: 8 p: 16 [ 101.396041] [drm] Setting: e: 68000 m: 8 p: 16 [ 105.012113] [drm] Requested: e: 11000 m: 40500 p: 16 [ 105.012121] [drm] Setting: e: 11000 m: 40500 p: 16 [ 107.613035] [drm] Requested: e: 68000 m: 8 p: 16 [ 107.613044] [drm] Setting: e: 68000 m: 8 p: 16 [ 111.728091] [drm] Requested: e: 11000 m: 40500 p: 16 [ 111.728099] [drm] Setting: e: 11000 m: 40500 p: 16 [ 114.328054] [drm] Requested: e: 68000 m: 8 p: 16 [ 114.328063] [drm] Setting: e: 68000 m: 8 p: 16 [ 114.328102] [drm] not in vbl for pm change 00020002 at entry [ 119.328104] [drm] Requested: e: 11000 m: 40500 p: 16 [ 119.328117] [drm] Setting: e: 11000 m: 40500 p: 16 [ 119.344343] [drm] not in vbl for pm change 00020002 at entry So you can see I receive VBLANK when *not* being in VBLANK in about 50% cases. I don't experience corruptions however. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list
Re: [git pull] drm request 3
If marking the driver as staging doesn't allow them to break ABI when they need to, then it seems like they'll have no choice but to either remove the driver from upstream and only submit it when the ABI is stable, or fork the driver and submit a new one only when the ABI is stable. Neither seem particularly attractive. The thing is, they clearly didn't even _try_ to make anything compatible. See how all the ioctl numbers were moved around. And if you can't make if backwards compatible, at least you should make it forwards-compatible. Is it even that? I don't know. I'm kind of afraid it isn't. The new libdrm required for it certainly hasn't been pushed to Fedora-12. Will it ever be? And if it is, can you still run an old kernel on it? All of these are always possible to do. We've been _very_ good at doing them in general. I'm complaining, because let's face it, what else can I do? And btw, I'd complain about breaking backwards compatibility even if it wasn't just my own machine. I can pretty much guarantee that I'm not going to be the only one hitting this issue. So practically speaking: what _do_ you suggest we do about all the regressions this will cause? At the moment in Fedora we deal with this for our users, we have dependencies between userspace and kernel space and we upgrade the bits when they upgrade the kernels, its a pain in the ass, but its what we accepted we needed to do to get nouveau in front of people. We are currently maintain 3 nouveau APIs across F11, F12 and F13. The main reason the API was gutted was because it supported lots of things that weren't supportable going forward. User modesetting support was completely removed and this meant lots of the API was pointless. Now I can ask Ben if he'd like to try and supply a libdrm that could in theory deal with both as a favour, but I'm not expecting the nouveau project guys to care, we pretty much got ourselves into this corner, and we'll pretty much have to get ourselves out. The other option I can ask him to look at is a CONFIG_NOUVEAU_015 interface which justs ifdefs around this for now, and in another release or two we rip all that out. Of course I can't ask him either of these until normal people who live in Australia wake up in 2-3 hrs, as opposed to me who is sitting in the dark trying not to wake the baby. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 1:18 PM, Linus Torvalds torva...@linux-foundation.org wrote: but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. From Dave's initial pull request [git pull] drm merge from March 1, he does say *NOTE* in case you missed it: this will *break* your nvidia machine, its purely intentional. Rawhide should have the libdrm and driver updates necessary. Matt Turner -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26347] powermanagement on rs780 not working
http://bugs.freedesktop.org/show_bug.cgi?id=26347 --- Comment #18 from Marc marvi...@gmx.de 2010-03-04 11:36:52 PST --- ah - sorry. I didn't meant the #lanes but the engine clock. dmesg reports 300 and 500 MHz available with 300 MHz default. radeon_pm_info says 500 is default and I'm using it! this sounds contradictory. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Matthew Garrett wrote: You're asking volunteers who didn't ask for their driver to be merged to perform more work in order to support users they didn't ask for. And _you_ are making excuses for BAD TECHNICAL DECISIONS! Come on! How hard is it to admit that that the change was done badly? How hard is it to admit that this isn't a political issue, it's about pure technology. There are good ways of doing things, and there are way sof doing things badly. I'm pointing to real _technical_ problems with how this was done. I'm talking about how this hurts testing, and how we've been able to handle things in other cases (with versioning, and forwards- or backwards- compatibility) without this kind of crap. If you can't handle backwards compatibility - fine. But I get the very strong feeling that people didn't even _think_ about trying to be at least forwards-compatible, and I'm getting the _very_ strong feeling that you are making excuses for bad technology. Is there some model of versioning inside X _except_ for the it won't work kind of thing? Can we fix this going forward, so that you can have _real_ versioning (ie multiple installed versions of a libdrm, the way you can have concurrently multiple installed versions of glibc?) IOW, we have a real technical problem here. Are you just going to continue to make excuses about it? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 11:08:07 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: The thing is, they clearly didn't even _try_ to make anything compatible. See how all the ioctl numbers were moved around. And if you can't make if backwards compatible, at least you should make it forwards-compatible. Is it even that? I don't know. I'm kind of afraid it isn't. The new libdrm required for it certainly hasn't been pushed to Fedora-12. Will it ever be? And if it is, can you still run an old kernel on it? Sure, but both kinds of compat come at a cost, a potentially large one in this case, so why take it on before absolutely necessary? I know you can see both sides of this... And btw, I'd complain about breaking backwards compatibility even if it wasn't just my own machine. I can pretty much guarantee that I'm not going to be the only one hitting this issue. Right, but OTOH it's a development driver. If you're running Fedora, things will work as long as you stick to the distro packages. And if you're building your own kernels, you ought to be taking care with staging drivers, right? So practically speaking: what _do_ you suggest we do about all the regressions this will cause? Before this thread I thought the policy was let people muddle through with staging drivers until their staging status is cleared. If that's not the case, then really what's the point of staging? I'm sure there are other examples of this type of breakage in staging drivers, though admittedly nouveau is probably the biggest in terms of user interest. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Dave Airlie wrote: At the moment in Fedora we deal with this for our users, we have dependencies between userspace and kernel space and we upgrade the bits when they upgrade the kernels, its a pain in the ass, but its what we accepted we needed to do to get nouveau in front of people. We are currently maintain 3 nouveau APIs across F11, F12 and F13. Can we try to make it less of a pain in the ass at some other level? For example, I realize that it's a real pain - both for the kernel _and_ for the user space library - to dynamically have to support multiple versions of some interface. And doing it _statically_ (with a compile option) isn't much better, because you end up not only with source code from hell, you still end up with the problem of having to compile the libraries and the kernel for the same interface, and not being able to mix. So let's say that we live with an API that changes, where none of the binaries (and no single version of the source code either) really support anything but _their_ version of the interface. Why does it then have to be such an effing pain for the _user_? (And by being such an effing pain for the user, it also becomes indirectly a pain for the distribution too - now you have all those nasty dependencies where you really cannot mix things up at all, and you can't upgrade one piece without upgrading the other). Now I can ask Ben if he'd like to try and supply a libdrm that could in theory deal with both as a favour, but I'm not expecting the nouveau project guys to care, we pretty much got ourselves into this corner, and we'll pretty much have to get ourselves out. Quite frankly, I really don't think that's a wonderful option either. Havign dynamic conditionals in code not only makes things worse to maintain, they slow things down too, and make code bigger. So what I'd look for is a sane technical solution to the technical problem of that ABI screwed up. And it's not like this is a new issue. We've had this several times before. It's called versioning, and the solution tends to pretty much _always_ boil down to two cases: - don't _ever_ change the ABI in backwards-incompatible ways, and have feature flags to say what level of support ther is. This is quite common, but it really does require that backwards compatibility. You can add features, but every time you add a feature, you still maintain the old ones _and_ new users need to check the feature flag first (and fall back on the old way of doing things if the new feature isn't there) Clearly this one doesn't seem to work for DRM. And quite frankly, I suspect it's at least partly because some DRM people aren't even _trying_ - possibly because they aren't even thinking about these kinds of issues. - Install multiple versions concurrently, and know they are incompatible, but pick the right one automatically. I really don't understand why this wouldn't solve all your distro problems, _and_ solve my kind of user problems too. It's simply not acceptable to just say ok, X doesn't work. Why aren't the libdrm libraries simply _versioned_? IOW, why can't we just have /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so living happily side-by-side? Why can't we just switch between Fedora 11, 12 and 13 kernels, and automatically get the right library? The glibc people do it based on hardware features. It's just a dlopen() away. This isn't rocket science. I shouldn't need to complain. I think it would make the life of even the _developers_ much easier. Who was the less-than-rocket-scientist that decided that the right thing to do was to check the kernel DRM version support, and exit with an error if it doesn't match? See what I'm saying? What I care about is that right now, it's impossible to switch kernels on a particular setup. That makes it effectively impossible to test new kernels sanely. And that really is a _technical_ problem. Btw, I'm sure there are other approaches too. But I really suspect that it should be pretty trivial to change nouveau (and I suspect this has nothing nouveau-specific in it - it migth even be the X server itself that does the DRM version test) to instead of dying, just doing a dlopen() of the right version. Wouldn't the radeon and intel driver people love to be able to do something like that -too-? Seriously. The current situation is not just crap, it's _stupid_ crap. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev --
[Bug 25093] mesa demo cubemap renders incorrectly with some filter combinations.
http://bugs.freedesktop.org/show_bug.cgi?id=25093 --- Comment #2 from Andy Furniss li...@andyfurniss.entadsl.com 2010-03-04 12:06:26 PST --- Created an attachment (id=33765) -- (http://bugs.freedesktop.org/attachment.cgi?id=33765) new cubemap corruption -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25093] mesa demo cubemap renders incorrectly with some filter combinations.
http://bugs.freedesktop.org/show_bug.cgi?id=25093 Andy Furniss li...@andyfurniss.entadsl.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #3 from Andy Furniss li...@andyfurniss.entadsl.com 2010-03-04 12:07:36 PST --- (In reply to comment #1) This is now working for me. Must have been a fluke - it seems like if other games/demos have been run first it has a chance of looking OK. If however it is the first thing I run then it's always corrupt, although I can't get it to look like the original screen shot I posted. Tried running several recent kernels,UMS,KMS,PCIE gart or AGP gart - all show the same corruption as attached. Once other apps have run the square is likely not to show, the black around the edges needs f pressing and only seems to show on filters involving nearest. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Matthew Garrett wrote: IOW, we have a real technical problem here. Are you just going to continue to make excuses about it? I'm not questioning the fact that it would be preferable to provide compatibility. But that compatibility doesn't come for free - someone has to implement it, and when your developer base is almost entirely made up of people who are doing this because they find it fun and interesting rather than because they're paid to, who's going to do it and what functionality is going to be delayed as a result? The thing is, I violently disagree with your basic premise. The way things are done now, that developer base actually just makes things _harder_ for themselves. They may not be aware that they do so, and they may _think_ that it's easier to just ignore versioning, but they are wrong. And I say that from personal experience. Doing incompatible changes in any code base makes everything harder. It results in users staying on old versions that you _know_ you don't want to support, but because of the incompatible change, they can't sanely upgrade. Seriously. So I bet we could do that wrapper nouveau.so that literally just does the get version, and dlopen the _real_ nouveau-version.so. Quite frankly, I don't know the XAA interfaces (or whatever they are in X these days), but somebody who does know them should be able to cook up such a wrapper in five minutes (and then spend a day testing it because of some silly bug, but whatever..) Do you seriously think that that wouldn't make life easier EVEN FOR THOSE DEVELOPERS that you claim to speak up for? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On 03/04/2010 02:04 PM, Matthew Garrett wrote: Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future. Shipping it as the default Fedora driver for NVIDIA hardware makes that text largely irrelevant. Jesse said Dave and the nouveau guys include the driver in Fedora to get much needed test coverage, and make sure the latest bits in rawhide work together. but when it is the default driver, it is the default _production_ driver for Fedora users, in an official, stable Fedora release. And the alternative? You said F-12 continues to ship the -nv driver, which will work fine with any kernel version as long as nouveau is disabled. FAIL. I actually tried that. Have you? Do you think it is remotely easy for a technically component, non-Xorg-hacker type to accomplish? I attempted to use the non-default 'nv' driver just before nouveau was merged into upstream/staging, because I wanted a development kernel that actually worked on my Fedora-based devel boxes. It was a complete exercise in frustration, requiring at least one bugzilla bug report, and ultimately resulted in failure. I gave up and waiting for Linus to merge nouveau, which instantly made my life a lot easier :) Kernel hacking on Fedora, my own dogfood, has become increasingly cumbersome because of all these graphics issues. Sometimes it's just easier to test a modern kernel on an ancient distro, sadly. Jeff -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 11:14:11AM -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. What kind of excuse is that? It's we did bad things, but if we didn't do those bad things, we'd have done _other_ bad things? Two wrong choices don't make a right. Nobody has even answered me whether this is _forwards_compatible. It clearly isn't backwards-compatible. IOW, is there _any_ way to move back-and-forth over that commit, even if I can find a new libdrm? Judging by http://cgit.freedesktop.org/mesa/drm/commit/?id=b496c63143e9a4ca02011582329bce2df99d9b7c , no. And if you're unhappy with that, don't use the driver. You enabled an option that's *documented* as potentially breaking between kernel releases, having been told that this was likely to happen, and now you're complaining? IOW, we know we have a problem here. But what's the solution? I know I can revert it (I tried, I'm running that kernel now, nouveau works). That's not a good solution, I know. But can you offer me a _better_ one? One that doesn't involve upgrade all the way to rawhide, and lose the ability to bisect anything, or run plain 2.6.33. Running -nv ought to be an option. So yes, I'm complaining. But I at least have mentioned one solution. You, in contast, are just making excuses with no solutions. You're asking volunteers who didn't ask for their driver to be merged to perform more work in order to support users they didn't ask for. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 11:41:22AM -0800, Linus Torvalds wrote: Is there some model of versioning inside X _except_ for the it won't work kind of thing? Can we fix this going forward, so that you can have _real_ versioning (ie multiple installed versions of a libdrm, the way you can have concurrently multiple installed versions of glibc?) There isn't. I don't think there's any intrinsic difficulty in doing so, other than the buildsystems and X's own unstable driver API. IOW, we have a real technical problem here. Are you just going to continue to make excuses about it? I'm not questioning the fact that it would be preferable to provide compatibility. But that compatibility doesn't come for free - someone has to implement it, and when your developer base is almost entirely made up of people who are doing this because they find it fun and interesting rather than because they're paid to, who's going to do it and what functionality is going to be delayed as a result? -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26891] New: Radeon KMS on Macs with EFI boot
http://bugs.freedesktop.org/show_bug.cgi?id=26891 Summary: Radeon KMS on Macs with EFI boot Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: stefandoesin...@gmx.at Created an attachment (id=33766) -- (http://bugs.freedesktop.org/attachment.cgi?id=33766) Bios from firmware loading hack Apple's iMacs and MacBooks don't have a video bios loaded when booting the Linux Kernel via an EFI bootloader rather than using Apple's bootcamp PC bios compatibility layer. This prevents the ATI Radeon kernel modesetting from working. Grub2 has a functionality to load a video bios image from a file stored on the efi boot partition. This makes the user mode setting in the X11 driver happy, but the kernel driver doesn't find the bios(invalid PCI Rom signature). Hacking the driver to try the load-from-vram method doesn't work either. I have created a hacky new bios loading method that loads a bios image via the kernel firmware loader from radeon/vbios.bin. I created this file from a bootcamp boot in the way documented in the Grub 2 wiki(http://grub.enbug.org/TestingOnMacbook). This way radeon KMS works, but like loading a bios image via the bootloader this is not a particularily pretty solution. I am using a native EFI bootloader instead of bootcamp because bootcamp is not capable of booting from a USB disk. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26891] Radeon KMS on Macs with EFI boot
http://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #1 from Stefan Dösinger stefandoesin...@gmx.at 2010-03-04 12:50:11 PST --- Oh, I forgot: The Intel DRM driver works just fine with KMS without a bios image(tested with a GMA 965 aka X3100). On the Nvidia side I have to use the EFI framebuffer, then start X with the proprietary driver, which obviously breaks my EFI framebuffer. I'm looking forward to noveau... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Move lists to freedesktop.org?
Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 12:07:19PM -0800, Linus Torvalds wrote: Do you seriously think that that wouldn't make life easier EVEN FOR THOSE DEVELOPERS that you claim to speak up for? Compared to dealing with Mesa's build system? I honestly wouldn't want to say. But you're right that pushing the job of supporting multiple interfaces out to userspace would be much more tractable here. -- Matthew Garrett | mj...@srcf.ucam.org -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 12:07, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: IOW, we have a real technical problem here. Are you just going to continue to make excuses about it? I'm not questioning the fact that it would be preferable to provide compatibility. But that compatibility doesn't come for free - someone has to implement it, and when your developer base is almost entirely made up of people who are doing this because they find it fun and interesting rather than because they're paid to, who's going to do it and what functionality is going to be delayed as a result? The thing is, I violently disagree with your basic premise. The way things are done now, that developer base actually just makes things _harder_ for themselves. They may not be aware that they do so, and they may _think_ that it's easier to just ignore versioning, but they are wrong. And I say that from personal experience. Doing incompatible changes in any code base makes everything harder. It results in users staying on old versions that you _know_ you don't want to support, but because of the incompatible change, they can't sanely upgrade. Seriously. So I bet we could do that wrapper nouveau.so that literally just does the get version, and dlopen the _real_ nouveau-version.so. Quite frankly, I don't know the XAA interfaces (or whatever they are in X these days), but somebody who does know them should be able to cook up such a wrapper in five minutes (and then spend a day testing it because of some silly bug, but whatever..) Do you seriously think that that wouldn't make life easier EVEN FOR THOSE DEVELOPERS that you claim to speak up for? No. It makes our lives much more complicated. I've worked on the radeon driver before and about half my time was spent just checking compatibility with multiple kernel/user space combinations. You have to handle all possible combinations of DRM+DDX+Mesa drivers, and that gets hairy real quick. Then for nouveau I decided not to bother until interfaces were stable enough, and I think all developers agree on that. I suggest you think about the do not break user space interfaces principle from a graphics developer point of view and what that means for the user space code. For example, you could take a look at the radeon DDX or Mesa drivers, which do implement compatibility. In the long run this leads to little gems like this: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r200/r200_state.c#n2148 Obviously even though there is some form of compatibility, not all user space/kernel combinations are tested. In short, the don't break user space interfaces principle is making user space code quality worse for everyone. And it makes our lives as graphics developers pretty miserable actually Stephane -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds torva...@linux-foundation.org wrote: Hmm. What the hell am I supposed to do about (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 (EE) NOUVEAU(0): 879: now? What happened to the whole backwards compatibility thing? I wasn't even warned that this breaks existing user space. That makes it impossible to _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid model, lots of people are just using some random distribution (F12 in my case), and you just broke it. I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Francisco Jerez curroje...@riseup.net but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. We can't just go around breaking peoples setups. This driver is, like it or not, used by Fedora-12 (and probably other distros). It may say staging, but that doesn't change the fact that it's in production use by huge distributions. Flag days aren't acceptable. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel What i'm about to say is my personal opinion, not that of nouveau as a whole (not even sure if such a thing exists). 1. We are in staging because our abi isn't final yet. 2. We (already) adjusted our way of working to ensure we have a usable and proper codebase by the time we are ready for mainline. 3. Redhat through Ben Skeggs contributes to nouveau (quite a bit i agree). 4. You are forcing red hat to force something on the rest of us. 5. I for one am happy we keep a clean api. 6. We keep an internal kernel tree that is tested to some degree (in this case the abi break was in there for a few weeks iirc) none of the developers asked for a revert. 7. Everyone (users, distros) are (or should) be aware of the nature of this driver, our userspace interface is experimental for that very reason. 8. Experience has tought me that in the case of nouveau, if a developer isn't using a codepath it will bitrot. So please, also take into consideration that this project isn't solely made by red hat and it's usually the other people that get to keep the pieces. Sincerely, Maarten Maathuis. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 10:21 PM, Maarten Maathuis madman2...@gmail.com wrote: On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds torva...@linux-foundation.org wrote: Hmm. What the hell am I supposed to do about (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 (EE) NOUVEAU(0): 879: now? What happened to the whole backwards compatibility thing? I wasn't even warned that this breaks existing user space. That makes it impossible to _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid model, lots of people are just using some random distribution (F12 in my case), and you just broke it. I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Francisco Jerez curroje...@riseup.net but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. We can't just go around breaking peoples setups. This driver is, like it or not, used by Fedora-12 (and probably other distros). It may say staging, but that doesn't change the fact that it's in production use by huge distributions. Flag days aren't acceptable. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel What i'm about to say is my personal opinion, not that of nouveau as a whole (not even sure if such a thing exists). 1. We are in staging because our abi isn't final yet. 2. We (already) adjusted our way of working to ensure we have a usable and proper codebase by the time we are ready for mainline. 3. Redhat through Ben Skeggs contributes to nouveau (quite a bit i agree). 4. You are forcing red hat to force something on the rest of us. 5. I for one am happy we keep a clean api. 6. We keep an internal kernel tree that is tested to some degree (in this case the abi break was in there for a few weeks iirc) none of the developers asked for a revert. Point 6 is iirc, someone can correct me if this is not the case. 7. Everyone (users, distros) are (or should) be aware of the nature of this driver, our userspace interface is experimental for that very reason. 8. Experience has tought me that in the case of nouveau, if a developer isn't using a codepath it will bitrot. So please, also take into consideration that this project isn't solely made by red hat and it's usually the other people that get to keep the pieces. Sincerely, Maarten Maathuis. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds torva...@linux-foundation.org wrote: Hmm. What the hell am I supposed to do about (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 (EE) NOUVEAU(0): 879: now? You can update your userspace components. No compatibility is offered between versions in any direction. What happened to the whole backwards compatibility thing? I wasn't even warned that this breaks existing user space. That makes it impossible to _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid model, lots of people are just using some random distribution (F12 in my case), and you just broke it. I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Francisco Jerez curroje...@riseup.net but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. We can't just go around breaking peoples setups. This driver is, like it or not, used by Fedora-12 (and probably other distros). It may say staging, but that doesn't change the fact that it's in production use by huge distributions. Flag days aren't acceptable. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Move lists to freedesktop.org?
On Thu, Mar 4, 2010 at 3:37 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. -- Jesse Barnes, Intel Open Source Technology Center As a user and occasional poster to these lists, that sounds very good to me. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev It'd be nice to get rid of these silly advertisements too. Matt -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26347] powermanagement on rs780 not working
http://bugs.freedesktop.org/show_bug.cgi?id=26347 --- Comment #19 from Rafał Miłecki zaj...@gmail.com 2010-03-04 13:51:04 PST --- (In reply to comment #15) @Rafał Miłecki: Currently (nearly) everything in PM looks wrong to me. Uhm. First of all the user has no way to configure the power management. I can't force the card into low-power mode like I can on Windows. Nor can I force the card into high-power mode if I need the performance e.g. for games (even on Windows there are situation where I don't want dynamic clock changes because I want a steady framerate). What you want is static PM, I never claimed we have that. I focus on dynpm. There is currently no way to tell the driver: I'm in this situation and I need that much performance. And that's (at least from my understanding) the main reason for the different power states the card offers. No. Power states in AtomBIOS are for both: dynamic and static PM. How do you imagine dynamic PM without knowing valid modes? This problem extends to mobile systems. On these the driver has currently no knowledge about the battery/AC-adapter situation. If we want the driver to react to ACPI events (like AC unplug/plug events) (and I really think we SHOULD react to that) we need to expose power state selection to userspace. We may use AC/battery state info in future, when doing much more advanced PM. For now there is not any usage of such info. Anyway, I don't think it's really important to understand Windows driver. We may eventually need smarter reclocking algorithm. I think it very much is, because the Windows driver actually does reclocking right (no artifacts, no sudden gamespeed slowdowns when reclocking occurs) and offers the user the ability to configure the reclocking behaviour. You won't get info about how to do reclocking to avoid artifacts/corruptions from watching Catalyst. Unless you're going to RE it. About providing UI for static PM I don't think there is much we can learn from Catalyst. We just need someone who will implement that. I agree that we may need a smarter algorithm for WHEN to do reclocking, but we should adapt to the Windows driver for WHICH clock/voltage/etc. to select. I believe we known most of flags of power states. If we meet some flags we don't know we may eventually try to find out when Catalyst uses mode with such flag. The current PM implementation on linux does too much automagic, which fails in most cases. It ignores the concept of power states in the sense that the term power state doesn't really matter to the driver - it switches between them anyway. Well, what really more would you like to use from power states? They just provide clocks and voltage with some flags (which we don't parse fully yet). Don't see much more magic about them we could use. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Can we try to make it less of a pain in the ass at some other level? For example, I realize that it's a real pain - both for the kernel _and_ for the user space library - to dynamically have to support multiple versions of some interface. And doing it _statically_ (with a compile option) isn't much better, because you end up not only with source code from hell, you still end up with the problem of having to compile the libraries and the kernel for the same interface, and not being able to mix. So let's say that we live with an API that changes, where none of the binaries (and no single version of the source code either) really support anything but _their_ version of the interface. Why does it then have to be such an effing pain for the _user_? (And by being such an effing pain for the user, it also becomes indirectly a pain for the distribution too - now you have all those nasty dependencies where you really cannot mix things up at all, and you can't upgrade one piece without upgrading the other). Now I can ask Ben if he'd like to try and supply a libdrm that could in theory deal with both as a favour, but I'm not expecting the nouveau project guys to care, we pretty much got ourselves into this corner, and we'll pretty much have to get ourselves out. Quite frankly, I really don't think that's a wonderful option either. Havign dynamic conditionals in code not only makes things worse to maintain, they slow things down too, and make code bigger. So what I'd look for is a sane technical solution to the technical problem of that ABI screwed up. And it's not like this is a new issue. We've had this several times before. It's called versioning, and the solution tends to pretty much _always_ boil down to two cases: - don't _ever_ change the ABI in backwards-incompatible ways, and have feature flags to say what level of support ther is. This is quite common, but it really does require that backwards compatibility. You can add features, but every time you add a feature, you still maintain the old ones _and_ new users need to check the feature flag first (and fall back on the old way of doing things if the new feature isn't there) Clearly this one doesn't seem to work for DRM. And quite frankly, I suspect it's at least partly because some DRM people aren't even _trying_ - possibly because they aren't even thinking about these kinds of issues. We've done this exactly like this since the drm went upstream, I think there has been one interface incompatible change in the kernel drm since it was upstream, in i810 back in the XFree86 days. KMS required new config options since moving the card init into the kernel, was going to break or be broken by a userspace driver reiniting that card, and we've retained compatiblity with older drivers fine. So you are tarring the whole drm with the interface to one driver which is clearly marked as having an unstable ABI. Nouveau is different, they have had no reason to version or make a stable interface until they could design an interface that would expose the features of the hw that they are trying to build a driver for. They've also used the timing to drop all support for legacy user modesetting drivers while they could, before it was deployed on a lot of people's machines in a lot of places. I really don't understand why this wouldn't solve all your distro problems, _and_ solve my kind of user problems too. It's simply not acceptable to just say ok, X doesn't work. Why aren't the libdrm libraries simply _versioned_? This would require redesigning the whole way distros build and distribute packages. Having to build 4-5 versions of nouveau for each version of Fedora would be a major increase in overheads for a minimal amount of return. IOW, why can't we just have /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so living happily side-by-side? Why can't we just switch between Fedora 11, 12 and 13 kernels, and automatically get the right library? The glibc people do it based on hardware features. It's just a dlopen() away. This isn't rocket science. I shouldn't need to complain. I think it would make the life of even the _developers_ much easier. Who was the less-than-rocket-scientist that decided that the right thing to do was to check the kernel DRM version support, and exit with an error if it doesn't match? See what I'm saying? What I care about is that right now, it's impossible to switch kernels on a particular setup. That makes it effectively impossible to test new kernels sanely. And that really is a _technical_ problem. Btw, I'm sure there are other approaches too. But I really suspect that it should be pretty trivial to change nouveau (and I suspect this has nothing nouveau-specific in it - it migth even be the X server itself that does the DRM version test) to instead of dying,
Re: Move lists to freedesktop.org?
Moving seems like a good idea. The delays here have been very troubling. -- Mike Stroyan - Software Architect LunarG, Inc. - The Graphics Experts Cell: (970) 219-7905 Email: m...@lunarg.com Website: http://www.lunarg.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Move lists to freedesktop.org?
On Thu, Mar 4, 2010 at 3:37 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Would anyone have objections if these lists moved to freedesktop.org? Yes please! The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26347] powermanagement on rs780 not working
http://bugs.freedesktop.org/show_bug.cgi?id=26347 --- Comment #20 from Rafał Miłecki zaj...@gmail.com 2010-03-04 14:19:43 PST --- Created an attachment (id=33771) -- (http://bugs.freedesktop.org/attachment.cgi?id=33771) drm/radeon/kms: add PM quirk for Asus Radeon HD 3200 Marc: can you try this, please? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. sf.net's mail interface is made of fail. Here's to changing to something credible. pgpV6TjtQUMox.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On 03/04/2010 05:18 PM, Adam Jackson wrote: On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote: On 03/04/2010 02:04 PM, Matthew Garrett wrote: F-12 continues to ship the -nv driver, which will work fine with any kernel version as long as nouveau is disabled. FAIL. I actually tried that. Have you? Do you think it is remotely easy for a technically component, non-Xorg-hacker type to accomplish? # cat EOF /etc/X11/xorg.conf Section Device Identifier Card0 Driver nv EndSection EOF Already tried that, and other suggested variations thereof. Did not work on F11 or F12 with 05:00.0 VGA compatible controller: nVidia Corporation GeForce 9800 GX2 (rev a2) # sed -i 's/\kernel\.*/ nouveau.modeset=0/g' /etc/grub.conf Never tried this part. Jeff -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Stephane Marchesin wrote: In short, the don't break user space interfaces principle is making user space code quality worse for everyone. And it makes our lives as graphics developers pretty miserable actually And _my_ point is that if you did a half-way decent job on versioning, you wouldn't be in the crappy situation you are now. For chissake, the DRM versioning model is a total disaster. The reason you can never ever break user space interfaces is exactly because when you break them, X stops working. What I suggested is to _keep_ a working model across different versions, so that you can get out of the rat-hole you are in now (and the rat-hole you put your users into, and the distributions). It's simply _not_ acceptable to tie the X server and the kernel version so tightly together as the crazy DRM model does right now. It's not all that different from us requiring people to install a new glibc every once in a while, just because we added a new filesystem. Everybody understands that that would be totally insane. Why does the X community not understand simple library versioning? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, Mar 4, 2010 at 2:42 PM, Eric Anholt e...@anholt.net wrote: On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. sf.net's mail interface is made of fail. Here's to changing to something credible. The funny thing about it is they're clearly using mailman, which has an archives interface, but they felt the need to implement some dog slow php forum-like interface over it. Why? -- Dan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote: On 03/04/2010 02:04 PM, Matthew Garrett wrote: F-12 continues to ship the -nv driver, which will work fine with any kernel version as long as nouveau is disabled. FAIL. I actually tried that. Have you? Do you think it is remotely easy for a technically component, non-Xorg-hacker type to accomplish? # cat EOF /etc/X11/xorg.conf Section Device Identifier Card0 Driver nv EndSection EOF # sed -i 's/\kernel\.*/ nouveau.modeset=0/g' /etc/grub.conf # telinit 6 HTH. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote: # sed -i 's/\kernel\.*/ nouveau.modeset=0/g' /etc/grub.conf Never tried this part. The bug I'm assuming you're referring to is https://bugzilla.redhat.com/show_bug.cgi?id=519298 in which you merely remove the nouveau userspace component, and in which I can't tell if you built nouveau into the kernel or not, but I assume you didn't based on your previous post. The X server does only try the one driver before falling back to vesa, which is a bug in the fallback logic I suppose. I've (blindly) fixed that for F13 now. However, the log in that bug only shows you using the built-in autoconfig logic, and not an xorg.conf file. So, given you were talking about a kernel without nouveau, I am left to assume one of: - you didn't try writing an xorg.conf fragment - you did, and it didn't work anyway The latter case is entirely plausible, as nv is not the sort of driver that gets a lot of love, but I'm not aware of any open bugs about gf9800 in particular in nv. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 8:54 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Stephane Marchesin wrote: In short, the don't break user space interfaces principle is making user space code quality worse for everyone. And it makes our lives as graphics developers pretty miserable actually And _my_ point is that if you did a half-way decent job on versioning, you wouldn't be in the crappy situation you are now. For chissake, the DRM versioning model is a total disaster. The reason you can never ever break user space interfaces is exactly because when you break them, X stops working. Stop aligning DRM versioning with nouveau versioning. This isn't a generic problem with DRM, we've supported versioning interfaces for years and have broken them maybe once. What I suggested is to _keep_ a working model across different versions, so that you can get out of the rat-hole you are in now (and the rat-hole you put your users into, and the distributions). It's simply _not_ acceptable to tie the X server and the kernel version so tightly together as the crazy DRM model does right now. It's not all that different from us requiring people to install a new glibc every once in a while, just because we added a new filesystem. Everybody understands that that would be totally insane. Why does the X community not understand simple library versioning? Its nouveau project not X not DRM, stop generalising the situation. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Adam Jackson wrote: On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. What kind of excuse is that? It's we did bad things, but if we didn't do those bad things, we'd have done _other_ bad things? Two wrong choices don't make a right. So unmerge it. That's what I told people I can do (I'd just revert that commit). I can do that. But it's not very productive, is it? What about the people who _do_ want to run the rawhide tree? Seriously - what's wrong with my suggestion to just version things properly? What's wrong with _fixing_ a stupid technical problem? What's wrong with people that you can't see that there are actual _solutions_ to the f*cking mess that is the current situation? I can solve it for my own use, and I already stated so. But while kernel developers should be scratching their own itches, a kernel developer that can't see past his own small sandbox is pretty damn worthless. We do need to fix this - and I'm bringing it up and complaining about it, because the nouveau people have _not_ done anything remotely sane. The current situation causes problems for people. Anybody who disputes that is in denial. Can somebody come up with a _better_ solution than the one I suggested? Feel free to do so, but in the meantime, I have to say that your reply and that of Matthew and others have been totally pointless, and making excuses rather than trying to actually face the fact that there is a problem. So man up, guys. Face the problem, rather than say well, it's staging, or well, we can revert it. Neither of those really solve anything in the short run _or_ the long run. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 14:54:03 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Stephane Marchesin wrote: In short, the don't break user space interfaces principle is making user space code quality worse for everyone. And it makes our lives as graphics developers pretty miserable actually And _my_ point is that if you did a half-way decent job on versioning, you wouldn't be in the crappy situation you are now. For chissake, the DRM versioning model is a total disaster. The reason you can never ever break user space interfaces is exactly because when you break them, X stops working. What I suggested is to _keep_ a working model across different versions, so that you can get out of the rat-hole you are in now (and the rat-hole you put your users into, and the distributions). It's simply _not_ acceptable to tie the X server and the kernel version so tightly together as the crazy DRM model does right now. It's not all that different from us requiring people to install a new glibc every once in a while, just because we added a new filesystem. Everybody understands that that would be totally insane. Why does the X community not understand simple library versioning? We use versioning on the Intel side, but in the form of feature flags as new things are added (we've had a handful since GEM was added in 2.6.28). It's a pain to handle the various code paths, but no more so than having lots of separate library versions to support. That would be nice from one perspective, but it would only save work if we abandoned the old versions quickly and kept a big shared component between library versions. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, 4 Mar 2010 14:55:29 -0800 Dan Nicholson dbn.li...@gmail.com wrote: On Thu, Mar 4, 2010 at 2:42 PM, Eric Anholt e...@anholt.net wrote: On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. sf.net's mail interface is made of fail. Here's to changing to something credible. The funny thing about it is they're clearly using mailman, which has an archives interface, but they felt the need to implement some dog slow php forum-like interface over it. Why? And their delivery is really slow too, which is quite annoying for active discussions. I guess Brian or Michel could get the current subscriber lists and transfer them over once we have the new lists. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. Ditto for dri-devel. BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? Not really, the lists should still have their own admins. I've been going through the moderation queues for both lists on a daily basis and am volunteering to continue doing so, but other than that I'm not really keen on being a list admin. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. What kind of excuse is that? It's we did bad things, but if we didn't do those bad things, we'd have done _other_ bad things? Two wrong choices don't make a right. So unmerge it. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Dave Airlie wrote: Its nouveau project not X not DRM, stop generalising the situation. Is it really just nouveau? I've not looked, but I bet the intel driver and the radeon driver have _exactly_ the same oh, I'm the wrong version, I will now kill myself behavior. I certainly seem to remember some similar issues with the intel driver long long ago. What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? Would it try to handle it gracefully? Or are we in the same situation that the intel driver guys can never fix anything fundamental without doing a whole flag day? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Fri, 05 Mar 2010 00:16:45 +0100 Michel Dänzer mic...@daenzer.net wrote: On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. Ditto for dri-devel. BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? Not really, the lists should still have their own admins. I've been going through the moderation queues for both lists on a daily basis and am volunteering to continue doing so, but other than that I'm not really keen on being a list admin. I don't have access to create the new lists, but Daniel or Tollef should. We may as well keep you guys as admins unless someone volunteers that you're ok with; but hopefully FDO will make the admin job a little easier/faster. Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 15:19 -0800, Linus Torvalds wrote: What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? Nothing. :) Only the major version is supposed to signify outright incompatibility, the minor version signifies backwards compatibility within the same major version, and the patchlevel has no impact on the interface. All the other drivers are basically following this, only nouveau is abusing the patchlevel as a major version for reasons beyond me. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Linus Torvalds wrote: Is it really just nouveau? I've not looked, but I bet the intel driver and the radeon driver have _exactly_ the same oh, I'm the wrong version, I will now kill myself behavior. Ok, I cloned the drm tree just to see, and it does seem like it's just nouveau that does that whole thing. At least from a quick grep of drmGetVersion() calls. I certainly seem to remember some similar issues with the intel driver long long ago. .. but Jesse tells me that it's using feature masks etc, so maybe my recollection is about unrelated issues. So yeah, nouveau seems to special. Although somebody already said that if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon driver just doesn't check the version number, and fails in different ways. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Its nouveau project not X not DRM, stop generalising the situation. Is it really just nouveau? I've not looked, but I bet the intel driver and the radeon driver have _exactly_ the same oh, I'm the wrong version, I will now kill myself behavior. I certainly seem to remember some similar issues with the intel driver long long ago. What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? Would it try to handle it gracefully? Or are we in the same situation that the intel driver guys can never fix anything fundamental without doing a whole flag day? Patchlevel never changed in intel, but if you changed the MINOR back to 1 then shit would break, exactly like any userspace shared library. It'll fall over in userspace, because userspace has minimum versioning requirements same as if you change all the udev interfaces back 6 years nothing boots anymore, or you remove the wireless interfaces or xattrs from ext3. I thin The standard DRM versioning interface is MAJOR - don't change this ever except for second coming. Radeon KMS is the only driver to have bumped this interface version, and we still support the 1.0.0 if you turn off modesetting. Mach64 bumped it once but we never upstreamed either version. MINOR - optionally bump this when you add a new API, new feature, new chipset, now we generally just add a new GETPARAM, which the userspace can check for and do the correct thing. PATCHLEVEL - ideally bump this for small non-user visible changes, in practice nobody touches this ever. Nouveau have abused this to provide pre 1.0.0 version number, when they release version 1.0.0 they are expected to follow standard drm versioning rules. Now just like in userspace, if you add features to the minor number, userspace driver will come to depend on these features being there. If you dropped the intel minor to 1.1 it would crap itself all over the place, same as if you starting trying to ship glibc2.0 on a glibc2.1 distro. We have never worried about new userspaces running on really old kernels, because generally 3-4 years has been good enough for distros. This is a nouveau problem not a drm problem. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 9:28 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Linus Torvalds wrote: Is it really just nouveau? I've not looked, but I bet the intel driver and the radeon driver have _exactly_ the same oh, I'm the wrong version, I will now kill myself behavior. Ok, I cloned the drm tree just to see, and it does seem like it's just nouveau that does that whole thing. At least from a quick grep of drmGetVersion() calls. I certainly seem to remember some similar issues with the intel driver long long ago. .. but Jesse tells me that it's using feature masks etc, so maybe my recollection is about unrelated issues. So yeah, nouveau seems to special. Although somebody already said that if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon driver just doesn't check the version number, and fails in different ways. As I mentioned earlier we had one issue with i810 about 7-8 years ago, before I was here, someone changed the i810_drm.h api incompatibly in XFree86. This was one of the things that led to having a proper policy. For radeon while we were developing the KMS feature in staging we changed the API once or twice, while we were developing KMS in Fedora we changed it at least 4 times, we shipped Intel KMS in F9 with a completly different API and just dealt with it, since upstreaming changed the API completely. The staging API changes were mostly to fix things that userspace did that made it possible to trample over other X users memory. This meant you had to bump the userspace that was doing the evil thing by mistake. Once we removed KMS from staging, we stabilised all APIs and behaviour (its not just the API, internal command stream checking for security issues). Since then we made one change to the CS behaviour in a backwards compatible manner so that old userspaces wouldn't die, but you couldn't abuse the hole they had relied on. I'm not saying it doesn't happen in other drivers from time to time, but when it does its treated as regression, for nouveau and STAGING that isn't what the Nouveau project (which Stephane mostly speaks for) seems to want at this stage. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 4, 2010 at 15:03, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Adam Jackson wrote: On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. What kind of excuse is that? It's we did bad things, but if we didn't do those bad things, we'd have done _other_ bad things? Two wrong choices don't make a right. So unmerge it. That's what I told people I can do (I'd just revert that commit). I can do that. But it's not very productive, is it? What about the people who _do_ want to run the rawhide tree? Seriously - what's wrong with my suggestion to just version things properly? What's wrong with _fixing_ a stupid technical problem? What's wrong with people that you can't see that there are actual _solutions_ to the f*cking mess that is the current situation? I can solve it for my own use, and I already stated so. But while kernel developers should be scratching their own itches, a kernel developer that can't see past his own small sandbox is pretty damn worthless. We do need to fix this - and I'm bringing it up and complaining about it, because the nouveau people have _not_ done anything remotely sane. Again, if we thought the DRM interfaces were good to begin with, we'd have submitted the driver for inclusion. But that's not the case so the we didn't submit the DRM. Whoever did gets to cope with the issues. Good luck, Stephane -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, Mar 4, 2010 at 15:09, Brian Paul bri...@vmware.com wrote: Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. Also I've been banned from posting to the lists at sf.net in the past because my smtp server was in their (wrong) RBLs. So I'm happy if the lists are moving away. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? No, you still have the mailman interface to handle all this. Stephane -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26872] Kernel 2.6.33 fails to suspend (bisected)
http://bugs.freedesktop.org/show_bug.cgi?id=26872 Nix n...@esperi.org.uk changed: What|Removed |Added Summary|Kernel 2.6.33 fails to |Kernel 2.6.33 fails to |suspend (semi-bisected) |suspend (bisected) --- Comment #2 from Nix n...@esperi.org.uk 2010-03-04 15:40:02 PST --- I re-bisected with more care and found it. Unfortunately it's a regression from a major API rework :/ The faulty commit pair is commit ca262a9998d46196750bb19a9dc4bd465b170ff7 Author: Jerome Glisse jgli...@redhat.com Date: Tue Dec 8 15:33:32 2009 +0100 drm/ttm: Rework validation memory space allocation (V3) commit 312ea8da049a1830aa50c6e2e50e30df476e Author: Jerome Glisse jgli...@redhat.com Date: Mon Dec 7 15:52:58 2009 +0100 drm/radeon/kms: Convert radeon to new TTM validation API (V2) Before these commits, suspension works. Afterwards, instead of suspension I see a quintuple(?) flash of the caps lock light and a hard reboot. I'm not certain what this means: a triple fault? The second change in behaviour, between abrupt reboot on suspend and hard hang, I haven't yet fully bisected (forty-three reboots in one evening was quite enough), but it lies in the range 2c761270d5520dd84ab0b4e47c24d99ff8503c38..004b35063296b6772fa72404a35b498f1e71e87e. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Dave Airlie wrote: I'm not saying it doesn't happen in other drivers from time to time, but when it does its treated as regression, for nouveau and STAGING that isn't what the Nouveau project (which Stephane mostly speaks for) seems to want at this stage. The problem with at this stage is that the stage has apparently been on-going for several years. Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are you guys simply planning on never supporting F12 with 2.6.34? I'd expect it to be a _major_ pain to have that whole hardcoded X and kernel must always change in lockstep. And the sad part is, it would be so nice if the X server would just dlopen the right thing automatically, so that the low-level driver wouldn't even need to care. It already does the whole discover which driver to load part, wouldn't it be nice if that code had automatic versioning too, and then a low-level driver really wouldn't have to care, everything would automatically do the right thing just when the version changes. Of course, the distro would still have to make all the different versions of libdrm available to users, but now updating one wouldn't screw over the others. So if you had a known-good setup with nouveau-0.0.15, you could install a nouveau-0.0.16 thing and _know_ that it won't affect that previous install at all. And yeah, I realize that those version numbers are wrong. Normal library versioning rules about patchlevel not changing semantics are obviously broken here. But maybe the rules could even try to first start with the exact version, ie do a driver-x.y.z.so load, then a driver-x.y.so load, then a driver-x.so load and finally a driver.so load. But I guess that nothing even does that drmGetVersion() until the nouveau driver has already been loaded. Which kind of forces the low-level drivers to do any such versioning on their own. But wouldn't it be nice if something like this was done at a higher level, so that the drivers really wouldn't even need to care? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Dave Airlie wrote: Speaking as distro maintainer here, No because we've got versioned interfaces and we are happy to support them yes it would be nice sometimes to dream about this, but its a major explosion in the testing matrix. You have to realise the more codepaths a distro ships, the more codepath it has to keep track off for security issues, for bug fixes, etc. I think you're missing the whole point here. There's no new and complex testing matrix. You only ever test the newest version, so there's no additional testing. Here's the inductive proof: - if the version number doesn't change, you aren't doing anything that is at all different from what you already do. - if the version number _does_ change, it does so only because you updated both the kernel component and the libdrm component together, and you test them together - exactly like you already do. So there is absolutely no difference for you. In either case, you only ever test paired up versions. If you make a new version, it will never _ever_ interact with old versions. There's no new complex testing needed. The only thing it allows is for you to have multiple kernels installed simultaneously - and be able to _use_ them all. Which is something you already do. And which the current model doesn't allow for. You may have three different kernels installed, but if libdrm got updated with a version change, only one of those kernels will actually _work_. When to we decide to stop shipping nouveau_drv-0.0.13? when do we find out it has a security issue? Irrelevant and total red herring. You never care about older versions, since if people have updated, they are running the newer version. So the older versions are there purely so that you _can_ have multiple different kernels, and so that your _developers_ can compile new kernels for older distributions. They aren't relevant for the case you point to: if somebody is just doing yum update, they'll get - and use - the newer version anyway. Here's the thing, distros are trying to ship an OS with a consistent set of packages, not a pick-n-mix. But here's the thing: if you expect people to do development, they _need_ to be able to mix things. A kernel developer needs to be able to update their kernel. And a kernel _tester_ needs to be able to test that kernel. Seriously: what do you expect me to do right now in my situation? I'm not going to release a kernel that I can't test. So if I can't get a libdrm that works in my F12 environment, I will _have_ to revert that patch that you asked me to merge. Really. Look at it from my standpoint. Look at it from _any_ kernel developer standpoint. It would be totally irresponsible of me to release 2.6.34 without even eating my own dog-food on my own main machine. Can't you see that this is obviously true? So right now, I'm running with that patch reverted on that machine. I haven't committed the revert, and quite frankly, I'd really prefer not to. But the only way that not revert case can really happen is if there is some other way for me to have a working machine again. Think about it. Tell me what the solution is. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Ben Skeggs wrote: The idea of staging was to allow for exactly the second problem, so why are you surprised? The fact Fedora ships nouveau is irrelevant, we also expect that for the most part people will be using our packages, which deal with the ABI issues. The fact that Fedora ships nouveau is _not_ irrelevant. That fact was what made it so important to get it merged. The distro rules wrt the kernel have been (for _years_ - before nouveau was ever even used by Fedora) that whole upstream first. I don't understand how you can even call it irrelevant. The very fact that Fedora started using Nouveau was - and is - the whole reason for this issue. I'm not going to release a kernel that I can't test. So if I can't get a libdrm that works in my F12 environment, I will _have_ to revert that patch that you asked me to merge. The F13 packages *will* work, so long as you're not bisecting back and forth. How do I install just the F13 libdrm thing, without changing everything else? I'm willing to try. We can make it part of the 2.6.34 release notes. And if we end up having people bisecting back and forth, I will hate that f*cking nouveau driver even more. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 16:08 -0800, Linus Torvalds wrote: On Fri, 5 Mar 2010, Dave Airlie wrote: Speaking as distro maintainer here, No because we've got versioned interfaces and we are happy to support them yes it would be nice sometimes to dream about this, but its a major explosion in the testing matrix. You have to realise the more codepaths a distro ships, the more codepath it has to keep track off for security issues, for bug fixes, etc. I think you're missing the whole point here. There's no new and complex testing matrix. You only ever test the newest version, so there's no additional testing. Here's the inductive proof: - if the version number doesn't change, you aren't doing anything that is at all different from what you already do. - if the version number _does_ change, it does so only because you updated both the kernel component and the libdrm component together, and you test them together - exactly like you already do. So there is absolutely no difference for you. In either case, you only ever test paired up versions. If you make a new version, it will never _ever_ interact with old versions. There's no new complex testing needed. The only thing it allows is for you to have multiple kernels installed simultaneously - and be able to _use_ them all. Which is something you already do. And which the current model doesn't allow for. You may have three different kernels installed, but if libdrm got updated with a version change, only one of those kernels will actually _work_. When to we decide to stop shipping nouveau_drv-0.0.13? when do we find out it has a security issue? Irrelevant and total red herring. You never care about older versions, since if people have updated, they are running the newer version. So the older versions are there purely so that you _can_ have multiple different kernels, and so that your _developers_ can compile new kernels for older distributions. They aren't relevant for the case you point to: if somebody is just doing yum update, they'll get - and use - the newer version anyway. Here's the thing, distros are trying to ship an OS with a consistent set of packages, not a pick-n-mix. But here's the thing: if you expect people to do development, they _need_ to be able to mix things. A kernel developer needs to be able to update their kernel. And a kernel _tester_ needs to be able to test that kernel. Here's the thing. *You* pushed for nouveau to go into staging before any of the developers were ready for it. Two of the big reasons (from my POV) for not requesting inclusion were the context programs (which have since been dealt with) and that yes, we have no intention of keeping crusty APIs around when they aren't what we require. The idea of staging was to allow for exactly the second problem, so why are you surprised? The fact Fedora ships nouveau is irrelevant, we also expect that for the most part people will be using our packages, which deal with the ABI issues. Seriously: what do you expect me to do right now in my situation? I'm not going to release a kernel that I can't test. So if I can't get a libdrm that works in my F12 environment, I will _have_ to revert that patch that you asked me to merge. The F13 packages *will* work, so long as you're not bisecting back and forth. Really. Look at it from my standpoint. Look at it from _any_ kernel developer standpoint. It would be totally irresponsible of me to release 2.6.34 without even eating my own dog-food on my own main machine. Can't you see that this is obviously true? With the release of 2.6.34 it'll require people to update userspace *once*, if they're rolling their own kernels and not using distro provided packages they should be able to handle that much. I agree it's a pain to bisect through, really. But it's far far from the common use case. Ben. So right now, I'm running with that patch reverted on that machine. I haven't committed the revert, and quite frankly, I'd really prefer not to. But the only way that not revert case can really happen is if there is some other way for me to have a working machine again. Think about it. Tell me what the solution is. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself.
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Luc Verhaegen wrote: libdrm is composed of the main libdrm, and several driver specific libdrms today (... and libkms, yes). It's actually not libdrm that is the primary issue, I'm sorry for saying that. It's the nouveau_drv.so thing - the actual X driver. Anyway, since I had looked at the libdrm sources, I had most of this on my machine anyway, so I've compiled it all, and am going to reboot and see if I can make a few symlinks work. IOW, right now I have this: [r...@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/ [r...@nehalem drivers]# ll nouveau_drv.so* lrwxrwxrwx 1 root root 21 2010-03-04 17:00 nouveau_drv.so - nouveau_drv.so-0.0.16 -rwxr-xr-x 1 root root 343784 2010-03-04 16:59 nouveau_drv.so-0.0.15 -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16 and I'll see if that works (yeah, yeah, I didn't strip the thing, and it's compiled with whatever defaults that probably include debugging too, so it's huge). Quite frankly, I still think that I shouldn't have to play these kinds of games. I think the versioning should be built in. And I still think that staging is not an excuse for it's bad crap, and we don't care Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 04:41:19PM -0800, Linus Torvalds wrote: The F13 packages *will* work, so long as you're not bisecting back and forth. How do I install just the F13 libdrm thing, without changing everything else? I'm willing to try. We can make it part of the 2.6.34 release notes. And if we end up having people bisecting back and forth, I will hate that f*cking nouveau driver even more. Linus libdrm is composed of the main libdrm, and several driver specific libdrms today (... and libkms, yes). While the main libdrm is relatively stable, the library specific ones move all the time, and there is only one version that is being tracked, and that is being bumped all the time. The most recent one: http://cgit.freedesktop.org/mesa/drm/commit/?id=b5495527 Only drivers depend on the driver specific libdrms. The xserver is compatible all the way to libdrm 2.3.0, which was tagged august 2006. xf86-video- drivers might depend on newer driver specific libdrms. And when the mesa tree is taken apart, when drivers are taken out of it, you'll find that its real dependency is also 2.3.0. It's the mesa drivers that are responsible for the main mesa dependency on libdrm 2.4.15. Luc Verhaegen. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 05:08:00PM -0800, Linus Torvalds wrote: On Fri, 5 Mar 2010, Luc Verhaegen wrote: libdrm is composed of the main libdrm, and several driver specific libdrms today (... and libkms, yes). It's actually not libdrm that is the primary issue, I'm sorry for saying that. It's the nouveau_drv.so thing - the actual X driver. Anyway, since I had looked at the libdrm sources, I had most of this on my machine anyway, so I've compiled it all, and am going to reboot and see if I can make a few symlinks work. IOW, right now I have this: [r...@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/ [r...@nehalem drivers]# ll nouveau_drv.so* lrwxrwxrwx 1 root root 21 2010-03-04 17:00 nouveau_drv.so - nouveau_drv.so-0.0.16 -rwxr-xr-x 1 root root 343784 2010-03-04 16:59 nouveau_drv.so-0.0.15 -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16 and I'll see if that works (yeah, yeah, I didn't strip the thing, and it's compiled with whatever defaults that probably include debugging too, so it's huge). Quite frankly, I still think that I shouldn't have to play these kinds of games. I think the versioning should be built in. And I still think that staging is not an excuse for it's bad crap, and we don't care Linus In an ideal world, you shouldn't be forced to update anything except some/all of the driver bits. But the fact that libdrm is lumped together as it is, and that mesa is a monolith, forces you to update a more significant portion of your system. You have to resort to some serious manual labour to get around that atm. Luc Verhaegen. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Linus Torvalds wrote: Anyway, since I had looked at the libdrm sources, I had most of this on my machine anyway, so I've compiled it all, and am going to reboot and see if I can make a few symlinks work. IOW, right now I have this: [r...@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/ [r...@nehalem drivers]# ll nouveau_drv.so* lrwxrwxrwx 1 root root 21 2010-03-04 17:00 nouveau_drv.so - nouveau_drv.so-0.0.16 -rwxr-xr-x 1 root root 343784 2010-03-04 16:59 nouveau_drv.so-0.0.15 -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16 Naah, I just end up with a really screwed up screen with that. I probably did something wrong in the configuration phase or something. I'll look for the precompiled ones, and hope they don't have some other odd dependencies. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Luc Verhaegen wrote: In an ideal world, you shouldn't be forced to update anything except some/all of the driver bits. But the fact that libdrm is lumped together as it is, and that mesa is a monolith, forces you to update a more significant portion of your system. You have to resort to some serious manual labour to get around that atm. Ok, that probably explains my messy screen and failure with the above simplistic approach - I didn't do the whole mesa thing, I just did the drivers. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Anyway, since I had looked at the libdrm sources, I had most of this on my machine anyway, so I've compiled it all, and am going to reboot and see if I can make a few symlinks work. IOW, right now I have this: [r...@nehalem ~]# cd /usr/lib64/xorg/modules/drivers/ [r...@nehalem drivers]# ll nouveau_drv.so* lrwxrwxrwx 1 root root 21 2010-03-04 17:00 nouveau_drv.so - nouveau_drv.so-0.0.16 -rwxr-xr-x 1 root root 343784 2010-03-04 16:59 nouveau_drv.so-0.0.15 -rwxr-xr-x 1 root root 1698805 2010-03-04 16:59 nouveau_drv.so-0.0.16 Naah, I just end up with a really screwed up screen with that. I probably did something wrong in the configuration phase or something. I'll look for the precompiled ones, and hope they don't have some other odd dependencies. Looks like libdrm_nouveau didn't get updated along with nouveau. We don't have mesa in F12 so that won't matter. wget http://kojipkgs.fedoraproject.org/packages/libdrm/2.4.18/1.fc13/src/libdrm-2.4.18-1.fc13.src.rpm rpmbuild --rebuild libdrm-2.4.18-1.fc13.src.rpm rpm -Uvh ~/rpmbuild/RPMS/libdrm-2.4.18-1.fc13.x86_64.rpm ~/rpmbuild/RPMS/libdrm-devel-2.4.18-1.fc13.x86_64.rpm wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm rebuild + install. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26496] OpenGL does not work on Radeon 9600 (r300)
http://bugs.freedesktop.org/show_bug.cgi?id=26496 --- Comment #7 from Joseph Jezak jos...@gentoo.org 2010-03-04 18:42:55 PST --- If this helps at all, I can reproduce the problem. glxgears seems to run properly. The games crack-attack and tomatoes work properly, but occasionally have some polygons that are rendered improperly as with the neverball screen shots already provided. I suspect that the complexity of the scene being rendered plays some part. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26570] [r6xx DRI] KMS enabled: GLSL white washing corruption (seen in Second Life)
http://bugs.freedesktop.org/show_bug.cgi?id=26570 Shawn Starr shawn.st...@rogers.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Shawn Starr shawn.st...@rogers.com 2010-03-04 19:48:04 PST --- This seems to be fixed, I am not seeing this corruption now so will close it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Dave Airlie wrote: wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm rebuild + install. This one doesn't work on F12. It wants xorg-x11-server-devel 1.7.99.3-3. Is there some limited set of rpm's I can get from the f13 archive? Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 3:17 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Fri, 5 Mar 2010, Dave Airlie wrote: wget http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm rebuild + install. This one doesn't work on F12. It wants xorg-x11-server-devel 1.7.99.3-3. Is there some limited set of rpm's I can get from the f13 archive? If by limited you mean the whole X server + udev updates that would work, if not then: http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm That src rpm should be rebuildable on F12, I just removed the requires on F13 stuff. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010, Dave Airlie wrote: if not then: http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm That src rpm should be rebuildable on F12, I just removed the requires on F13 stuff. Well, that wants the new kernel, but I can force it with --nodeps.. I'll reboot and test. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010, Linus Torvalds wrote: On Fri, 5 Mar 2010, Dave Airlie wrote: if not then: http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm That src rpm should be rebuildable on F12, I just removed the requires on F13 stuff. Well, that wants the new kernel, but I can force it with --nodeps.. I'll reboot and test. Bingo. Could this be done as a real F12 binary package (maybe call it force-nouveau-0.0.16 or something) for testers to use? I had most of the X devel tools set up anyway since I used to build intel drivers from git for one of my experimental machines. And I guess most kernel devs can generally easily do the rpm build, but I'd hate to lose any more plain testers than I absolutely have to. And it would make it way easier for people to try out their kernel, notice that X doesn't work, and then let them know that something like a simple yum install force-nouveau-0.0.16 makes it work. Compared to having them install X builds, do a rpm -Uvh --nodeps etc etc. Anyway, this at least makes me feel like I don't have to revert that commit just to be able to test current -git again. Thanks, Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
* Ben Skeggs skeg...@gmail.com wrote: But here's the thing: if you expect people to do development, they _need_ to be able to mix things. A kernel developer needs to be able to update their kernel. And a kernel _tester_ needs to be able to test that kernel. Here's the thing. *You* pushed for nouveau to go into staging before any of the developers were ready for it. Two of the big reasons (from my POV) for not requesting inclusion were the context programs (which have since been dealt with) and that yes, we have no intention of keeping crusty APIs around when they aren't what we require. The idea of staging was to allow for exactly the second problem, so why are you surprised? The fact Fedora ships nouveau is irrelevant, we also expect that for the most part people will be using our packages, which deal with the ABI issues. Here is my experience with the development of various ABIs - and i've been on both sides of the fence, i've done 'flag day' ABI changes during development myself, and i've done gradual ABI development as well. One experience i can tell you with 100% certainty: no matter whether a project is small or large, simple or complex, whether the old ABI is the ugliest wart on this planet or just hit by an unfortunate limitation that needs to be eliminated. The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: - wrong - harmful - limits the developer base - limits the tester base - wastes time and effort. (fewer developers/testers means that while _this_ feature was easier to add, all your _future_ features will be a bit harder to do. It compounds up.) - so it hurts even the very developer who is most convinced that this was the right thing to do It's a bad technical decision throughout. It's masochistic and often suicidal to just about any project in essence. I've seen projects that did it once and died just due to that single act of stupidity. I've seen projects that have done it a few times and took the usage hit, limped along with the wounds and never grew to the size they could have achieved. I've seen projects that did it once, took the hit, learned from it and never did it again. How many times does DRM want to take that bullet head on? I have _never_ seen a situation where in hindsight breaking the ABI of a widely deployed project could be considered 'good', for just about any sane definition of 'good'. It's really that simple IMO. There's very few unconditional rules in OSS, but this is one of them. Ingo -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote: The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: - wrong - harmful - limits the developer base - limits the tester base - wastes time and effort. (fewer developers/testers means that while _this_ feature was easier to add, all your _future_ features will be a bit harder to do. It compounds up.) - so it hurts even the very developer who is most convinced that this was the right thing to do It's a bad technical decision throughout. It's masochistic and often suicidal to just about any project in essence. I've seen projects that did it once and died just due to that single act of stupidity. I've seen projects that have done it a few times and took the usage hit, limped along with the wounds and never grew to the size they could have achieved. I've seen projects that did it once, took the hit, learned from it and never did it again. Agreed. What bothers me in this discussion is that people keep bringing up the fact that nouveau is mostly developed by volunteers and thus it doesn't make sense to make sure it's backwards (or forwards) compatible. But the way I see it, it's the complete opposite. It's _more_ important to support ABIs for community-driven efforts because you're relying on people who by definition don't have time to waste. While the nouveau people might have good intentions, I'm afraid they might be severely limiting their developer and tester base because they're not focused on real world problems (like the ones Linus is seeing). Pekka -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
Pekka Enberg wrote: On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote: The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: - wrong - harmful - limits the developer base - limits the tester base - wastes time and effort. (fewer developers/testers means that while _this_ feature was easier to add, all your _future_ features will be a bit harder to do. It compounds up.) - so it hurts even the very developer who is most convinced that this was the right thing to do It's a bad technical decision throughout. It's masochistic and often suicidal to just about any project in essence. I've seen projects that did it once and died just due to that single act of stupidity. I've seen projects that have done it a few times and took the usage hit, limped along with the wounds and never grew to the size they could have achieved. I've seen projects that did it once, took the hit, learned from it and never did it again. Agreed. What bothers me in this discussion is that people keep bringing up the fact that nouveau is mostly developed by volunteers and thus it doesn't make sense to make sure it's backwards (or forwards) compatible. But the way I see it, it's the complete opposite. It's _more_ important to support ABIs for community-driven efforts because you're relying on people who by definition don't have time to waste. While the nouveau people might have good intentions, I'm afraid they might be severely limiting their developer and tester base because they're not focused on real world problems (like the ones Linus is seeing). staging != stable Nobody guaranteed a stable API for staging and in fact it was stated previously it needed to be changed. Please lets just get back to work and stop declaring the sky is falling. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
* Pekka Enberg penb...@cs.helsinki.fi wrote: On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote: The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: ?- wrong ?- harmful ?- limits the developer base ?- limits the tester base ?- wastes time and effort. (fewer developers/testers means that while _this_ ? feature was easier to add, all your _future_ features will be a bit harder ? to do. It compounds up.) ?- so it hurts even the very developer who is most convinced that this was the ? right thing to do It's a bad technical decision throughout. It's masochistic and often suicidal to just about any project in essence. I've seen projects that did it once and died just due to that single act of stupidity. I've seen projects that have done it a few times and took the usage hit, limped along with the wounds and never grew to the size they could have achieved. I've seen projects that did it once, took the hit, learned from it and never did it again. Agreed. What bothers me in this discussion is that people keep bringing up the fact that nouveau is mostly developed by volunteers and thus it doesn't make sense to make sure it's backwards (or forwards) compatible. But the way I see it, it's the complete opposite. It's _more_ important to support ABIs for community-driven efforts because you're relying on people who by definition don't have time to waste. While the nouveau people might have good intentions, I'm afraid they might be severely limiting their developer and tester base because they're not focused on real world problems (like the ones Linus is seeing). Yeah. I've seen a few other bad arguments as well: 'exploding test matrix' This is often the result of _another_ bad technical decision: over-modularization. Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature: - it's developed by the same tightly knit developer base who often cross between these packages. Features often need changes in each component. - a developer to be able to do real work has to have the latest sources of all these components. - a user just uses whatever horizontal version cut the distro did and never truly 'mixes' these components as a conscious decision. - distros just try to get the latest and most capable but still stable version. Desperately so. Often they will create a version mix that was never tested by developers in that form. They'll expose users to ABI combinations that were never really intended. They have trouble bootstrapping and stabilizing those essentially random combinations and then have trouble applying stability and security fixes. The thing is, if development has such characteristics then it's pretty clearly not 3-4 separate projects but _one_ abstract project. [*] So the 'exploding test matrix' is simply the result of: creating ABIs between 3-4 _artificial components of the same project_ and then going through developer hell living with that mistake. [**] It's a bit as if we split up the kernel into 'microkernel' components, did a VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and then tried to develop them as separate components. If we did then then Linux kernel development would slow down massively while in reality everyone would _still_ have to have the latest and greatest source checked out to do some real development work and to be able to implement features that affect the whole kernel ... Linux would become an epic fail of historic proportions if we ever did that. Ingo [*] I realize that it's possibly hard for Xorg to merge with mesa and the kernel for license reasons, but my technical observation still stands. [**] I realize that modularization and many small packages were a clear advantage when we were still all downloading bits via 14.4k modems, but in this day and age of megabit connections that has become a non-issue. Rampant over-modularization and the resulting loss of focus on the end result (and the resulting explosion of a test matrix) is hurting us _far more_ than the disadvantages of any monolithic could ever hurt. We are seeing the proof of that all day with a 10+ MLOC kernel. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
* C. Bergstr?m cbergst...@pathscale.com wrote: Pekka Enberg wrote: On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote: The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: - wrong - harmful - limits the developer base - limits the tester base - wastes time and effort. (fewer developers/testers means that while _this_ feature was easier to add, all your _future_ features will be a bit harder to do. It compounds up.) - so it hurts even the very developer who is most convinced that this was the right thing to do It's a bad technical decision throughout. It's masochistic and often suicidal to just about any project in essence. I've seen projects that did it once and died just due to that single act of stupidity. I've seen projects that have done it a few times and took the usage hit, limped along with the wounds and never grew to the size they could have achieved. I've seen projects that did it once, took the hit, learned from it and never did it again. Agreed. What bothers me in this discussion is that people keep bringing up the fact that nouveau is mostly developed by volunteers and thus it doesn't make sense to make sure it's backwards (or forwards) compatible. But the way I see it, it's the complete opposite. It's _more_ important to support ABIs for community-driven efforts because you're relying on people who by definition don't have time to waste. While the nouveau people might have good intentions, I'm afraid they might be severely limiting their developer and tester base because they're not focused on real world problems (like the ones Linus is seeing). staging != stable Nobody guaranteed a stable API for staging and in fact it was stated previously it needed to be changed. Please lets just get back to work and stop declaring the sky is falling. I dont think you understood the argument. The (very simple) argument was: no matter how a project is developed, whether it's been freshly announced (not even in staging), in staging or been upstream for years, breaking ABIs is _technically wrong_. No ifs and when. A released ABI that is in use cannot be so messy to make it worth breaking. You've got users. You've got developers. You've got yourself. You can still phase it out gradually (and even do that quickly), one or two stable releases down the road you can even print out the final ABI removal patch on paper, make a bonfire out of it and jump on its ashes in joy, but if you are interested in running a successful OSS project then the current ABI is sacrosanct. Ingo -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, Mar 5, 2010 at 5:44 PM, Ingo Molnar mi...@elte.hu wrote: * Pekka Enberg penb...@cs.helsinki.fi wrote: On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar mi...@elte.hu wrote: The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: ?- wrong ?- harmful ?- limits the developer base ?- limits the tester base ?- wastes time and effort. (fewer developers/testers means that while _this_ ? feature was easier to add, all your _future_ features will be a bit harder ? to do. It compounds up.) ?- so it hurts even the very developer who is most convinced that this was the ? right thing to do It's a bad technical decision throughout. It's masochistic and often suicidal to just about any project in essence. I've seen projects that did it once and died just due to that single act of stupidity. I've seen projects that have done it a few times and took the usage hit, limped along with the wounds and never grew to the size they could have achieved. I've seen projects that did it once, took the hit, learned from it and never did it again. Agreed. What bothers me in this discussion is that people keep bringing up the fact that nouveau is mostly developed by volunteers and thus it doesn't make sense to make sure it's backwards (or forwards) compatible. But the way I see it, it's the complete opposite. It's _more_ important to support ABIs for community-driven efforts because you're relying on people who by definition don't have time to waste. While the nouveau people might have good intentions, I'm afraid they might be severely limiting their developer and tester base because they're not focused on real world problems (like the ones Linus is seeing). Yeah. I've seen a few other bad arguments as well: 'exploding test matrix' This is often the result of _another_ bad technical decision: over-modularization. Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature: - it's developed by the same tightly knit developer base who often cross between these packages. Features often need changes in each component. - a developer to be able to do real work has to have the latest sources of all these components. - a user just uses whatever horizontal version cut the distro did and never truly 'mixes' these components as a conscious decision. - distros just try to get the latest and most capable but still stable version. Desperately so. Often they will create a version mix that was never tested by developers in that form. They'll expose users to ABI combinations that were never really intended. They have trouble bootstrapping and stabilizing those essentially random combinations and then have trouble applying stability and security fixes. The thing is, if development has such characteristics then it's pretty clearly not 3-4 separate projects but _one_ abstract project. [*] So the 'exploding test matrix' is simply the result of: creating ABIs between 3-4 _artificial components of the same project_ and then going through developer hell living with that mistake. [**] It's a bit as if we split up the kernel into 'microkernel' components, did a VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and then tried to develop them as separate components. If we did then then Linux kernel development would slow down massively while in reality everyone would _still_ have to have the latest and greatest source checked out to do some real development work and to be able to implement features that affect the whole kernel ... Linux would become an epic fail of historic proportions if we ever did that. The other option that we used to have was out-of-tree kernel modules, that shipped in X.org along with Mesa all in one big tree. This wasn't satisfactory and we were pretty much told to put the drm modules into the kernel at that point, Other suggestion from Luc has been to stablise drm/mesa/X.org APIs a lot more and ship driver sources for all 3 bit separately, but that doesn't seem workable either, since the Mesa API is infinitely broad (its effectively OpenGL), and changes way too often, as does the kernel API, though the drm component is probably okay. You'll find groups like Intel are releasing things at fairly similiar times every quarter and recommending those groupings for distros to take as tested together. You also have the BSD options where they just create a base OS system and screw the whole pick-n-mix decisions. Dave -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing
