[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 changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from Shawn Starr 2010-03-05 21:27:27 PST --- Reopen, i dont have a consistant setup with drm changes happening.. I will close it once I can double confirm things. -- 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® 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 26195] Green screen on HDMI with RV730
http://bugs.freedesktop.org/show_bug.cgi?id=26195 --- Comment #17 from Michael Lothian 2010-03-05 17:25:16 PST --- This was using the latest head of drm-radeon-testing which has been working fine for a while as per this bug Did you want me to go back to when I had issues or revert the disable HDMI audio commit? -- 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® 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 #9 from Joseph Jezak 2010-03-05 16:42:54 PST --- I'm using kernel 2.6.33, libdrm-2.4.16 and not using KMS, but if you'd like I can try that as well. Bisected, and came up with this as the problem commit: 5fb5ea97f4439184f03075f57fa1fda56caf51b4 is the first bad commit commit 5fb5ea97f4439184f03075f57fa1fda56caf51b4 Author: Maciej Cencora Date: Sat Jul 11 20:40:51 2009 +0200 r300: use VBOs for vertex attributes :04 04 a1563d1d248860e6feb264e5f8a2b97e618a31401538bf6175a6ca180af150086a5b99847a567436 M src If you'd still like my Xorg log, please let me know. -- 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® 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
[PATCH] drm/radeon/r600: add missing license and comments to r600_blit_shaders.c
>From 6e323fc30b00aac303973ef3d5cadd4ba1f228c6 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Fri, 5 Mar 2010 19:22:24 -0500
Subject: [PATCH] drm/radeon/r600: add missing license and comments to
r600_blit_shaders.c
R6xx+ cards need to use the 3D engine to blit data which requires
quite a bit of hw state setup. Rather than pull the whole 3D driver
(which normally generates the 3D state) into the DRM, we opt to use
statically generated state tables. The regsiter state and shaders
were hand generated to support blitting functionality. See the 3D
driver or documentation for descriptions of the registers and
shader instructions.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_blit_shaders.c | 35
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c
b/drivers/gpu/drm/radeon/r600_blit_shaders.c
index a112c59..0271b53 100644
--- a/drivers/gpu/drm/radeon/r600_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/r600_blit_shaders.c
@@ -1,7 +1,42 @@
+/*
+ * Copyright 2009 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) AND/OR ITS SUPPLIERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Alex Deucher
+ */
#include
#include
+/*
+ * R6xx+ cards need to use the 3D engine to blit data which requires
+ * quite a bit of hw state setup. Rather than pull the whole 3D driver
+ * (which normally generates the 3D state) into the DRM, we opt to use
+ * statically generated state tables. The regsiter state and shaders
+ * were hand generated to support blitting functionality. See the 3D
+ * driver or documentation for descriptions of the registers and
+ * shader instructions.
+ */
+
const u32 r6xx_default_state[] =
{
0xc0002400,
--
1.5.6.3
0001-drm-radeon-r600-add-missing-license-and-comments-to.patch
Description: application/mbox
--
Download Intel® 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 Fri, 2010-03-05 at 16:11 -0800, Jesse Barnes wrote: > On Fri, 5 Mar 2010 23:19:13 +0100 > wrote: > > > Hi, > > > > On Thu, Mar 04, 2010 at 12:37:23PM -0800, 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, > > > > Err, how would moving the list to fdo help with the "non-subscriber > > aspect"?... > > I was thinking that managing the moderation queue would be faster; > sf.net is always horribly slow for me, but fdo is usually pretty quick. Can't say I've really noticed any difference, probably thanks to the awesome listadmin tool. But it certainly won't hurt. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel® 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 Fri, 5 Mar 2010 23:19:13 +0100 wrote: > Hi, > > On Thu, Mar 04, 2010 at 12:37:23PM -0800, 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, > > Err, how would moving the list to fdo help with the "non-subscriber > aspect"?... I was thinking that managing the moderation queue would be faster; sf.net is always horribly slow for me, but fdo is usually pretty quick. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel® 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
> > Distro's that want to have a good reputation need to have a higher > standard than, "hey, it's allowed by the GPL." And maybe if we are > sinking to the point where people are going to use "stable means ABI > breakages are allowed", we need to change the rules, since people want > to quote rules as opposed to just being good community members. If > you want lots of testers, then you need to be treat the testers, and > the other developers in our development community with respect. > > I think the real problem was that Fedora and the Neauveu community are > acting incredibly selfishly. They only care about their narrow point > of view, and don't care about the pain they are inflicting on the > kernel development process and other kernel developers. This is > _legal_. It is, however, anti-social. > >- Ted > > And people wonder why I stubbornly stick with Slackware Linux. -- Download Intel® 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?
Hi, On Thu, Mar 04, 2010 at 12:37:23PM -0800, 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, Err, how would moving the list to fdo help with the "non-subscriber aspect"?... -antrik- -- Download Intel® 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 6:19 PM, Linus Torvalds wrote: > The thing I objected to, in the VERY BEGINNING in this thread, i the fact > that the thing was done in such a way that it's basically impossible to > support the old/new ABI at all! [...] > The way this was done, it's apparently basically impossible for the Fedora > people to push out packaged that support both the old and the new kernel. The reason why the nouveau people wanted to leave the driver in staging is because they wanted to leave open the option of reshuffling the API. The Fedora guys integrated this stuff on their own risk, and linux (because of your pressure), also did. At no point in time nouveau guys agreed to freeze the API. Now they have done precisely what was expected; there's no surprise there. The surprise seems to be that you thought (for some reason), that reshuffling the API wouldn't break the old (or current in F12) user-space code. Now, how exactly do you think that could have been achieved? Even if you have both nouveau_drv-0.0.15.so, and nouveau_drv-0.0.16.so... What piece of could would choose one rather than the other? There has never been such a piece of code. If there was no compatibility code for API re-shuffling, and API re-shuffling was expected, the resulting breakage was doomed to happen. Finally, at least it's possible to compile the radeon driver without support for DRM, so perhaps nouveau (and other drivers), should check the kernel drm version at run-time instead, and fall-back to non-drm mode when the version is not compatible. I think that's a sensible approach, although that might require a considerable amount of code. However, that's something to consider for the future, as your current libdrm/nouveau is not prepared to handle the DRM API re-shuffle that _must_ happen. Cheers. -- Felipe Contreras -- Download Intel® 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/05/2010 09:42 AM, Jeff Garzik wrote: > On 03/05/2010 10:17 AM, Daniel Stone wrote: >> On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: >>> If it effects such a large number of people, which this noveau thing >>> does, it's entirely relevant to everyone. And the way it's breaking >>> and making kernel development difficult for so many people matters to >>> us. >> >> Maybe the lesson to be learned from all this is, 'if the developers >> don't want something merged because they're not ready and forsee huge >> problems in the future, actually listen to them instead of blindly >> ramming it in regardless'? But maybe that's just me. > > That particular horse left the barn when Fedora shipped nouveau in a > stable release, not when Linus merged it into his tree. > > Jeff > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > stopped me in my tracks i.g. in order to install using the livecd requires brain surgery. (for me that's fine, but for an average business person/s forget it). Justin P. Mattock -- Download Intel® 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 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote: > If distros want to run weird experiments on their users, let them! > Sure, sometimes bad things happen, but sometimes good things happen > too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut, > Plymouth, the list goes on and on. So what distro would you recommend for people who want to do kernel development, do kernel testing, and do kernel bisects to help us find bugs? Are you basically saying, "Kernel people shouldn't use Fedora"? So what should we use instead? - Ted -- Download Intel® 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 2:41 AM, Linus Torvalds wrote: > On Fri, 5 Mar 2010, Ben Skeggs 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. I believe Dave has already explained this to you, but nobody has mentioned it here. What you are supposed to do is install the new nouveau driver, which requires a new libdrm. So, just compile both libdrm, and nouveau, to a sandbox, say /opt/new-nouveau, and then in /etc/X11/xorg.conf: Section "Files" ModulePath "/opt/new-nouveau/lib/xorg/modules" ModulePath "/usr/lib/xorg/modules" EndSection That should do it. No frankensteinian F13 packaging stuff, and no mess with the system's /usr/lib/. Cheers. -- Felipe Contreras -- Download Intel® 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 26195] Green screen on HDMI with RV730
http://bugs.freedesktop.org/show_bug.cgi?id=26195 --- Comment #16 from Rafał Miłecki 2010-03-05 15:22:56 PST --- (In reply to comment #15) > Was this what you were after? Well, I'm afraid there is something wrong about your testing. I don't see any reason how my first (fast debugging) patch could change anything. It could be some really sensitive timing issue or compiler bug. I don't think any is the case. Anyway I'm reworking HDMI assigning right now, will publish patch this weekend. When we will have HDMI fixed (and hopefully working) we will can focus on green screen again. Meanwhile you can try again drm tree with and without my patch. As I said, I don't see reason how my first patch could fix anything. Can you double check 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® 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
Strawman, mostly because all distros suck, the less patches you apply the less likely things are to work, LFS is the most fragile thing out there, etc. Hurp derp. If you need a feature not in the distro, and it is needed because you have installed something not in the distro or not new enough, you will have to go get it yourself. If you want a bleeding X, you should be prepared to build bleeding DDX and Mesa. If you want a new kernel FS, you probably need a newer e2fsprogs or xfsprogs. If you want new kernel DRM, you will need a new libdrm. That process is relatively distro-agnostic. Posting from a mobile, pardon my terseness. ~ C. On Mar 5, 2010 1:51 PM, wrote: On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote: > If distros want to run weird exper... So what distro would you recommend for people who want to do kernel development, do kernel testing, and do kernel bisects to help us find bugs? Are you basically saying, "Kernel people shouldn't use Fedora"? So what should we use instead? - Ted -- Download Intel® 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] i965 OpenGL is heavily broken again
On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: > On Fri, 05 Mar 2010 23:18:07 +0200 > Maxim Levitsky wrote: > > > On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: > > > On Fri, 05 Mar 2010 22:42:21 +0200 > > > Maxim Levitsky wrote: > > > > > > > After quite long period of inactivity, I updated graphical stack on my > > > > desktop/server. > > > > > > > > To say the truth, I did such update about month ago, but found out that > > > > X refuses flatly to use DRI modules. I assumed that it was my mistake in > > > > compilation process (although it is automated). > > > > > > That generally indicates a build or config problem of some kind. Did > > > you ever narrow it down? > > Because the same compile process works now, I suspect that wasn't build > > failure. > > Well something weird is going on; maybe you didn't build X after Mesa > or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) > > > I now compiled same stack, but reverted mesa to > > > > commit 465fee75ee8991349da742e5a1a5be3cd179bb62 > > Author: Roland Scheidegger > > Date: Sat Nov 21 04:39:30 2009 -0800 > > > > intel: make CopyTex[Sub]Image fallback debug messages more > > consistent > > > > > > > > And compiled the xserver with --disable-aiglx > > (I will always use that option from now on, because I hate the way X and > > mesa are tied otherwise. For example X won't build if I compile it > > against old mesa, etc...) > > If you can't get AIGLX to work then it may indicate a bigger problem. > X needs to load a DRI driver to perform acceleration for indirect > clients, I'm not sure what in that is hate-worthy. > > > And now all 3D problems are gone. > > > > I now doing a bisect, although I am not sure if it will help much. > > Probably not. It sounds like your configuration is pretty custom and > something is seriously broken, so it'll be hard to help further. I don't think so. Older mesa works, new one works too but with bugs. New mesa just contains a lot of bugs. Best regards, Maxim Levitsky -- Download Intel® 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] i965 OpenGL is heavily broken again
On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky wrote: > On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: > > On Fri, 05 Mar 2010 22:42:21 +0200 > > Maxim Levitsky wrote: > > > > > After quite long period of inactivity, I updated graphical stack on my > > > desktop/server. > > > > > > To say the truth, I did such update about month ago, but found out that > > > X refuses flatly to use DRI modules. I assumed that it was my mistake in > > > compilation process (although it is automated). > > > > That generally indicates a build or config problem of some kind. Did > > you ever narrow it down? > Because the same compile process works now, I suspect that wasn't build > failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? > I now compiled same stack, but reverted mesa to > > commit 465fee75ee8991349da742e5a1a5be3cd179bb62 > Author: Roland Scheidegger > Date: Sat Nov 21 04:39:30 2009 -0800 > > intel: make CopyTex[Sub]Image fallback debug messages more > consistent > > > > And compiled the xserver with --disable-aiglx > (I will always use that option from now on, because I hate the way X and > mesa are tied otherwise. For example X won't build if I compile it > against old mesa, etc...) If you can't get AIGLX to work then it may indicate a bigger problem. X needs to load a DRI driver to perform acceleration for indirect clients, I'm not sure what in that is hate-worthy. > And now all 3D problems are gone. > > I now doing a bisect, although I am not sure if it will help much. Probably not. It sounds like your configuration is pretty custom and something is seriously broken, so it'll be hard to help further. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel® 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] i965 OpenGL is heavily broken again
On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: > On Fri, 05 Mar 2010 22:42:21 +0200 > Maxim Levitsky wrote: > > > After quite long period of inactivity, I updated graphical stack on my > > desktop/server. > > > > To say the truth, I did such update about month ago, but found out that > > X refuses flatly to use DRI modules. I assumed that it was my mistake in > > compilation process (although it is automated). > > That generally indicates a build or config problem of some kind. Did > you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. I now compiled same stack, but reverted mesa to commit 465fee75ee8991349da742e5a1a5be3cd179bb62 Author: Roland Scheidegger Date: Sat Nov 21 04:39:30 2009 -0800 intel: make CopyTex[Sub]Image fallback debug messages more consistent And compiled the xserver with --disable-aiglx (I will always use that option from now on, because I hate the way X and mesa are tied otherwise. For example X won't build if I compile it against old mesa, etc...) And now all 3D problems are gone. I now doing a bisect, although I am not sure if it will help much. Best regards, Maxim Levitsky > > > Now I repeat same process and find out that OpenGL does work, but once > > again it became very buggy, so buggy that it is almost unusable. > > > > > > > > Neverball. - Now it hangs when I switch to full screen mode. > > - Also, once again frames appear to be rendered > > in batches > > In fact full screen mode leads to a hang always > > > > > > Sauerbraten. - Hangs early with 'Loading' > > Nexuiz - Same as above > > > > Compiz. - Hangs now after start > > > > GoogleEarth - No change, works, but in street view, one on screen label > > 'jumps' > > > > Xmoto, Torcs. Full screen mode hangs. > > I just pushed a few fixes to the xf86-video-intel code that might > help... > -- Download Intel® 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 26195] Green screen on HDMI with RV730
http://bugs.freedesktop.org/show_bug.cgi?id=26195 --- Comment #15 from Michael Lothian 2010-03-05 13:04:29 PST --- Was this what you were after? -- 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® 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 11:38 AM, Corbin Simpson wrote: > I was trying my hardest to not say anything, but... > > [blah blah Fedora blah Ubuntu blah staging blah blah] > > That said... Code probably is moving too fast inside nouveau. There is > a bit of a wall to go through to get new patches upstream, which one > would hope would inspire some developer restraint. intel and radeon > both still have most (if not all) of the legacy code needed by ancient > userspaces, and both DDX drivers are doing multiple-branch releases to > keep old userspace interfaces alive for people unable to update their > kernels. It might be useful for the nouveau guys to really seriously > consider code before it leaves their trees and enters mainline; > writing code that you won't commit to is quite lame for the obvious > reasons, but also for some unobvious reasons, e.g. it makes you look > like you don't actually know what you're doing and would rather just > keep reinventing wheels without justifying and testing your design > choices. (This is also why I was not exactly pleased with the > suggestion of retooling all of the r600 userspace over a change to the > CS system; we just spent the better part of a year moving everything > over to CS!) Strike this paragraph. After talking with the nouveau guys again, I don't think they were doing anything out of the ordinary for staging drivers. Frustrating, sure, but not anything worth a 200-post flame war. Also, I am a tool, don't know what I'm talking about, not actually a nouveau dev, etc. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® 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] i965 OpenGL is heavily broken again
On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky wrote: > After quite long period of inactivity, I updated graphical stack on my > desktop/server. > > To say the truth, I did such update about month ago, but found out that > X refuses flatly to use DRI modules. I assumed that it was my mistake in > compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? > Now I repeat same process and find out that OpenGL does work, but once > again it became very buggy, so buggy that it is almost unusable. > > > > Neverball. - Now it hangs when I switch to full screen mode. > - Also, once again frames appear to be rendered > in batches > In fact full screen mode leads to a hang always > > > Sauerbraten. - Hangs early with 'Loading' > Nexuiz - Same as above > > Compiz. - Hangs now after start > > GoogleEarth - No change, works, but in street view, one on screen label > 'jumps' > > Xmoto, Torcs. Full screen mode hangs. I just pushed a few fixes to the xf86-video-intel code that might help... -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel® 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
i965 OpenGL is heavily broken again
After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). Now I repeat same process and find out that OpenGL does work, but once again it became very buggy, so buggy that it is almost unusable. Neverball. - Now it hangs when I switch to full screen mode. - Also, once again frames appear to be rendered in batches In fact full screen mode leads to a hang always Sauerbraten. - Hangs early with 'Loading' Nexuiz - Same as above Compiz. - Hangs now after start GoogleEarth - No change, works, but in street view, one on screen label 'jumps' Xmoto, Torcs. Full screen mode hangs. Environment: libdrm :- commit 1d4d1e6b138aac8bd734c4c20617a43fb3337c63 Author: Eric Anholt Date: Thu Mar 4 16:09:40 2010 -0800 intel: Only align Y-tiling pitch to the Y tile width. Fixes piglit depth-tex-modes on gen4. mesa :- commit 2b15f4fc6840b4bb5ca81d3ed0137c31f63725e8 Author: Michal Krol Date: Fri Mar 5 18:42:42 2010 +0100 progs: Add arbocclude2 demo. xserver :- commit bbae92795c7eab062e6722c42fa7915e0cee5d69 Author: Matt Turner Date: Mon Feb 15 20:08:09 2010 -0500 Replace assembly with generic unaligned access code Removes Alpha assembly, and probably works around unaligned accesses on other sensitive platforms. xf86-video-intel :- commit 54ac4e2df987b72529a523ffbde357bec27e3658 Author: Chris Wilson Date: Thu Mar 4 21:34:52 2010 + Rate limit batch buffer error. Once we hit this error it's unlikely that we're coming back - so don't flood the logs with redundant information. Signed-off-by: Chris Wilson kernel: commit 9ddabb6700f82a033a76bcf7a547204fa12aaa17 Merge: bf0c346 3ce2f76 Author: Linus Torvalds Date: Fri Jan 15 14:53:24 2010 -0800 Merge branch 'for-linus/samsung' of git://git.fluff.org/bjdooks/linux * 'for-linus/samsung' of git://git.fluff.org/bjdooks/linux: ARM: MINI2440: Fixup __initdata usage ARM: MINI2440: Fix crash on boot due to improper __initdata qualifier ARM: SMDK6410: Specify no GPIO for B_PWR_5V regulator ARM: S3C: NAND: Check the existence of nr_map before copying Best regards, Maxim Levitsky -- Download Intel® 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
> So overall, I'd say that we spent about a month of developer time > at least between jbarnes, ickle, and myself, on extending the execbuf > interface to add a flag saying "dear kernel, please don't do this bit of > work on this buffer, because I don't need it and it makes things slow." Perhaps then, we should break ABI compatibility _more_ often to speed up development, but also have awesome mechanisms to make it painless for the user. Such as: 1. Automatic side by side userspace installation, as Linus proposed 2. Kernel "make install" refusing to proceed if it finds that userspace is not updated, and giving instructions on how to update userspace 3. Distributions packaging the new ABI X/Mesa drivers and libdrm even for stable distributions 4. Kernel "make install" offering to automatically install said distribution packages if it detects a supported distribution 5. Ability to drop new versions of drivers/gpu/drm in an older kernel tree and have it compile (within reasonable limits) In particular, for people with (slightly) old kernels, it should be much easier to make updated DRM trees still work with older kernels, than attempting to make updated userspace work with older kernel modules. This also actually gives them the benefits of the new code. And for people with really old kernels, it's not different from any other hardware device, which requires a kernel upgrade to have better support. Then, for instance, Linus would just have seen the following upon running make install: This kernel requires the Nouveau userspace version 0.0.16, which you don't have installed. Fedora 12 has been detected. Invoke yum to install the RPMs required for it? [y/n] _or_ Ubuntu 9.10 has been detected Invoke apt-get to install the packages required for it? [y/n] If the user says no, or the distribution is unknown, instructions on how to download and compile the source would be presented. Once you setup this system, you can freely break the ABI with no significant user discomfort by just raising the version number. This also potentially applies to stuff other than DRM (e.g. perf, kvm, iptables, udev, filesystem-specific tools/APIs, various device configuration systems, and so on). The really stable APIs/ABIs should not be the (undocumented) kernel ones, but Xlib and OpenGL, which actually have formal specifications. Perhaps eventually Gallium could join them as a stable API closer to the hardware, but that's a long way off. -- Download Intel® 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
[PATCH] drm/radeon/kms: gfx init fixes for r6xx/r7xx
>From cec90cfdc0f20efcbcd266069a6a8234d230cc0b Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Fri, 5 Mar 2010 14:50:37 -0500 Subject: [PATCH] drm/radeon/kms: gfx init fixes for r6xx/r7xx This fixes some issues with the last gfx init patch. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/r600.c|1 + drivers/gpu/drm/radeon/r600_cp.c |3 +++ drivers/gpu/drm/radeon/rv770.c |3 +++ 3 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index f9a8335..3980ec9 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -1132,6 +1132,7 @@ void r600_gpu_init(struct radeon_device *rdev) /* Setup pipes */ WREG32(CC_RB_BACKEND_DISABLE, cc_rb_backend_disable); WREG32(CC_GC_SHADER_PIPE_CONFIG, cc_gc_shader_pipe_config); + WREG32(GC_USER_SHADER_PIPE_CONFIG, cc_gc_shader_pipe_config); tmp = R6XX_MAX_PIPES - r600_count_pipe_bits((cc_gc_shader_pipe_config & INACTIVE_QD_PIPES_MASK) >> 8); WREG32(VGT_OUT_DEALLOC_CNTL, (tmp * 4) & DEALLOC_DIST_MASK); diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c index 40416c0..68e6f43 100644 --- a/drivers/gpu/drm/radeon/r600_cp.c +++ b/drivers/gpu/drm/radeon/r600_cp.c @@ -1548,10 +1548,13 @@ static void r700_gfx_init(struct drm_device *dev, RADEON_WRITE(R600_CC_RB_BACKEND_DISABLE, cc_rb_backend_disable); RADEON_WRITE(R600_CC_GC_SHADER_PIPE_CONFIG, cc_gc_shader_pipe_config); + RADEON_WRITE(R600_GC_USER_SHADER_PIPE_CONFIG, cc_gc_shader_pipe_config); RADEON_WRITE(R700_CC_SYS_RB_BACKEND_DISABLE, cc_rb_backend_disable); RADEON_WRITE(R700_CGTS_SYS_TCC_DISABLE, 0); RADEON_WRITE(R700_CGTS_TCC_DISABLE, 0); + RADEON_WRITE(R700_CGTS_USER_SYS_TCC_DISABLE, 0); + RADEON_WRITE(R700_CGTS_USER_TCC_DISABLE, 0); num_qd_pipes = R7XX_MAX_PIPES - r600_count_pipe_bits((cc_gc_shader_pipe_config & R600_INACTIVE_QD_PIPES_MASK) >> 8); diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c index 37887de..63c181b 100644 --- a/drivers/gpu/drm/radeon/rv770.c +++ b/drivers/gpu/drm/radeon/rv770.c @@ -647,10 +647,13 @@ static void rv770_gpu_init(struct radeon_device *rdev) WREG32(CC_RB_BACKEND_DISABLE, cc_rb_backend_disable); WREG32(CC_GC_SHADER_PIPE_CONFIG, cc_gc_shader_pipe_config); + WREG32(GC_USER_SHADER_PIPE_CONFIG, cc_gc_shader_pipe_config); WREG32(CC_SYS_RB_BACKEND_DISABLE, cc_rb_backend_disable); WREG32(CGTS_SYS_TCC_DISABLE, 0); WREG32(CGTS_TCC_DISABLE, 0); + WREG32(CGTS_USER_SYS_TCC_DISABLE, 0); + WREG32(CGTS_USER_TCC_DISABLE, 0); num_qd_pipes = R7XX_MAX_PIPES - r600_count_pipe_bits((cc_gc_shader_pipe_config & INACTIVE_QD_PIPES_MASK) >> 8); -- 1.5.6.3 0001-drm-radeon-kms-gfx-init-fixes-for-r6xx-r7xx.patch Description: application/mbox -- Download Intel® 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 12:21:29 +, Alan Cox wrote: > Serious discussion point perhaps should be: is the libdrm so close to the > kernel it ought to be in the same git tree ? Alternatively does it need > to be easier to have multiple Nouveau libdrms autoselected according to > the kernel side versioning. ELF library versioning is not rocket science > and both the old and new libraries exist and can be installed so all the > bits are present except for the wrapper to load the right sublibrary yes ? That *would* make versioning impossible. To make the difficulty of improving ABI at the moment concrete, I just got done merging the patches for execbuf2 in userland and enabling i915 texture tiling. This was a 3% performance win in one test I was looking at, and 1% in another -- less than hoped, but important nonetheless (there are other cases that should see 30% or so wins hopefully). The patches got written back in July, and revved several times as they broke various combinations of compatibility. At the point that I merged eb2 to the kernel for 2.6.33, it wasn't *really* tested -- the userland side was broken all to hell it looked like, but at least it wasn't regressing execbuf1 any more, right? I spent this week getting userland working, including a new libdrm release (already obsolete because a bug in the libdrm violated what the ABI between libdrm <-> msea was supposed to be). So overall, I'd say that we spent about a month of developer time at least between jbarnes, ickle, and myself, on extending the execbuf interface to add a flag saying "dear kernel, please don't do this bit of work on this buffer, because I don't need it and it makes things slow." This is not that bad for Intel folks. We're paid to hack on it, and can justify spending ridiculous amounts of time for small wins. I actually enjoy this. Right now all the userland -- whether it's Mesa, xf86-video-intel, libva, cairo-drm, stand-alone DRM testcases, etc., gets to move to the new libdrm API, declare its dependency in PKG_CHECK_MODULES, and hand that new flag to libdrm as if the kernel supported the new interface. Inside libdrm, it looks at the kernel version and uses the new interface or old as appropriate. The ugly versioning stuff stays in one easy-to-review 5kloc component, and the complicated 50kloc driver components get to pretend they have a fancy new kernel. But if libdrm's in the kernel, all those userland components no longer get to rely on the version of libdrm, because distros will ship whatever's with the kernel they're using and our userland does have to work on (relatively recent) distros. Each of those userland components would have to grow a compatibility layer to work with whatever kernel libdrm is available, passing the flag in the new API or using the old API. Userland would even buggier for having to replicate all that logic everywhere, and we probably wouldn't have execbuf2 landed yet. Well, OK. What I'd really do instead is make the kernel libdrm be a thin ioctl wrapper, and build a librealdrm that does what libdrm does today. But I don't think that's what you were suggesting. pgp21kB5PwxVU.pgp Description: PGP signature -- Download Intel® 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:46 AM, wrote: > On Fri, Mar 05, 2010 at 06:04:34PM +0200, Daniel Stone wrote: >> >> So you're saying that there's no way to develop any reasonable body of >> code for the Linux kernel without committing to keeping your ABI >> absolutely rock-solid stable for eternity, no exceptions, ever? Cool, >> that worked really well for Xlib. > > No, that's not what people are saying. What people are saying is, > "avoid flag days". Deprecate things over a 6-12 month time period. > We have lots of really good interfaces for doing that. > > You say you don't want to do that? Then keep it to your self and > don't get it dropped into popular distributions like Fedora or Ubuntu. > You want a larger pool of testers? Great! The price you need to pay > for that is to be able to do some kind of of ABI versioning so that > you don't have "drop dead flag days". > > If you don't want to be a good citizen, then prepared to have people > call you out for, well, not being a good OSS citizen. I was trying my hardest to not say anything, but... Nouveau isn't an official Xorg project. It hasn't been added to the jhbuild list for auto-checkout, it doesn't get tinderbox time (admittedly a function of being part of the jhbuild) and I don't think it's on the katamari list, so it's never been shipped as part of an Xorg release. It is only in mainline under the staging rules; drivers come and go from staging under fairly lax rules. Fedora ships this stuff because they're actively developing it and enjoy deploying half-broken things to users in the vain hope that it magically won't break. I can't count the number of kittens eaten by Fedora systems I've used. (It is kind of sad that Fedora's still the best distro about not deploying broken stuff but still remaining up-to-date.) Tellingly, it doesn't look like this interface change has been deployed to stable Fedora, just Rawhide. The Ubuntu people don't talk to us as much as they should. Seeing how badly they biffed Radeon and Intel KMS deployment, it's hard for me to believe that deploying Nouveau went smoothly. I don't have much more personal experience; my work computer has an HD 3450 in it now instead of the old GeForce, and that's my only Ubuntu box. If distros want to run weird experiments on their users, let them! Sure, sometimes bad things happen, but sometimes good things happen too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut, Plymouth, the list goes on and on. If the problem here is actually that a distro is deploying a staging driver and picking up the pieces themselves, then just say it. This whole thing with flag days, deprecation, interface changes, etc. hinges on the idea that the code being deprecated was stable, usable, and widely deployed, but it wasn't and isn't. That said... Code probably is moving too fast inside nouveau. There is a bit of a wall to go through to get new patches upstream, which one would hope would inspire some developer restraint. intel and radeon both still have most (if not all) of the legacy code needed by ancient userspaces, and both DDX drivers are doing multiple-branch releases to keep old userspace interfaces alive for people unable to update their kernels. It might be useful for the nouveau guys to really seriously consider code before it leaves their trees and enters mainline; writing code that you won't commit to is quite lame for the obvious reasons, but also for some unobvious reasons, e.g. it makes you look like you don't actually know what you're doing and would rather just keep reinventing wheels without justifying and testing your design choices. (This is also why I was not exactly pleased with the suggestion of retooling all of the r600 userspace over a change to the CS system; we just spent the better part of a year moving everything over to CS!) ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Download Intel® 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
[PATCH] drm/radeon/kms: add PM quirk for Asus Radeon HD 3200
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/radeon_pm.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 6b65f15..a2ea0be 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -79,6 +79,23 @@ static void radeon_print_power_mode_info(struct
radeon_device *rdev)
}
}
+static void radeon_apply_pm_quirks(struct radeon_device *rdev)
+{
+ /* Asus Radeon HD 3200 contains power states with reversed types */
+ /* We received single report like this so far. See FDO bug #26347.
+ In case of more reports we may consider some detecting algorithm */
+ if ((rdev->pdev->device == 0x9610) &&
+ (rdev->pdev->subsystem_vendor == 0x1043) &&
+ (rdev->pdev->subsystem_device == 0x82f1)) {
+ rdev->pm.power_state[0].type = POWER_STATE_TYPE_PERFORMANCE;
+ rdev->pm.power_state[1].type = POWER_STATE_TYPE_DEFAULT;
+ rdev->pm.default_power_state = &rdev->pm.power_state[1];
+ rdev->pm.current_power_state = rdev->pm.default_power_state;
+ rdev->pm.current_clock_mode =
+ rdev->pm.default_power_state->default_clock_mode;
+ }
+}
+
static struct radeon_power_state * radeon_pick_power_state(struct
radeon_device *rdev,
enum
radeon_pm_state_type type)
{
@@ -235,6 +252,7 @@ int radeon_pm_init(struct radeon_device *rdev)
radeon_atombios_get_power_modes(rdev);
else
radeon_combios_get_power_modes(rdev);
+ radeon_apply_pm_quirks(rdev);
radeon_print_power_mode_info(rdev);
}
--
1.6.4.2
--
Download Intel® 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 05, 2010 at 05:04:14PM +, Alan Cox wrote: > You can only see it as malicious if you assume they ever had some reason > to keep compatibility or had promised it somewhere. Quite the reverse > happened, and they never asked to be upstream in the first place. The reason why this thread is inspiring so much traffic is because it's fundamentally about community norms. There are plenty of things that are not illegal, but which are at the same time anti-social. For example, there are all sorts of rules, if you are a researcher, about experimenting on human subjects. Many of those restrictions aren't codified in law, but if you violate them, other researches will say that you are a bad person, a bad researcher, and refuse to associate with you. And you might well lose your funding in the future --- but it's not illegal. If we are only talking about obligations under the GPL, sure, no one violated copyright licenses. But what *did* happen is someone basically said, "I want to experiment on a whole bunch of users, but I don't want to spend the effort to do things in the right way. I want to take short cuts; I don't want to worry about the fact that it will be impossible to test kernels without pulling Frankenstein combinations of patches between Fedora 13 and Fedora 12." It's much like people who drill oil in the Artic Ocean, but use single-hulled tankers and then leave so much toxic spillage in their wake, but then say, "hey, the regulations said what we did was O.K. Go away; don't bother us." Distro's that want to have a good reputation need to have a higher standard than, "hey, it's allowed by the GPL." And maybe if we are sinking to the point where people are going to use "stable means ABI breakages are allowed", we need to change the rules, since people want to quote rules as opposed to just being good community members. If you want lots of testers, then you need to be treat the testers, and the other developers in our development community with respect. I think the real problem was that Fedora and the Neauveu community are acting incredibly selfishly. They only care about their narrow point of view, and don't care about the pain they are inflicting on the kernel development process and other kernel developers. This is _legal_. It is, however, anti-social. - Ted -- Download Intel® 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 05, 2010 at 06:04:34PM +0200, Daniel Stone wrote: > > So you're saying that there's no way to develop any reasonable body of > code for the Linux kernel without committing to keeping your ABI > absolutely rock-solid stable for eternity, no exceptions, ever? Cool, > that worked really well for Xlib. No, that's not what people are saying. What people are saying is, "avoid flag days". Deprecate things over a 6-12 month time period. We have lots of really good interfaces for doing that. You say you don't want to do that? Then keep it to your self and don't get it dropped into popular distributions like Fedora or Ubuntu. You want a larger pool of testers? Great! The price you need to pay for that is to be able to do some kind of of ABI versioning so that you don't have "drop dead flag days". If you don't want to be a good citizen, then prepared to have people call you out for, well, not being a good OSS citizen. - Ted -- Download Intel® 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/05/2010 10:17 AM, Daniel Stone wrote: > On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: >> If it effects such a large number of people, which this noveau thing >> does, it's entirely relevant to everyone. And the way it's breaking >> and making kernel development difficult for so many people matters to >> us. > > Maybe the lesson to be learned from all this is, 'if the developers > don't want something merged because they're not ready and forsee huge > problems in the future, actually listen to them instead of blindly > ramming it in regardless'? But maybe that's just me. That particular horse left the barn when Fedora shipped nouveau in a stable release, not when Linus merged it into his tree. Jeff -- Download Intel® 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: Making Xorg easier to test
On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote: > From: Daniel Stone > Date: Fri, 5 Mar 2010 17:41:43 +0200 > > > I understand that you guys are upset about this, so maybe you'd like to > > donate, say, 10% of your developer base to help out? That'd be pretty > > ace. > > You have to support less than %10 of the amount of hardware we have to > support. You can't compare a network card and a GPU. The latter is way more complex to code for. Xav -- Download Intel® 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
* Mike Galbraith wrote: > On the bright side, all this hubbub sends a very positive message to the > noveau development crew. Folks, your work is important. I'd be proud as a > peacock :) Heh, most definitely so! Noveau really is a game-changer i think, it's a big break-through for Xorg IMO. For the first time in Linux history we support 90%+ of graphics hardware in a more or less acceptable way. That is a big deal really and the xorg/drm folks should be proud of that accomplishment. It solves the nvidia.ko mess to a large degree and moves all these things into an actionable technical domain. I'm so much happier to argue with OSS folks who write this code than having to look at nvidia.ko tainted kernel crash logs. Ingo -- Download Intel® 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: Making Xorg easier to test
From: Jesse Barnes Date: Fri, 5 Mar 2010 10:02:44 -0800 > So from that perspective, the graphics stack is the most complex one in > Linux by a long shot. It's even worse than if we had STREAMS > networking with a ton of different modules up in userspace messing with > protocol. :) Maybe :-) -- Download Intel® 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: Making Xorg easier to test
On Fri, 05 Mar 2010 09:54:06 -0800 (PST) David Miller wrote: > From: Xavier Bestel > Date: Fri, 05 Mar 2010 18:50:24 +0100 > > > On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote: > >> From: Daniel Stone > >> Date: Fri, 5 Mar 2010 17:41:43 +0200 > >> > >> > I understand that you guys are upset about this, so maybe you'd like to > >> > donate, say, 10% of your developer base to help out? That'd be pretty > >> > ace. > >> > >> You have to support less than %10 of the amount of hardware we have to > >> support. > > > > You can't compare a network card and a GPU. The latter is way more > > complex to code for. > > I wasn't talking specifically about network cards. But if you want > specific examples... > > How about the x86 or parisc cpu, and all their derivatives, are those > complex enough for you? :-) > > I've worked on OpenGL capable grapics card drivers of various > vintages, and I honestly don't think there is anything in there more > complex than what we have to deal with in the kernel. I think you must be saying this for the sake of argument. The complexity lies not in the programming interfaces exposed by the device (those indeed are complex, more so than some CPUs, less so than others). The complexity lies in the fact that those interfaces change from revision to revision, and even between boards sharing the same chip. And more than that, the interfaces exposed to applications are spread across many software components, some of which send commands to the hardware directly. The problem Linus ran into is directly related to this fact, because it involved the interfaces between a few of these components. So from that perspective, the graphics stack is the most complex one in Linux by a long shot. It's even worse than if we had STREAMS networking with a ton of different modules up in userspace messing with protocol. :) -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel® 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 11:05 AM, David Miller wrote: > From: Alan Cox > Date: Fri, 5 Mar 2010 16:02:17 + > >>> You can't unleash something like this on a userbase of this magnitude >>> and then throw your hands up in the air and say "I'm not willing to >>> support this in a reasonable way." >> >> Not to belabour the obvious - they didn't. Linus ordered them to merge it. > > And I'm arguing not merging it upstream would be like saying > the same thing. > No, it's not like saying the same thing. Not merging it upstream is saying "we're not willing to support this in a reasonable way *at this time*." -- Download Intel® 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: Making Xorg easier to test
From: Xavier Bestel Date: Fri, 05 Mar 2010 18:50:24 +0100 > On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote: >> From: Daniel Stone >> Date: Fri, 5 Mar 2010 17:41:43 +0200 >> >> > I understand that you guys are upset about this, so maybe you'd like to >> > donate, say, 10% of your developer base to help out? That'd be pretty >> > ace. >> >> You have to support less than %10 of the amount of hardware we have to >> support. > > You can't compare a network card and a GPU. The latter is way more > complex to code for. I wasn't talking specifically about network cards. But if you want specific examples... How about the x86 or parisc cpu, and all their derivatives, are those complex enough for you? :-) I've worked on OpenGL capable grapics card drivers of various vintages, and I honestly don't think there is anything in there more complex than what we have to deal with in the kernel. -- Download Intel® 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 05, 2010 at 04:31:29PM +, Alan Cox wrote: > On Fri, 05 Mar 2010 08:06:26 -0800 (PST) > David Miller wrote: > > > From: Daniel Stone > > Date: Fri, 5 Mar 2010 18:04:34 +0200 > > > > > So you're saying that there's no way to develop any reasonable body of > > > code for the Linux kernel without committing to keeping your ABI > > > absolutely rock-solid stable for eternity, no exceptions, ever? Cool, > > > that worked really well for Xlib. > > > > read() still works the same way it did 30 years ago last time I > > checked. > > Thats disingenous as read() is a method not an interface. It's also wrong > because read() and write() behaviour has changed in various ways and old > code broke because of it in subtle ways. Keeping the same method behaviour > would have required things like new versions of read() for 64bit files, > nonblocking, mandlocks, NFS, networking, etc all of which changed the > core read() behaviour. I've yet to see anyone meaningfully argue it was > the wrong thing to do. > > Alan > Also GPU API is way more complex than any others kernel API (at least to my knowledge) and you can't know if the API you have is the good one until you have a fully working & fast 3D driver ... and that takes either a lot of time with a lot of people. Cheers, Jerome -- Download Intel® 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
Alan Cox wrote: >> Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The >> guy who is, as far as I know, effectively in charge of that whole >> integration. Yeah, I realize that there are other people (Kyle?) involved, >> and maybe Dave isn't as central as I think he is, but I learnt from last >> time that the nouveau guys don't seem to care. >> > > Ok "screamed about" is perhaps better wording. Why should the Nouveau > guys care ? You've forced their hand, you've demanded stuff they > said they didn't want to do and then you've bitched about things they > said they would do. Actually I think they've been quite restrained. I'd > probably have proposed a licence change to make it only work on FreeBSD > and Solaris given that treatment ;) > Our OpenSolaris port isn't done yet.. ;) Oh.. and I hope you won't mind if we break the API in doing so.. *cough* /me hides -- Download Intel® 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, Daniel Stone wrote: > > So you're saying that there's no way to develop any reasonable body of > code for the Linux kernel without committing to keeping your ABI > absolutely rock-solid stable for eternity, no exceptions, ever? I think that's what David ended up saying, but I think he is being _too_ strict. It's not how we've done other things either. We've changed ABI's over time many times. And we've even had complete breakage of old tools (although that is very much reserved for system tools, not regular applications: I think we've been almost religious about "normal" apps not breaking, unless there was some really overriding reason like security that forced us to really remove some interface). But most of the changes have been extending things, leaving the old interfaces around (often as wrappers around the new internal world order, sometimes by effectively having actual duplicated code). And then the old interface is maintained for quite a while (sometimes decades, often years, and generally at least for several kernel versions so that people have time to upgrade, and a distro can generally pick a newer kernel without having to change anything else). Sometimes we've done things that really end up requiring new tools. It's pretty rare, but it does happen. It happens a lot more for "esoteric" things that aren't every-day-in-your-face (I've seen at least _one_ mutter about "sysfs" in this thread ;) and might break something like a temperature sensor, for example. So the machine might _work_ and you could go for days without even noticing, but you might have some very specific functionality missing. Maybe your power meter doesn't work, or maybe you need to upgrade your kernel profiler to get good profiles again. Things like that. I suspect you as an X person know this very well, in fact. X itself has carried along a _lot_ of cruft exactly like this, that you guys have been removing only in the last few years - sometimes after decades of it being there. The whole switch to modern font handling is an obvious example of a _major_ fundamental feature change like that. So in general, what the kernel strives for is that very kind of "the old model will still work - but it might be slow and emulated on top of a new way of dong things, and not get a lot of attention any more". And sometimes, there's really no good way of maintaining two interfaces at the kernel level, and then you have the downstream tools that have to learn to pick either the old or the new one, so that the tool still works regardless. And again, the old code _eventually_ bitrots or gets cleaned up, but what you really really want to avoid is to have a flag-day when you switch from one to the other, and you can't switch between adjacent versions of the kernel. In the 2.4.x/2.6.x split, for example, we did have system tools that needed to be upgraded if you came from a 2.4.x environment. You can still see signs of that in the kernel tree: we have that whole Documentation/Changes file that _still_ remains in our tree, even though it's purely historical. But if you look at that Documentation/Changes file, I don't think there is _any_ flag-day issue except for the removal of "devfs". People _still_ talk about devfs in hushed tones. Everything else is about having to upgrade system tools _before_ upgrading the kernel (iow, they still worked on 2.4.x, but you needed recent enough versions of them to compile and run a 2.6.x kernel). In other words, it wasn't a "flag day" (apart from the already mentioned devfs users, and possibly something else I can't think of). It was an upgrade, yes, and it required some other things to be recent, but you could go back-and-forth between kernels if you had to. (Of course, it's now many years since that, so maybe my rose-colored glasses makes me forget the pain involved. And I obviously personally never made the whole 2.4.x -> 2.6.x jump, since I'd been running the development kernels in between. So maybe I forgot some painful part). Linus -- Download Intel® 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
> Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The > guy who is, as far as I know, effectively in charge of that whole > integration. Yeah, I realize that there are other people (Kyle?) involved, > and maybe Dave isn't as central as I think he is, but I learnt from last > time that the nouveau guys don't seem to care. Ok "screamed about" is perhaps better wording. Why should the Nouveau guys care ? You've forced their hand, you've demanded stuff they said they didn't want to do and then you've bitched about things they said they would do. Actually I think they've been quite restrained. I'd probably have proposed a licence change to make it only work on FreeBSD and Solaris given that treatment ;) > Even if you need to change the interface, I've actually looked at the > patch in question (have you, Alan?), Yes but I read it somewhat differently. Someone who never made a commitment to stability decided to do the logical thing. They deleted all the old broken interfaces, they cleaned up their ioctls numbering and they tided up afterwards. I read it as the action of someone who simply doesnt acknowledge that you have a right to control their development and is continuing to work in the way they intended. You can only see it as malicious if you assume they ever had some reason to keep compatibility or had promised it somewhere. Quite the reverse happened, and they never asked to be upstream in the first place. "But the fact is, at least from my standpoint, I'd really hope that anything I had written would be used in ways I asked people to" - Linus Torvalds, 2004 -- Download Intel® 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, Alan Cox wrote: > > So the watershed moment was _never_ the "Linus merged it". The watershed > > moment was always "Fedora started shipping it". That's when the problems > > with a standard upstream kernel started. > > > > Why is that so hard for people to understand? > > So why are you screaming at the DRM and Nouveau people about the > breakage ? That's the bit I really don't understand. Umm. You _really_ haven't been following, have you? Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The guy who is, as far as I know, effectively in charge of that whole integration. Yeah, I realize that there are other people (Kyle?) involved, and maybe Dave isn't as central as I think he is, but I learnt from last time that the nouveau guys don't seem to care. And I would like to say that yes, Dave really helped me. He got me a working setup again. I thank you, Dave. It means I don't have to revert the thing, and we can hopefully make progress. That said, I do think that the Fedora people _should_ have been the ones to catch this as a problem, and pushed back a bit on the Nouveau people even before it got to me. For all the reasons I've mentioned. Even if you need to change the interface, I've actually looked at the patch in question (have you, Alan?), and I got the very strong feeling that it _could_ have been done without breaking compatibility so completely and utterly, and making it so apparently intentionally hard to have a driver that can handle both the old and the new. IOW, maybe it would have required a new nouveau_drv etc, but with a slightly less hack-and-slash approach, maybe the new one could have supported the old interfaces enough to at least limp along. For example, breaking DRM so that 3D doesn't work, but you still get basic 2D acceleration - that's _way_ more acceptable, and is likely to need a much smaller subset of the whole DRI functionality. It looks like nobody even tried. Linus -- Download Intel® 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: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 5 Mar 2010, Daniel Stone wrote: > > FWIW, Option "ModulePath" in xorg.conf lets you more or less do this; > the usual approach is to install your new server + drivers into a > separate prefix. The thing is, Xorg has - and I think for _very_ good reasons - deprecated using xorg.conf at all. So most people don't even have one (I certainly don't), and wouldn't know how to create one in the first place. And yeah, I used to happily edit timing lines and make up non-standard modes for my monitor, but I have to admit that I never _ever_ want to touch that file ever again. Last time I tried to, it was to set DPI to be something sane, but these days X gets even that right automatically, and no longer does the insane "set DPY by size of the screen" thing any more. And I think all of the reasons xorg.conf is basically being deprecated are valid for this case too. Switching between kernels is - in this case, due to the whole API change - effectively the same as switching the graphics card in the machine, but without even the ability to _name_ the cards and share a xorg.conf for the two cases (not that I think that you could do different ModulePath's per display anyway). So yeah, you could "switch between kernels, start out in init 3, edit xorg.conf appropriately, switch to init 5", but once you start doing that, you might as well just switch a symlink around instead - it's easier. So I don't think xorg.conf is a help. Linus -- Download Intel® 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
> The thing I objected to, in the VERY BEGINNING in this thread, i the fact > that the thing was done in such a way that it's basically impossible to > support the old/new ABI at all! What did you expect them to do. They said when you first forced a merge that they would do this. They have no contract that I am aware of to deliver you compatibility, in fact quite the reverse they said they wouldn't be. Then you attribute to malice what was done as a cleanup by people who've pointedly never to commited to a constant API yet "That commit seems to _on_purpose_ try to avoid at all cost being compatible." Great way to make friends. Alan -- Download Intel® 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, 05 Mar 2010 08:06:26 -0800 (PST) David Miller wrote: > From: Daniel Stone > Date: Fri, 5 Mar 2010 18:04:34 +0200 > > > So you're saying that there's no way to develop any reasonable body of > > code for the Linux kernel without committing to keeping your ABI > > absolutely rock-solid stable for eternity, no exceptions, ever? Cool, > > that worked really well for Xlib. > > read() still works the same way it did 30 years ago last time I > checked. Thats disingenous as read() is a method not an interface. It's also wrong because read() and write() behaviour has changed in various ways and old code broke because of it in subtle ways. Keeping the same method behaviour would have required things like new versions of read() for 64bit files, nonblocking, mandlocks, NFS, networking, etc all of which changed the core read() behaviour. I've yet to see anyone meaningfully argue it was the wrong thing to do. Alan -- Download Intel® 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: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 5 Mar 2010 07:53:46 -0800 (PST) Linus Torvalds wrote: > > > On Fri, 5 Mar 2010, Carlos R. Mafra wrote: > > > > Whereas everytime I wanted to do that with Xorg it was such a pain that > > I want to keep away from that mess. > > Actually, take it from me: Xorg is _pleasant_ to test these days. > > Ok, so that's partly compared to the mess it _used_ to be, but it's really > night and day. The whole build system was so incredibly baroque and heavy > that you really had to understand it deeply if you wanted to do anything > fancy. > > And the non-fancy alternative was to just build the whole thing, which > took _hours_ even on fast machines because the build system overhead was > near-infinite (I dunno, maybe parallel builds could be made to work, but > it took more brain-power than I could ever put into it). > > These days, there's a few dependencies you need to know about (I do agree > that from a user perspective the thing might have been made a bit _too_ > modular) but they are generally fairly trivial, and there are scripts to > download all the drivers and misc utilities needed. Just FYI for those following this thread; testing the server and 3D drivers really isn't too much trouble these days, you can even install everything into a separate path (I usually choose /opt-gfx-test); you just need to build libdrm, mesa, xserver and your video driver (along with an input driver or tw) in that order. Then just startx -- /opt/gfx-test/bin/Xorg and put something reasonable in .xinitrc. Full instructions at http://wiki.x.org/wiki/Development/BuildingX. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel® 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
> I think you need to be clearer about that. Your distribution packaging > may not support that out of the box. There are a variety of ways to do > almsot all of this including having entire parallel X installs for > development work. Sure, but each user must manually find out how to setup that, and create and test the setup himself (or happen to use a distribution that somehow eases that, if any exist). I think that Linus has a good point in saying that this should be provided by default. And ideally not just by the distribution, but upstream, so that people wanting to test bleeding edge DRM drivers (not necessarily just nouveau) can do so more easily, and beable to go back to their working setup by rebooting should something go wrong. > The fundamental problem you can't solve by versioning though is the exact > one here. A new kernel that requires version X of a driver won't help if > the newest version you have is X - 1. Yes, but the fact that you can't have both X - 1 and X at the same time makes it worse, since for instance bisecting won't just work. > Yeah perhaps Fedora should have pushed an update that was smart enough to > handle the Nouveau old/new ABI before the patch went upstream. Hindsight > is an exact science. Well, yes, but it can still be implemented in time for the next distribution releases and the lesson can be learned for similar future situations. -- Download Intel® 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
> So the watershed moment was _never_ the "Linus merged it". The watershed > moment was always "Fedora started shipping it". That's when the problems > with a standard upstream kernel started. > > Why is that so hard for people to understand? So why are you screaming at the DRM and Nouveau people about the breakage ? That's the bit I really don't understand. Alan -- Download Intel® 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, Alan Cox wrote: > > Yeah perhaps Fedora should have pushed an update that was smart enough to > handle the Nouveau old/new ABI before the patch went upstream. Hindsight > is an exact science. Alan - it seems you're missing the whole point. The thing I objected to, in the VERY BEGINNING in this thread, i the fact that the thing was done in such a way that it's basically impossible to support the old/new ABI at all! Let me quote that second email: "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." So it's not a "before the patch went upstream" issue. The same issue exists _after_ the patch went upstream. The way this was done, it's apparently basically impossible for the Fedora people to push out packaged that support both the old and the new kernel. Alan, if this had been done in a way that allowed that whole old/new ABI that you mention to work, I wouldn't have been complaining so much! In other words - I've not been complaining about updating the ABI. I've been complaining about doing it in such a way that it's near impossible to go back-and-forth, because the very thing you suggest was made way way harder than it should be. Linus -- Download Intel® 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 08:44:07 +0100 Ingo Molnar wrote: > 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. This is a very good point, and something we've been wrestling with in the gfx community. Awhile back we separated the X drivers from the X core; I feel this was a mistake for the reasons you mention above. It's just plain harder to fix issues when you have to rev the ABI with every change, make sure both the old/new and new/old combinations work, and generally improve things like we do inside of Linux. > [*] 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. No we don't need to merge them fortunately. With GEM and KMS we've pushed two major bits of functionality into the kernel; bits that were badly split between all portions of the stack before. With EGL, we can push a lot of what X did into Mesa. There are even some projects to make a very thin X driver or separate display server sit directly on top of Mesa + EGL, unifying things further. So I really think things are getting better here, not worse (the nouveau issue here aside). -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel® 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:03 -0800, Linus Torvalds wrote: > On Thu, 4 Mar 2010, Adam Jackson wrote: > > On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: > > > 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). Read it more strongly: drop nouveau from your tree entirely. Don't give me any "not a solution" nonsense about that. The problem is entirely that your expectations for interface stability [1] in your tree do not match nouveau's development model and will not for the forseeable future. Yes, they should htfu and version interfaces like real men. But they're not going to, so either enforce your rule or don't. [1] - apparently ignorable when it's inconvenient, but let's not turn this into a sysfs argument. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel® 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, Alan Cox wrote: > > You can't unleash something like this on a userbase of this magnitude > > and then throw your hands up in the air and say "I'm not willing to > > support this in a reasonable way." > > Not to belabour the obvious - they didn't. Linus ordered them to merge it. Alan, you're ignoring reality. This problem existed *before* nouveau was merged. In fact, it was *worse* back then. How hard is that to understand? And yes, I do actually know. Because I used nouveau for a year before it was merged. You had to use a different version of drm too, so you couldn't even just compile the nouveau tree and install just the nouveau driver (and keep the other drivers from the main tree). So the watershed moment was _never_ the "Linus merged it". The watershed moment was always "Fedora started shipping it". That's when the problems with a standard upstream kernel started. Why is that so hard for people to understand? Linus -- Download Intel® 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: Making Xorg easier to test (was Re: [git pull] drm request 3)
Hi, On Fri, Mar 05, 2010 at 07:53:46AM -0800, Linus Torvalds wrote: > These days, there's a few dependencies you need to know about (I do agree > that from a user perspective the thing might have been made a bit _too_ > modular) Indeed, no argument here. > That said, the _one_ thing I really wish could be done would be to make it > easier to install things side-by-side - and with the modularization, you > really do want to do it module-by-module. One of the things that makes it > so easy to test the kernel is that when you install one kernel, that > doesn't affect the others, and you can go back-and-forth in testing. > That's really important, because it makes testing trivial and non-scary > even in the presense of issues that makes the new version unusable. FWIW, Option "ModulePath" in xorg.conf lets you more or less do this; the usual approach is to install your new server + drivers into a separate prefix. Cheers, Daniel pgpnHb05h5vaf.pgp Description: PGP signature -- Download Intel® 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 16:56:10 +0100 Luca Barbieri wrote: > It seems to me that Linus' technical argument is indeed being mostly ignored. > > While breaking the ABI is unfortunate, the real problem that Linus > complained about is that you can't install several userspace versions > side-by-side. I think you need to be clearer about that. Your distribution packaging may not support that out of the box. There are a variety of ways to do almsot all of this including having entire parallel X installs for development work. All the X builds are modular, all the modular builds support --prefix= with their autogen script. ld.so supports LD_LIBRARY_PATH and the shells support PATH variables. You can replace all or almost any part of X quite easily. There is also a mechanism for versioning within DRM for a lot of stuff, and drivers use flags to make it work nicely except for devel code (which is what Nouveau is) The fundamental problem you can't solve by versioning though is the exact one here. A new kernel that requires version X of a driver won't help if the newest version you have is X - 1. Yeah perhaps Fedora should have pushed an update that was smart enough to handle the Nouveau old/new ABI before the patch went upstream. Hindsight is an exact science. Alan -- Download Intel® 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, David Miller wrote:
>
> In fact, I argue that the moment nouveau went into Fedora and
> was turned on by default, the interfaces needed to be frozen.
Now, I agree that that would have been the optimal setup from a testing an
user standpoint, but I think it's a bit too strong.
Things don't need to be "frozen", but flag-days need to be avoided. The
problem with flag-days is not so much that they need new support code:
downloading a new version of something like X is not a huge issue. But
flag-days work both ways: it's not just that you have to download a new
version, it's that you can't go _back_ either - not even a little bit.
For example, I can now test my new kernel, but if it turns out that there
are problems with it, I'm now officially screwed. I can't go back and rely
on even the stable distro kernel, like I'm used to ("ok, that _really_
didn't work, but happily I didn't remove the distro kernel, so I'll just
reboot with that"). And I certainly can't bisect without major problems.
And Fedora can't install the new libraries, because they won't work with
their own old kernels either. So it effectively causes a version freeze:
it looks like F12 will simply _never_ be able to support a 2.6.34 kernel,
because if they do that, then everybody who gets the new packages (and has
a nvidia graphics card) will now be stuck.
So flag-days really are bad. They're bad for users, they're bad for
distributions, and they're eventually bad for developers too because now
they lose a lot of every-day testing. Some day, F13 will come out, and the
_only_ testing all the new code ever got was the (relatively small)
rawhide community, and the kernel crazies who did things manually.
But even if you can't guarantee backwards compatibility, if you avoid the
flag-day, and can have a new version of the environment that can handle
both the old and the new model, you _could_ install that on F12 (before
switching kernels), and not be in that effective version-freeze.
Yeah, you'll still have a dependency chain, but it will be a one-way one,
so you're not stuck. As long as you have the newest vesion of whatever
libraries or support, you can go back-and-forth and test development
systems.
And we do that for the kernel in many other respects. We require that you
have a "recent enough" compiler, for example. So there are already lots of
those one-way dependencies where we're not infinitely backwards compatible
with user space, but we've been pretty good at not having flag-days.
Linus
--
Download Intel® 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: Making Xorg easier to test
On Fri, Mar 05, 2010 at 07:49:32AM -0800, David Miller wrote: > From: Daniel Stone > > I understand that you guys are upset about this, so maybe you'd like to > > donate, say, 10% of your developer base to help out? That'd be pretty > > ace. > > You have to support less than %10 of the amount of hardware we have to > support. With a great deal less than 10% of the number of developers. pgpdiV1fa8kSW.pgp Description: PGP signature -- Download Intel® 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
From: Daniel Stone Date: Fri, 5 Mar 2010 18:04:34 +0200 > So you're saying that there's no way to develop any reasonable body of > code for the Linux kernel without committing to keeping your ABI > absolutely rock-solid stable for eternity, no exceptions, ever? Cool, > that worked really well for Xlib. read() still works the same way it did 30 years ago last time I checked. -- Download Intel® 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
From: Alan Cox Date: Fri, 5 Mar 2010 16:02:17 + >> You can't unleash something like this on a userbase of this magnitude >> and then throw your hands up in the air and say "I'm not willing to >> support this in a reasonable way." > > Not to belabour the obvious - they didn't. Linus ordered them to merge it. And I'm arguing not merging it upstream would be like saying the same thing. >> We're better than that. > > If you consider the problem is with the Fedora kernel team decision to > merge it into Fedora in the first place For the second time Alan, I don't. I think Fedora should have merged it. I think it should be upstream. And I think the API bustage needs to be avoided. -- Download Intel® 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 05, 2010 at 07:48:35AM -0800, David Miller wrote: > From: Daniel Stone > > On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: > >> In fact, I argue that the moment nouveau went into Fedora and > >> was turned on by default, the interfaces needed to be frozen. > > > > That's a matter for the Fedora kernel team; for better or worse, they > > made the choices they did, which included going through all the relevant > > pain to support this. They didn't consider it suitable for upstream > > because they didn't think everyone else should be forced to endure that > > pain. > > By not merging it upstream the pain is larger not smaller. > > It's enabled by default, so you therefore can't test upstream kernels > by default. 'That's a matter for the Fedora kernel team'. > And as I showed already, even if you jump through the hoops to make it > work (building noveau from out of tree in the upstream kernel) you'll > end up getting screwed when the API changes anyways. So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for Xlib. > Using VESA or whatever else you've suggested is just not a reasonable > alternative. > > You can't unleash something like this on a userbase of this magnitude > and then throw your hands up in the air and say "I'm not willing to > support this in a reasonable way." > > We're better than that. Your opinion on what constitutes reasonable support is not universal, absolute truth. pgpCl9WgXtapb.pgp Description: PGP signature -- Download Intel® 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: Making Xorg easier to test
On Fri, 05 Mar 2010 07:49:32 -0800 (PST) David Miller wrote: > From: Daniel Stone > Date: Fri, 5 Mar 2010 17:41:43 +0200 > > > I understand that you guys are upset about this, so maybe you'd like to > > donate, say, 10% of your developer base to help out? That'd be pretty > > ace. > > You have to support less than %10 of the amount of hardware we have to > support. If we believe the changelogs including X.org userspace then they also have a good deal less than 10% of the contributors. Alan -- Download Intel® 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
> You can't unleash something like this on a userbase of this magnitude > and then throw your hands up in the air and say "I'm not willing to > support this in a reasonable way." Not to belabour the obvious - they didn't. Linus ordered them to merge it. > We're better than that. If you consider the problem is with the Fedora kernel team decision to merge it into Fedora in the first place, perhaps you should have an internal Red Hat discussion about it with the people who made that decision - who I suspect see it differently. Either way the Nouveau developers don't control Fedora packaging policy, in fact the GPL licence specially ensures the control is not theirs. Alan -- Download Intel® 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
It seems to me that Linus' technical argument is indeed being mostly ignored. While breaking the ABI is unfortunate, the real problem that Linus complained about is that you can't install several userspace versions side-by-side. This means that if you install your new kernel and userspace, reboot, and find the new kernel doesn't work for some reason, you can't just go back to the old kernel and have working X, because you just replaced userspace with a version that no longer works with the kernel that worked correctly. This is even worse for distributions that want to upgrade the kernel, because each kernel package would need to have a Depends on the exact userspace package version. Thus, the package manager would remove the older kernel when the new one is installed (since they depend on different versions of the same userspace package). If the new kernel somehow doesn't work, the user is totally screwed and must reboot from a live CD. As pointed out, in this case, it is relatively easy to solve by adding a version number to libdrm-nouveau, the X driver and the DRI drivers. X will then have to load the correct driver and give Mesa the DRI driver name with the correct version appended. It may be a good idea to do this before the new nouveau ABI gets shipped in released distributions, and with a generic mechanisms that can be used by all X/drm drivers. Workarounds are possible, such as replacing /usr/bin/X with a script that loads the correct version, or using X over /dev/fb0 (which should work fine with any DRM KMS driver, and any non-DRI framebuffer), but they shouldn't be needed. BTW, the nVidia proprietary driver also ties the kernel and userspace version in this way, and is actually worse because it replaces the X libglx.so, breaking all other drivers. -- Download Intel® 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: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 5 Mar 2010, Carlos R. Mafra wrote: > > Whereas everytime I wanted to do that with Xorg it was such a pain that > I want to keep away from that mess. Actually, take it from me: Xorg is _pleasant_ to test these days. Ok, so that's partly compared to the mess it _used_ to be, but it's really night and day. The whole build system was so incredibly baroque and heavy that you really had to understand it deeply if you wanted to do anything fancy. And the non-fancy alternative was to just build the whole thing, which took _hours_ even on fast machines because the build system overhead was near-infinite (I dunno, maybe parallel builds could be made to work, but it took more brain-power than I could ever put into it). These days, there's a few dependencies you need to know about (I do agree that from a user perspective the thing might have been made a bit _too_ modular) but they are generally fairly trivial, and there are scripts to download all the drivers and misc utilities needed. And the modularization often works: you can often (but by no means always; it does require that the other parts are "close enough" and that there haven't been any major changes) just have the source code to the one driver you care about, and recompile and install just that _single_ driver. I've done it. It's becautiful when it works. And it's a major pain when you notice it didn't work, and you needed to get the whole server and libdrm trees after all, and now you're not replacing single files any more and have little idea what it will stomp on in your distro. So it really is very convenient when it works. And X doesn't have thousands of drivers like the kernel (maybe 10-15 that people care about at all, and about three or four that actually really matter), and there are seldom huge changes that affect them all, so the modularization doesn't turn totally crazy. So I can see where the Xorg people really like their new modular world. It does work, it's _sooo_ much better than the mess it used to be, and the problems are fairly manageable when they do happen. The modular approach really works very well when there aren't lots of interactions between the modules, and when the modules are few enough that it isn't a total disaster (imagine doing a change that requires changes to all drivers in Xorg, vs doing a change that requires changes to all drivers in the kernel - the modular approach simply wouldn't work for the latter case, because you'd spend all your time just chasing down external users). That said, the _one_ thing I really wish could be done would be to make it easier to install things side-by-side - and with the modularization, you really do want to do it module-by-module. One of the things that makes it so easy to test the kernel is that when you install one kernel, that doesn't affect the others, and you can go back-and-forth in testing. That's really important, because it makes testing trivial and non-scary even in the presense of issues that makes the new version unusable. Linus -- Download Intel® 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: Making Xorg easier to test
From: Daniel Stone Date: Fri, 5 Mar 2010 17:41:43 +0200 > I understand that you guys are upset about this, so maybe you'd like to > donate, say, 10% of your developer base to help out? That'd be pretty > ace. You have to support less than %10 of the amount of hardware we have to support. -- Download Intel® 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
From: Daniel Stone Date: Fri, 5 Mar 2010 17:40:09 +0200 > On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: >> In fact, I argue that the moment nouveau went into Fedora and >> was turned on by default, the interfaces needed to be frozen. > > That's a matter for the Fedora kernel team; for better or worse, they > made the choices they did, which included going through all the relevant > pain to support this. They didn't consider it suitable for upstream > because they didn't think everyone else should be forced to endure that > pain. By not merging it upstream the pain is larger not smaller. It's enabled by default, so you therefore can't test upstream kernels by default. And as I showed already, even if you jump through the hoops to make it work (building noveau from out of tree in the upstream kernel) you'll end up getting screwed when the API changes anyways. Using VESA or whatever else you've suggested is just not a reasonable alternative. You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say "I'm not willing to support this in a reasonable way." We're better than that. -- Download Intel® 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, 2010-03-05 at 06:24 -0500, Jeff Garzik wrote: > On 03/04/2010 05:59 PM, Adam Jackson wrote: > > 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. > > Thanks. Can this be put into F12 too? Sure, why not. > > - 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. > > The latter... would modeset in grub interfere, perhaps? It's not going to do anything if you didn't build a KMS driver. It's just a kcmdline option like any other; if there's no module to honor it, then it doesn't do anything. grub doesn't have any particular KMS awareness. I'm really going to have to see an X log and dmesg from the failure mode when actually using nv to diagnose this any further. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel® 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 05, 2010 at 06:37:18AM -0800, David Miller wrote: > If it effects such a large number of people, which this noveau thing > does, it's entirely relevant to everyone. And the way it's breaking > and making kernel development difficult for so many people matters to > us. Maybe the lesson to be learned from all this is, 'if the developers don't want something merged because they're not ready and forsee huge problems in the future, actually listen to them instead of blindly ramming it in regardless'? But maybe that's just me. Cheers, Daniel pgp6wYP1dGLlT.pgp Description: PGP signature -- Download Intel® 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: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, Mar 05, 2010 at 10:22:27AM -0500, Matt Turner wrote: > On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra wrote: > > Why can't there be a 'Linus Torvalds' for Xorg accepting patches from > > various > > maintainers and keeping the whole thing tied up? Why can't it mimic the > > 'make menuconfig' way of selecting what to compile to have the guarantee > > that > > the whole thing will simply work nicely together? > > You must not follow X development at all. His name is Keith Packard. Except that if you look at X lately, you'll realise that we do not have the resources to even come close to being able to do this properly. We struggle to support what we have already today, and we've still been hoping to create a real API, instead of the sad joke that is /usr/include/xorg/*.h, for the last few years. But we don't have enough people (or at least enough people who aren't busy with the other parts of their day jobs, or kids, or burnout, or whatever) to do it. I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. Cheers, Daniel pgpB62OHx1v5N.pgp Description: PGP signature -- Download Intel® 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
Hi, On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: > From: Daniel Stone > > On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: > >> If it effects such a large number of people, which this noveau thing > >> does, it's entirely relevant to everyone. And the way it's breaking > >> and making kernel development difficult for so many people matters to > >> us. > > > > Maybe the lesson to be learned from all this is, 'if the developers > > don't want something merged because they're not ready and forsee huge > > problems in the future, actually listen to them instead of blindly > > ramming it in regardless'? But maybe that's just me. > > That's doesn't work, and it never will. > > First of all, if we didn't merge the driver Fedora users wouldn't be > able to test the upstream kernel at all. > > And if you think things through, there is one and onle one set of > actions that would have made things work properly. > > And that's merge the driver upstream and not break user visible APIs. Ah, argument by assertion. That's my most favourite thing to deal with on a Friday evening. Wait, did I say 'most'? I meant least. > In fact, I argue that the moment nouveau went into Fedora and > was turned on by default, the interfaces needed to be frozen. That's a matter for the Fedora kernel team; for better or worse, they made the choices they did, which included going through all the relevant pain to support this. They didn't consider it suitable for upstream because they didn't think everyone else should be forced to endure that pain. Now it's upstream and everyone's being forced to deal with it. Great. > Consider if it didn't go upstream and I want to do upstream > kernel development, ok so I patch the noveau-of-the-moment into > my upstream tree. > > Six months and 10 DRM library updates later I go back and try to boot > that kernel. And it's not going to work. nouveau isn't going to work, no. vesa and nv remain unaffected; it's not like it's some kind of catastrophic failure whereby booting it eats your disk and gropes your sister-in-law. > So if the user visible APIs are changed in any set of situations > (upstream merged, not upstream merged, etc.) things can end up > breaking. Correct! > Ergo, you simply can't sanely do it at all. You have to have > a compatability story when you change these things. You cannot sanely do it at all in an upstream kernel, no. > Personally I wouldn't have ever committed to that "user visible APIs > can break cause it's in -stable." Because that's complete garbage. I guess you mean staging here; either way, that's a matter for you guys to deal with. I guess the upshot here is 'if you merge something against the developers' wishes by screaming at them until they comply, they repeatedly tell you that it's not API-stable, you merge it, and it changes API, then joke's on you'. If the result of this ridiculous mess is that anything merged to staging is never allowed to change userspace ABI ever, then great. As I said, it's really not my problem. Either way, fuck it, it's Friday. To the pub. Cheers, Daniel pgpl2HOShne3z.pgp Description: PGP signature -- Download Intel® 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
> Personally I wouldn't have ever committed to that "user visible APIs > can break cause it's in -stable." Because that's complete garbage Staging has to have the no API rules. Read some of the stuff in there to understand why or apply about 30 seconds of thought to what it would mean to you. There are staging drivers using old wireless layers. If you say that no API can be broken from staging then you will have to put the old wireless compatibility into your network code forever. Does that fill you with joy, light and happiness ? Whether nouveau should ever have gone into staging is a different question. I don't personally think its all as clear cut as it might seem. Quite a few distributions ship whacky wireless drivers with old API's as the choice is that or nothing. They manage the user expectation and they deal with the drivers moving from one wireless stack to the other and mostly successfully hide it in userspace. The differences here appear to be - Having no video is more annoying than having no wireless - Userspace failed to hide it (so maybe its not a kernel ABI problem but a failure to anticipate the need for versioned libdrm and the importance in some eyes of supporting the kernel.org kernel - which like it or not is a corner case for distro *users*). - The box it broke happened to belong to Linus but that doesn't really require tantrums or fingerpointing to fix, particularly when its only the combination of a set of decisions and misunderstandings by Linus, Fedora and the Nouveau developers together that combined to create the mess. Alan -- Download Intel® 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] fence errors with rs785 and kernel 2.6.33
http://bugs.freedesktop.org/show_bug.cgi?id=26887 --- Comment #4 from Alex Deucher 2010-03-05 07:37:28 PST --- (In reply to comment #3) > yes - could this be sideport related? > Not likely. -- 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® 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 #21 from Marc 2010-03-05 07:34:18 PST --- Rafał, this seems to work. radeon_pm_info shows proper switching. Also I get some more frames in glxgears (538->588) so I guess the gpu really runs faster now. However, the "not in vbl for pm change 00020002 at entry/exit" is still there. Don't know if this is important. Thanks! -- 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® 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
From: Daniel Stone Date: Fri, 5 Mar 2010 17:17:54 +0200 > On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: >> If it effects such a large number of people, which this noveau thing >> does, it's entirely relevant to everyone. And the way it's breaking >> and making kernel development difficult for so many people matters to >> us. > > Maybe the lesson to be learned from all this is, 'if the developers > don't want something merged because they're not ready and forsee huge > problems in the future, actually listen to them instead of blindly > ramming it in regardless'? But maybe that's just me. That's doesn't work, and it never will. First of all, if we didn't merge the driver Fedora users wouldn't be able to test the upstream kernel at all. And if you think things through, there is one and onle one set of actions that would have made things work properly. And that's merge the driver upstream and not break user visible APIs. In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. Consider if it didn't go upstream and I want to do upstream kernel development, ok so I patch the noveau-of-the-moment into my upstream tree. Six months and 10 DRM library updates later I go back and try to boot that kernel. And it's not going to work. So if the user visible APIs are changed in any set of situations (upstream merged, not upstream merged, etc.) things can end up breaking. Ergo, you simply can't sanely do it at all. You have to have a compatability story when you change these things. Personally I wouldn't have ever committed to that "user visible APIs can break cause it's in -stable." Because that's complete garbage. -- Download Intel® 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: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra wrote: > Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various > maintainers and keeping the whole thing tied up? Why can't it mimic the > 'make menuconfig' way of selecting what to compile to have the guarantee that > the whole thing will simply work nicely together? You must not follow X development at all. His name is Keith Packard. Matt Turner -- Download Intel® 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, 2010-03-05 at 06:37 -0800, David Miller wrote: > From: Alan Cox > Date: Fri, 5 Mar 2010 12:38:34 + > > >> The conclusion is crystal clear, breaking an ABI via a "flag day" > >> cleanup/feature/etc is: > > > > Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor > > junk that is in there being cleaned up it would be *insane* to keep their > > old APIs > > > > See there's a bigger offence than breaking an ABI - its called not RTFM. > > All of this RTFM and what directory the noveau driver is sitting in is > entirely irrelevant Alan. > > If it effects such a large number of people, which this noveau thing > does, it's entirely relevant to everyone. And the way it's breaking > and making kernel development difficult for so many people matters to > us. > > It's about the tester base, and this breakage shrinks the tester base > considerably. > > Or do you want the kernel tested by less people? On the bright side, all this hubbub sends a very positive message to the noveau development crew. Folks, your work is important. I'd be proud as a peacock :) -Mike -- Download Intel® 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, "C. Bergström" wrote: > > staging != stable This really is being repeated, over and over. But it's irrelevant. It's irrelevant because it's just a bad _excuse_. That driver is used in production environments. That's _reality_. The whole "staging" thing is nothing more than a meaningless word. And no, "staging" wasn't why it was merged. The reason it was merged was that very same "reality". So every time somebody mentions staging as an argument, he's missing the whole effing point. It also misses the point that the issues I've tried to bring up (bisection, testability) are real _technical_ arguments. Again, waving that "staging" flag is just stupid. It has nothing to do with the technical arguments, or with the reality of the situation. In other words, it's not just an excuse, it's a _meaningless_ excuse. It's a red herring. It's irrelevant to the issue. Linus -- Download Intel® 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
From: Alan Cox Date: Fri, 5 Mar 2010 15:09:34 + > I think you miss a bigger picture ? > > If Fedora hadn't merged it then it wouldn't have gotten to the state of > usability it had. If Fedora hadn't merged it then several hundred > thousand users wouldn't have had useful working machines. I think Fedora were right to merge it, and I think it was proper to merge it into the upstream kernel. But I also think the large size of that userbase should have been respected by "doing the right thing" here, and that means not making it so hard for Fedora users to use upstream kernels out of the box. Making the "sandbox" claim cuts both ways Alan. -- Download Intel® 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
> If it effects such a large number of people, which this noveau thing > does, it's entirely relevant to everyone. And the way it's breaking > and making kernel development difficult for so many people matters to > us. > > It's about the tester base, and this breakage shrinks the tester base > considerably. > > Or do you want the kernel tested by less people? I think you miss a bigger picture ? If Fedora hadn't merged it then it wouldn't have gotten to the state of usability it had. If Fedora hadn't merged it then several hundred thousand users wouldn't have had useful working machines. So - do you want Linux used by a lot less people, and to have no Nvidia driver ? See - its all about viewpoints. Do you think screaming at people who did no wrong increases the kernel developer and testing base ? No I thought not. To be honest the big thing I object to here is certain people who should know better behaving like small children. Not just in the sense of throwing their toys around because mummy didn't buy them the right sweetie but in not thinking about how other people see the problem and their actions. - Fedora merged the stuff to make it work and to improve life for lots of users. Good intent, rational logical behaviour - Linus asked for it to be merged and was warned about the ABI. He did that for good, sound reasons. - The developers accepted the merge to staging so they could fix the ABI later, they made that clear - again all good sound intentions - The ABI change and clean up was done - again good sound intentions, rational behaviour - Linus then threw a tantrum. He's right there are issues about how user migration should be handled but he didn't need to go screaming at the DRM people (not their fault), Fedora (who had good sensible goals in what they did) or the Nouveau people (who told him what was going on well in advance and did exactly what was asked of them before) Firstly he's being hypocritical (he keeps saying he doesn't want to control distributions, he even refused to allow ext2 to be merged *until* Red Hat shipped it), he was told clearly, and staging is for unfixed ABIs. Secondly he's shouting at people who all did a right thing, which only produces bad feelings. All that was needed was a "Hey guys, I know its in staging but this is going to be a problem, can we either fix back compatibility or have some kind of migration policy and the tools so I can test it - otherwise I can't merge this" No blaming, no tantrums, no judgemental comments from a single viewpoint. A collection of good intentions produced a problem. It happens all the time, screaming and blaming may be how politicians sometimes behave but we can surely do better ? Alan -- Download Intel® 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
From: Alan Cox Date: Fri, 5 Mar 2010 12:38:34 + >> The conclusion is crystal clear, breaking an ABI via a "flag day" >> cleanup/feature/etc is: > > Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor > junk that is in there being cleaned up it would be *insane* to keep their > old APIs > > See there's a bigger offence than breaking an ABI - its called not RTFM. All of this RTFM and what directory the noveau driver is sitting in is entirely irrelevant Alan. If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. It's about the tester base, and this breakage shrinks the tester base considerably. Or do you want the kernel tested by less people? -- Download Intel® 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
> Why does the X community not understand simple library versioning? Why does Linus Torvalds not understand the Kconfig of his own staging directory ? Alan -- Download Intel® 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, 04 Mar 2010 14:32:02 -0500 Jeff Garzik wrote: > 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. Why ? Fedora isn't special, Fedora is just a distribution that uses the Linux kernel. If Fedora turns on staging drivers then Fedora has to accept that stuff breaks and manage that expectation with its users. Staging is not and has not been API stable. If staging is going to be API stable then it it useless and may as well be deleted. In this case Linus is just a random Fedora user having a distro problem. I don't even see what it has to do with linux-kernel. The libdrm problem and difficulty using Fedora libdrm with current upstream kernel is a Fedora problem not a kernel problem. The kernel staging tree is unstable for API. Whether thats the Nouveau guys breaking Fedora, submissions to network drivers breaking/removing bogus APIs in stuff being cleaned up - whatever then thats how the cookie crumbles. DRM has just made it all horribly more visible because the libdrm/kernel stuff has such a complex and closely tied interface. Serious discussion point perhaps should be: is the libdrm so close to the kernel it ought to be in the same git tree ? Alternatively does it need to be easier to have multiple Nouveau libdrms autoselected according to the kernel side versioning. ELF library versioning is not rocket science and both the old and new libraries exist and can be installed so all the bits are present except for the wrapper to load the right sublibrary yes ? Alan -- Download Intel® 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
> 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 stop and think for a minute instead. Maybe a timeline would help Nouveau development starts People ship highly experimental stuff for testers Code gets to the "works but really needs a clean up point" Linus demands it is merged Linus gets it merged as staging Developers start doing the cleanup Linus throws a tantrum because they did the cleanup after merge *YOU* forced the early merge (rightly or wrongly) *YOU* effectively created the API break problem So blaming other people is quite out of order. Alan -- Download Intel® 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 05, 2010 at 08:44:07AM +0100, Ingo Molnar wrote: > > 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. Tying kernel, libdrm, X and mesa together 1-1 is not going to help anybody. When thinking along the same line of your reasoning, the answer is unifying graphics driver stacks, which requires increased modularization (in libdrm and mesa): one big abstract project. All of X.org, libdrm, drm, mesa/dri, mesa/gallium, all have relatively stable interfaces as they are supposed to support multiple (from 3 (libdrm) to ~50 (Xorg)) drivers. It's driver internal interfaces that are highly volatile, as it is easy to adjust all parts inside the same graphics driver stack, especially since the same developers know all these parts and it supports the same hw. On top, graphics driver are special, they are as complex and diverse as the hardware. So, graphics driver stacks can currently have up to 7-8 pieces spread everywhere: kernel drm driver, firmware, libdrm driver, Xorg driver, 2 mesa drivers, 1-2 media acceleration libraries. All spreading inherently unstable interfaces everywhere. Graphics drivers will always be complex, and buggy and unstable, but we should try to encapsulate some of that mess in a way that makes sense. I had a talk on FOSDEM about this which was very "warmly" received by some; the slides are here http://www.phoronix.com/scan.php?page=article&item=fosdem_2010_unification&num=1 Luc Verhaegen. -- Download Intel® 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: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 05 Mar 2010 11:00:30 +0100, "Carlos R. Mafra" said: > Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various > maintainers and keeping the whole thing tied up? Why can't it mimic the > 'make menuconfig' way of selecting what to compile to have the guarantee that > the whole thing will simply work nicely together? Feel free to do so. Note that you'll hit 2 problems: 1) In the kernel, the sysadmin can almost always get away with saying "I have no XYZ devices" or "I only have ext4 filesystems" or similar choices, and have the resulting kernel still support basically all the syscalls (unless you start going into CONFIG_EMBEDDED and doing some *major* surgury). Over on the X side of the fence, there aren't as many options that don't involve dropping major chunks of the functionality. You *sure* that nothing on your system depends on the XRandR extension? ;) 2) Lately, the X server is *already* highly modular and different components built from different source trees. Note that the base X server is only about half the size of the kernel RPM - there really isn't much left to trim out of the base server anymore. ncftp ...velopment/source/SRPMS > dir kern* xorg* -rw-r--r--1 263 263 66965350 Feb 26 18:03 kernel-2.6.34-0.4.rc0.git2.fc14.src.rpm -rw-r--r--1 263 26344300 Feb 27 01:39 xorg-sgml-doctools-1.1.1-4.fc12.src.rpm -rw-r--r--2 263 263 2229508 Feb 11 02:23 xorg-x11-apps-7.4-10.fc13.src.rpm -rw-r--r--1 263 263 8250097 Feb 27 00:06 xorg-x11-docs-1.3-6.fc12.src.rpm -rw-r--r--1 263 263 9718 Feb 27 03:27 xorg-x11-drivers-7.3-13.fc12.src.rpm -rw-r--r--2 263 263 263291 Feb 5 21:40 xorg-x11-drv-acecad-1.4.0-3.fc13.src.rpm -rw-r--r--2 263 263 271426 Feb 5 23:03 xorg-x11-drv-aiptek-1.3.0-3.fc13.src.rpm -rw-r--r--1 263 263 293991 Feb 27 01:02 xorg-x11-drv-apm-1.2.2-1.fc12.src.rpm -rw-r--r--2 263 263 247603 Feb 5 19:49 xorg-x11-drv-ark-0.7.2-2.fc13.src.rpm -rw-r--r--1 263 263 273849 Feb 26 20:22 xorg-x11-drv-ast-0.89.9-1.fc12.src.rpm -rw-r--r--1 263 263 475771 Feb 19 00:50 xorg-x11-drv-ati-6.13.0-0.23.20100219gite68d3a389.fc14.src.rpm -rw-r--r--1 263 263 354400 Feb 27 01:17 xorg-x11-drv-chips-1.2.2-1.fc12.src.rpm -rw-r--r--2 263 263 296790 Feb 5 16:10 xorg-x11-drv-cirrus-1.3.2-2.fc13.src.rpm -rw-r--r--2 263 263 257700 Feb 5 19:48 xorg-x11-drv-dummy-0.3.3-2.fc13.src.rpm -rw-r--r--2 263 263 260227 Feb 5 16:26 xorg-x11-drv-elographics-1.2.3-6.fc13.src.rpm -rw-r--r--2 263 263 537577 Feb 5 21:59 xorg-x11-drv-evdev-2.3.99-2.20100108.fc13.src.rpm -rw-r--r--2 263 263 254313 Feb 9 13:19 xorg-x11-drv-fbdev-0.4.1-3.fc13.src.rpm -rw-r--r--1 263 263 252387 Feb 17 05:13 xorg-x11-drv-fpit-1.3.0-8.fc14.src.rpm -rw-r--r--2 263 263 608480 Feb 5 23:07 xorg-x11-drv-geode-2.11.4.1-2.fc13.src.rpm -rw-r--r--2 263 263 361698 Feb 5 21:40 xorg-x11-drv-glint-1.2.4-2.fc13.src.rpm -rw-r--r--2 263 263 244962 Feb 9 13:48 xorg-x11-drv-hyperpen-1.3.0-4.fc13.src.rpm -rw-r--r--2 263 263 289677 Feb 5 22:38 xorg-x11-drv-i128-1.3.3-2.fc13.src.rpm -rw-r--r--2 263 263 281904 Feb 5 20:33 xorg-x11-drv-i740-1.3.2-2.fc13.src.rpm -rw-r--r--1 263 263 978993 Feb 12 07:15 xorg-x11-drv-intel-2.10.0-4.fc13.src.rpm -rw-r--r--2 263 263 305926 Feb 5 19:26 xorg-x11-drv-ivtv-1.1.1-1.fc13.src.rpm -rw-r--r--2 263 263 296974 Feb 5 19:22 xorg-x11-drv-keyboard-1.4.0-4.fc13.src.rpm -rw-r--r--2 263 263 492204 Feb 5 20:02 xorg-x11-drv-mach64-6.8.2-2.fc13.src.rpm -rw-r--r--2 263 263 427579 Feb 5 20:39 xorg-x11-drv-mga-1.4.11-2.fc13.src.rpm -rw-r--r--2 263 263 318263 Feb 9 13:52 xorg-x11-drv-mouse-1.5.0-4.fc13.src.rpm -rw-r--r--2 263 263 254590 Feb 5 20:17 xorg-x11-drv-mutouch-1.2.1-6.fc13.src.rpm -rw-r--r--2 263 263 290495 Feb 5 22:02 xorg-x11-drv-neomagic-1.2.4-3.fc13.src.rpm -rw-r--r--2 263 26391334 Feb 18 16:59 xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm -rw-r--r--2 263 263 449803 Feb 9 12:19 xorg-x11-drv-nv-2.1.15-5.fc13.src.rpm -rw-r--r--2 263 263 475028 Feb 9 12:26 xorg-x11-drv-openchrome-0.2.904-2.fc13.src.rpm -rw-r--r--2 263 263 248668 Feb 9 12:27 xorg-x11-drv-penmount-1.4.0-6.fc13.src.rpm -rw-r--r--2 263 263 280184 Feb 5 22:08 xorg-x11-drv-qxl-0.0.9-0.1.fc13.src.rpm -rw-r--r--2 263 263 424771 Feb 5 19:36 xorg-x11-drv-r128-6.8.1-3.fc13.src.rpm -rw-r--r--2 263 26
Re: [git pull] drm request 3
> The conclusion is crystal clear, breaking an ABI via a "flag day" > cleanup/feature/etc is: Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor junk that is in there being cleaned up it would be *insane* to keep their old APIs See there's a bigger offence than breaking an ABI - its called not RTFM. Alan -- Download Intel® 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] fence errors with rs785 and kernel 2.6.33
http://bugs.freedesktop.org/show_bug.cgi?id=26887 Marc changed: What|Removed |Added CC||marvi...@gmx.de --- Comment #3 from Marc 2010-03-05 03:41:22 PST --- yes - could this be sideport related? -- 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® 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:59 PM, Adam Jackson wrote: > On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote: > >>> # sed -i 's/\.*/& 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. Thanks. Can this be put into F12 too? > 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. The latter... would modeset in grub interfere, perhaps? Jeff -- Download Intel® 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] fence errors with rs785 and kernel 2.6.33
http://bugs.freedesktop.org/show_bug.cgi?id=26887 --- Comment #2 from Jerome Glisse 2010-03-05 03:07:44 PST --- Does this happen all the time ? -- 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® 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
Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri 5.Mar'10 at 8:44:07 +0100, Ingo Molnar wrote: > > 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: I agree 100% with this! I test the kernel often (running 2.6.33-05070-g64ba992 ATM) because it is _easy_ for me. Every morning I simply do a 'git pull' + compile + install and I am ready to test the bleeding edge kernel. And everytime I complained about something breaking it got fixed. Really, testing the linux kernel is a hobby for me because it is easy. Whereas everytime I wanted to do that with Xorg it was such a pain that I want to keep away from that mess. > - 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. True! Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the guarantee that the whole thing will simply work nicely together? If this could be done for the kernel (which from my user POV seems much more complicated), I guess it could be done with Xorg. And Linux would have more Xorg testers and be better as a whole. -- Download Intel® 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
[PATCH 3/3] drm/radeon/kms: simplify & improve GPU reset
This simplify and improve GPU reset for R1XX-R6XX hw, it's
not 100% reliable here are result:
- R1XX/R2XX works bunch of time in a row, sometimes it
seems it can work indifinitly
- R3XX/R3XX the most unreliable one, sometimes you will be
able to reset few times, sometimes not even once
- R5XX more reliable than previous hw, seems to work most
of the times but once in a while it fails for no obvious
reasons (same status than previous reset just no same
happy ending)
- R6XX/R7XX are lot more reliable with this patch, still
it seems that it can fail after a bunch (reset every
2sec for 3hour bring down the GPU & computer)
This have been tested on various hw, for some odd reasons
i wasn't able to lockup RS480/RS690 (while they use to
love locking up).
Note that on R1XX-R5XX the cursor will disapear after
lockup haven't checked why, switch to console and back
to X will restore cursor.
Next step is to record the bogus command that leaded to
the lockup.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c | 180 +++
drivers/gpu/drm/radeon/r100d.h | 128 ++
drivers/gpu/drm/radeon/r300.c | 134 +++-
drivers/gpu/drm/radeon/r300d.h | 47 -
drivers/gpu/drm/radeon/r520.c |1 -
drivers/gpu/drm/radeon/r600.c | 53 +-
drivers/gpu/drm/radeon/radeon.h|4 +-
drivers/gpu/drm/radeon/radeon_asic.h | 12 +-
drivers/gpu/drm/radeon/radeon_device.c | 20
drivers/gpu/drm/radeon/radeon_fence.c |5 +-
drivers/gpu/drm/radeon/radeon_gart.c |4 +
drivers/gpu/drm/radeon/rs400.c |2 -
drivers/gpu/drm/radeon/rs600.c | 73 +-
drivers/gpu/drm/radeon/rs600d.h| 46
drivers/gpu/drm/radeon/rs690.c |2 -
drivers/gpu/drm/radeon/rv515.c | 90
drivers/gpu/drm/radeon/rv515d.h| 46
17 files changed, 501 insertions(+), 346 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index f5b46a9..91e3b57 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -659,26 +659,6 @@ int r100_cp_init(struct radeon_device *rdev, unsigned
ring_size)
if (r100_debugfs_cp_init(rdev)) {
DRM_ERROR("Failed to register debugfs file for CP !\n");
}
- /* Reset CP */
- tmp = RREG32(RADEON_CP_CSQ_STAT);
- if ((tmp & (1 << 31))) {
- DRM_INFO("radeon: cp busy (0x%08X) resetting\n", tmp);
- WREG32(RADEON_CP_CSQ_MODE, 0);
- WREG32(RADEON_CP_CSQ_CNTL, 0);
- WREG32(RADEON_RBBM_SOFT_RESET, RADEON_SOFT_RESET_CP);
- tmp = RREG32(RADEON_RBBM_SOFT_RESET);
- mdelay(2);
- WREG32(RADEON_RBBM_SOFT_RESET, 0);
- tmp = RREG32(RADEON_RBBM_SOFT_RESET);
- mdelay(2);
- tmp = RREG32(RADEON_CP_CSQ_STAT);
- if ((tmp & (1 << 31))) {
- DRM_INFO("radeon: cp reset failed (0x%08X)\n", tmp);
- }
- } else {
- DRM_INFO("radeon: cp idle (0x%08X)\n", tmp);
- }
-
if (!rdev->me_fw) {
r = r100_cp_init_microcode(rdev);
if (r) {
@@ -781,39 +761,6 @@ void r100_cp_disable(struct radeon_device *rdev)
}
}
-int r100_cp_reset(struct radeon_device *rdev)
-{
- uint32_t tmp;
- bool reinit_cp;
- int i;
-
- reinit_cp = rdev->cp.ready;
- rdev->cp.ready = false;
- WREG32(RADEON_CP_CSQ_MODE, 0);
- WREG32(RADEON_CP_CSQ_CNTL, 0);
- WREG32(RADEON_RBBM_SOFT_RESET, RADEON_SOFT_RESET_CP);
- (void)RREG32(RADEON_RBBM_SOFT_RESET);
- udelay(200);
- WREG32(RADEON_RBBM_SOFT_RESET, 0);
- /* Wait to prevent race in RBBM_STATUS */
- mdelay(1);
- for (i = 0; i < rdev->usec_timeout; i++) {
- tmp = RREG32(RADEON_RBBM_STATUS);
- if (!(tmp & (1 << 16))) {
- DRM_INFO("CP reset succeed (RBBM_STATUS=0x%08X)\n",
-tmp);
- if (reinit_cp) {
- return r100_cp_init(rdev, rdev->cp.ring_size);
- }
- return 0;
- }
- DRM_UDELAY(1);
- }
- tmp = RREG32(RADEON_RBBM_STATUS);
- DRM_ERROR("Failed to reset CP (RBBM_STATUS=0x%08X)!\n", tmp);
- return -1;
-}
-
void r100_cp_commit(struct radeon_device *rdev)
{
WREG32(RADEON_CP_RB_WPTR, rdev->cp.wptr);
@@ -1727,51 +1674,6 @@ int r100_mc_wait_for_idle(struct radeon_device *rdev)
return -1;
}
-void r100_gpu_init(struct radeon_device *rdev)
-{
- /* TODO: anythings to do here ? pipes ? */
- r100_hdp_reset(rdev);
-}
-
-void r100_hdp_reset(struct radeon_device *rdev)
-{
- uint32_t tmp;
-
- tmp
[PATCH 2/3] drm/radeon/kms: rename gpu_reset to asic_reset
Patch rename gpu_reset to asic_reset in prevision of having
gpu_reset doing more stuff than just basic asic reset.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/r100.c |6 ++--
drivers/gpu/drm/radeon/r300.c |6 ++--
drivers/gpu/drm/radeon/r420.c |4 +-
drivers/gpu/drm/radeon/r520.c |4 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/radeon.h|6 ++--
drivers/gpu/drm/radeon/radeon_asic.h | 36
drivers/gpu/drm/radeon/radeon_device.c |2 +-
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
drivers/gpu/drm/radeon/rs400.c |4 +-
drivers/gpu/drm/radeon/rs600.c |4 +-
drivers/gpu/drm/radeon/rs690.c |4 +-
drivers/gpu/drm/radeon/rv515.c |8 +++---
14 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 8988df7..f1a860c 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -496,7 +496,7 @@ bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
return false;
}
-int evergreen_gpu_reset(struct radeon_device *rdev)
+int evergreen_asic_reset(struct radeon_device *rdev)
{
/* FIXME: implement for evergreen */
return 0;
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 96a6370..f5b46a9 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1856,7 +1856,7 @@ bool r100_gpu_is_lockup(struct radeon_device *rdev)
return r100_gpu_cp_is_lockup(rdev, &rdev->config.r100.lockup,
&rdev->cp);
}
-int r100_gpu_reset(struct radeon_device *rdev)
+int r100_asic_reset(struct radeon_device *rdev)
{
uint32_t status;
@@ -3498,7 +3498,7 @@ int r100_resume(struct radeon_device *rdev)
/* Resume clock before doing reset */
r100_clock_startup(rdev);
/* Reset gpu before posting otherwise ATOM will enter infinite loop */
- if (radeon_gpu_reset(rdev)) {
+ if (radeon_asic_reset(rdev)) {
dev_warn(rdev->dev, "GPU reset failed ! (0xE40=0x%08X,
0x7C0=0x%08X)\n",
RREG32(R_000E40_RBBM_STATUS),
RREG32(R_0007C0_CP_STAT));
@@ -3566,7 +3566,7 @@ int r100_init(struct radeon_device *rdev)
return r;
}
/* Reset gpu before posting otherwise ATOM will enter infinite loop */
- if (radeon_gpu_reset(rdev)) {
+ if (radeon_asic_reset(rdev)) {
dev_warn(rdev->dev,
"GPU reset failed ! (0xE40=0x%08X, 0x7C0=0x%08X)\n",
RREG32(R_000E40_RBBM_STATUS),
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 08b79c0..fd162f0 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -446,7 +446,7 @@ bool r300_gpu_is_lockup(struct radeon_device *rdev)
return r100_gpu_cp_is_lockup(rdev, &rdev->config.r300.lockup,
&rdev->cp);
}
-int r300_gpu_reset(struct radeon_device *rdev)
+int r300_asic_reset(struct radeon_device *rdev)
{
uint32_t status;
@@ -1329,7 +1329,7 @@ int r300_resume(struct radeon_device *rdev)
/* Resume clock before doing reset */
r300_clock_startup(rdev);
/* Reset gpu before posting otherwise ATOM will enter infinite loop */
- if (radeon_gpu_reset(rdev)) {
+ if (radeon_asic_reset(rdev)) {
dev_warn(rdev->dev, "GPU reset failed ! (0xE40=0x%08X,
0x7C0=0x%08X)\n",
RREG32(R_000E40_RBBM_STATUS),
RREG32(R_0007C0_CP_STAT));
@@ -1399,7 +1399,7 @@ int r300_init(struct radeon_device *rdev)
return r;
}
/* Reset gpu before posting otherwise ATOM will enter infinite loop */
- if (radeon_gpu_reset(rdev)) {
+ if (radeon_asic_reset(rdev)) {
dev_warn(rdev->dev,
"GPU reset failed ! (0xE40=0x%08X, 0x7C0=0x%08X)\n",
RREG32(R_000E40_RBBM_STATUS),
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index c7593b8..3221855 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -233,7 +233,7 @@ int r420_resume(struct radeon_device *rdev)
/* Resume clock before doing reset */
r420_clock_resume(rdev);
/* Reset gpu before posting otherwise ATOM will enter infinite loop */
- if (radeon_gpu_reset(rdev)) {
+ if (radeon_asic_reset(rdev)) {
dev_warn(rdev->dev, "GPU reset failed ! (0xE40=0x%08X,
0x7C0=0x%08X)\n",
RREG32(R_000E40_RBBM_STATUS),
RREG32(R_0007C0_CP_STAT));
@@ -313,7 +313,7 @@ int r420_init(struct radeon_device *rdev)
}
}
/* Reset gpu before posti
Improved GPU reset
This patches improve the GPU reset, many time i able to successfully reset the GPU and carry on operation, note that after a reset you will likely see corrpution on the screen. Hope is that we should now be able to capture faulty command stream. I still need to do a full retesting with this patch (especialy suspend/resume). -- Download Intel® 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 #8 from Michel Dänzer 2010-03-05 02:08:30 PST --- IIRC I was using the post radeon-rewrite driver without KMS for a while on my PowerBook, and I don't remember issues like this. So with some luck, this is a regression between the radeon-rewrite merge (commit 7f223ff89172069dbad987f592aea2a8ba16355f) and 7.6.1 which could be bisected. BTW, can you guys attach your Xorg.0.log files? -- 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® 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 23:44, Ingo Molnar wrote: > > * Pekka Enberg wrote: > >> On Fri, Mar 5, 2010 at 8:49 AM, Ingo Molnar 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. > Yes that is exactly the problem we are facing. And you know what? All graphic driver devs agree on that, but there is no obvious solution. Here are the interfaces which are part of this problem: - drm interface (drm wrappers as seen from the driver, drm ioctls from the user space) - X.Org acceleration interface (EXA and friends as seen from the driver, XRender and friends as seen from the apps) - Mesa interface (Gallium or mesa driver interface from the driver, OpenGL seen from the app) Any solution will involve merging two or more components together to remove interfaces, so lets observe pairwise what could be merged and the drawbacks: - Merge DRM and Mesa drivers. Technically we could do this, but then what happens when a new OpenGL version/feature comes around? Yes, we get a new mesa interface. So we're exchanging one interface for another here. No gain. - Merge DDX And DRM driver. Same problem as before, whenever 2D interfaces changes, we have to update the DDX anyway. Again, no gain in sight. - Merge Mesa and DDX drivers. This makes sense, and this is where gallium is going by providing 2D and GL acceleration on top of a singl
Re: [PATCH] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
Hi Eric, On Wed, 2010-03-03 at 15:34 -0800, Eric Anholt wrote: > On Tue, 2 Mar 2010 22:59:52 +0200, Surbhi Palande > wrote: > > BugLink: https://bugs.launchpad.net/bugs/515246 > > > > Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed > > when it is open. This leads to a "no connectors reported" error at startup. > > Blacklisting them, to always return a connected status for the default > > lvds connector. > > > > Signed-off-by: Surbhi Palande > > As far as I know, this should already be covered by: > > commit 7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4 > Author: Jesse Barnes > Date: Fri Feb 12 09:30:00 2010 -0800 > > drm/i915: give up on 8xx lid status Yes I agree. Thanks for the comment. However, the "drm/i915: give up on 8xx lid status" will work for the Dell Inspiron 700m. But, the Sony VGN-BX196VP will still need to be blacklisted as it is a 915GM device. If you agree with this, I will rewrite the patch and send you another version. Thanks! Warm Regards, Surbhi. -- Download Intel® 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 Thursday 04 March 2010 18:53:32 Linus Torvalds wrote: > > 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? Why not support a _minimal_ ABI that will always let X start with nouveau? Having X working does not mean that all forms of acceleration have to work too. If X starts, even if is slow, users can easily check logs which should have a message saying 'ABI change - upgrade your ...'. Thoughts? Ed Tomlinson -- Download Intel® 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 01:32 PM, Jeff Garzik wrote: > 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. Indeed, that text isn't really reconcilable with the fact that the driver is being used by default in a stable distro release. (Why do people keep forgetting the whole "upstream development" thing?) > > 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. Advising people to use nv is pretty much a joke IMHO, it's barely above VESA in some ways. People would be more likely to use the nvidia binary driver than that contraption.. Aside from the fact that running nouveau on this machine would drive me crazy (there's no fan speed control implemented so the GPU fan screams away at maximum speed), the other big reason I can't use it is that at least until quite recently it couldn't work with upstream kernels. Unfortunately, changes like this will being that problem back.. So at this point the nvidia binary driver is the most practical solution that actually meets my needs, sadly enough.. > > 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® 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 4:41 PM, Linus Torvalds wrote: > And if we end up having people bisecting back and forth, I will hate that > f*cking nouveau driver even more. Would it help to tag the flag day commit? At least that would make it trivial for bisecters to see whether each step in a bisection contains the commit or not. Generalizing that ... perhaps there could be a way to tell git that some set of tags represent flag days, so it could warn in any bisection if the set of included flag days changes. -Tony -- Download Intel® 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 03:53:32PM -0800, Linus Torvalds wrote: > 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". > Frankly, I completely agree with you. This kind of shit makes it extremely difficult for users to run, say, 2.6.33 on F-12 without us doing a backport. Thankfully Ben takes care of that for me, usually, by keeping nouveau up to date with upstream in the various Fedora's, but it's still a set of shackles that I'm pretty sure none of us want. (Not only that, but it means if you update, you may need to do a full reboot before you can start X again, which is pretty disappointing.) For example, right now, Fedora 11's 2.6.30 kernel has nouveau 12, with nouveau 12 userspace. For Fedora 11's 2.6.32 kernel, instead of updating the userspace stuff, I forward ported the old DRM entirely, bringing with it whatever bugs it had, simply because DRM is such a nightmare. It's already impossible to run Fedora 13's 2.6.33 kernel on 12 since Ben put the nouveau git changes for the new ABI in there already. So we'll have to drop those from the F-13 2.6.33 for the F-12 2.6.33... This situation /sucks/ for users. Personally, I think we committed to a stable update ABI when nouveau got a MODULE_DEVICE_TABLE and started binding by default. But hey, I'm just the kernel maintainer, and I didn't pipe up then, which was my mistake. If we're going to ram something at users by default, we should at least try to guarantee that they'll be able to restart X and have things continue to work. That said, whether you think it's a lame excuse or not, staging was clearly labelled as buyer beware. I'm personally sorry that you got burned by nouveau on Fedora both these times, but we're really just trying to help, and not hinder things. (Maybe I should commit a patch to rip out the module aliases for nouveau, but I suspect I'd have more people screaming for blood that way. Sigh.) regards, Kyle -- Download Intel® 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
