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: [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
Re: [git pull] drm request 3
On 03/04/2010 05:18 PM, Adam Jackson wrote: > On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote: >> On 03/04/2010 02:04 PM, Matthew Garrett wrote: >>> F-12 continues to ship the -nv driver, which will work fine with any >>> kernel version as long as nouveau is disabled. >> >> FAIL. I actually tried that. Have you? Do you think it is remotely >> easy for a technically component, non-Xorg-hacker type to accomplish? > > # cat<< EOF> /etc/X11/xorg.conf > Section "Device" > Identifier "Card0" > Driver "nv" > EndSection > EOF Already tried that, and other suggested variations thereof. Did not work on F11 or F12 with 05:00.0 VGA compatible controller: nVidia Corporation GeForce 9800 GX2 (rev a2) > # sed -i 's/\.*/& nouveau.modeset=0/g' /etc/grub.conf Never tried this part. 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 03/04/2010 02:04 PM, Matthew Garrett wrote: > "Please note that these drivers are under heavy development, may or may > not work, and may contain userspace interfaces that most likely will be > changed in the near future." Shipping it as the default Fedora driver for NVIDIA hardware makes that text largely irrelevant. Jesse said > Dave and the nouveau guys include the driver in Fedora to get > much needed test coverage, and make sure the latest bits in rawhide > work together. but when it is the default driver, it is the default _production_ driver for Fedora users, in an official, stable Fedora release. And the alternative? You said > F-12 continues to ship the -nv driver, which will work fine with any > kernel version as long as nouveau is disabled. FAIL. I actually tried that. Have you? Do you think it is remotely easy for a technically component, non-Xorg-hacker type to accomplish? I attempted to use the non-default 'nv' driver just before nouveau was merged into upstream/staging, because I wanted a development kernel that actually worked on my Fedora-based devel boxes. It was a complete exercise in frustration, requiring at least one bugzilla bug report, and ultimately resulted in failure. I gave up and waiting for Linus to merge nouveau, which instantly made my life a lot easier :) Kernel hacking on Fedora, my own dogfood, has become increasingly cumbersome because of all these graphics issues. Sometimes it's just easier to test a modern kernel on an ancient distro, sadly. Jeff -- Download Intel® 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
On 12/11/2009 10:28 AM, Linus Torvalds wrote: > > > On Fri, 11 Dec 2009, Jeff Garzik wrote: >> >> F11 uses nouveau here. It is actually a pain to get 'nv' going as an >> alternate -- bugs have been filed. Makes kernel dev more difficult for me. >> I >> was actually told, by Fedora people, that I should be hacking on the Fedora >> (rpm-based) kernel, rather than a 100% upstream kernel like I have been >> hacking/booting for the past decade, as a result of this setup (needing >> nouveau kernel support, thus needing Fedora rather than upstream kernel). > > Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the > wrong people - it's just that the actual driver authors aren't the ones > that violated any rules), I do have to give kudos for the fact that the > F12 situation seems to be much better. > > These days, what you can do is basically do all development (assuming it's > not nouveau development) in the upstream kernel, and then you just have a > separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff > into. > > That tree/branch will be a mess of random merges-of-the-day, but you'll > never push it out to anybody anyway, so nobody cares. And building that > messy merge tree will get you a working setup without any extra steps - a > simple "make modules_install ; make install" will JustWork(tm). At the outset, I was hoping for an even more straightforward solution: "if nouveau kernel mod not present, fall back to nv" That would work without any kernel modifications at all. But the answer came back as "if you run Fedora, run a Fedora kernel, otherwise don't expect anything to work" My experience directly contradicts claims of "upstream first" policy, both in code and attitude. I am looking into doing the git tree merge you suggest right now I didn't know that was an option, given ongoing API changes. That would make my life quite a bit easier. As you note, anything graphics is _glacially_ slow due to vesa fallback, when using a 100% upstream kernel. Jeff -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On 12/11/2009 04:18 AM, Alan Cox wrote: > F11 certainly shipped some bits of it for 2D support. I am not sure if > F10 shipped a purely userspace set up. Neither had it enabled as the > default driver - they used "nv" or "vesa" depending upon the card. F11 uses nouveau here. It is actually a pain to get 'nv' going as an alternate -- bugs have been filed. Makes kernel dev more difficult for me. I was actually told, by Fedora people, that I should be hacking on the Fedora (rpm-based) kernel, rather than a 100% upstream kernel like I have been hacking/booting for the past decade, as a result of this setup (needing nouveau kernel support, thus needing Fedora rather than upstream kernel). Jeff -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel oops after drmfntbl-0-0-2-20040824-merge
Ian Romanick wrote: So, you have x_ata.ko and y_ata.ko that are both linked with libata. What happens when when the user loads both modules at once? How do you avoid symbol conflicts from the libata linked to both drivers? This is basically what the DRM does, but we have the evil macros (no, I don't like them either) to prevent the symbol conflicts. libata is a library module. Just like userspace libraries, libata module is loaded once, then shared among N drivers that reference its symbols. The first module loaded will cause libata to be loaded. The second module loaded will simply reference the already-loaded libata. There is no need for additional work to prevent symbol conflicts. Jeff --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote: > On Saturday 25 October 2003 21:17, Jeff Garzik wrote: > > Graphics processors are growing more general, too -- moving towards > > generic vector/data processing engines. I bet you'll see an optimal > > model emerge where you have some sort of "JIT" for GPU microcode in > > userspace. Multiple apps pipeline X/GL/hardware commands into the JIT, > > which in turn pipelines data and microcode commands to the GPU kernel > > driver. > > These "JIT" is needed also for another reason: > > There are contraints for GPU commands and the pipelines need to > be modelled, like CPU piplines are modelled in a compiler. But > more like the pipelines of some early long instruction word > processors, where issuing to a used pipeline will cause random > behavior and crashes. So the JIT doesn't should also emit > synchronization points. > > With this JIT in place, there need to be just some hardware description > files (backends) and some API (GL, DirectX, X) description files > (frontends). I agree 60% ;-) This JIT emits GPU-specific microcode, so it should lean towards being hardware-dependent. Speed and efficiency IMO demand that. Looking at existing, open-source CPU JITs, there are certainly general pieces and CPU-specific pieces. But for GPUs, I think the best method is to start at the more-GPU-specific end of the spectrum, and _evolve_ towards a more general solution, as hardware needs dictate. In other terms, let the hardware drive the JIT design and evolution, and don't over-design for a future that may never come. That was part of GGI's problem, IMO. > Now we just need some funding for that and the datasheets. Then it's > doable. Yep ;-) > I see just one showstopper: Cheating in benchmarks isn't possible anymore. > > PS: That's basically the GGI approach taken further. I followed GGI for a while. Trying to be all things to all people was their principle mistake. As Pat Morita said in Karate Kid, "Focus, Daniel-san!" Be specific before general. Jeff --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
On Mon, Oct 27, 2003 at 03:14:11PM +, Keith Whitwell wrote: > Jeff Garzik wrote: > >Thank you for saying it. This is what I have been preaching (quietly) > >for years -- command submission and synchronization (and thus, DMA/irq > >handling) needs to be in the kernel. Everything else can be in > >userspace (excluding hardware enable/enumerate, of course). > > To enable secure direct rendering on current hardware (ie without secure > command submission mechanisms), you need command valididation somewhere. > This could be a layer on top of the minimal dma engine Linus describes. Certainly. > >Graphics processors are growing more general, too -- moving towards > >generic vector/data processing engines. I bet you'll see an optimal > >model emerge where you have some sort of "JIT" for GPU microcode in > >userspace. > > You mean like the programmable fragment and vertex hardware that has been > in use for a couple of years now? I mean, taking current fragment and vertex processing and making it even _more_ general. Which has already happened, on one particular chip maker's chip... Jeff --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
Linus Torvalds wrote: Quite frankly, I'd much rather see a low-level graphics driver that does _two_ things, and those things only: - basic hardware enumeration and setup (and no, "basic setup" does not mean "mode switching": it literally means things like doing the pci_enable_device() stuff. - serialization and arbitrary command queuing from a _trusted_ party (ie it could take command lists from the X server, but not from untrusted clients). This part basically boils down to "DMA and interrupts". This is the part that allows others to wait for command completion, "enough space in the ring buffers" etc. But it does _not_ know or care what the commands are. Thank you for saying it. This is what I have been preaching (quietly) for years -- command submission and synchronization (and thus, DMA/irq handling) needs to be in the kernel. Everything else can be in userspace (excluding hardware enable/enumerate, of course). Graphics processors are growing more general, too -- moving towards generic vector/data processing engines. I bet you'll see an optimal model emerge where you have some sort of "JIT" for GPU microcode in userspace. Multiple apps pipeline X/GL/hardware commands into the JIT, which in turn pipelines data and microcode commands to the GPU kernel driver. Jeff --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
On Fri, Oct 24, 2003 at 09:44:38AM -0700, Linus Torvalds wrote:
> So wouldn't it be nice if we just had those ten lines as a generic
> function like
>
> int pci_enable_rom(struct pci_device *dev)
> {
> ...
>
> int pci_disable_rom(..);
Yes. Agreed,
Jeff
---
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
Linus Torvalds wrote: [ Jeff: is that PCI ROM enable _really_ that complicated? Ouch. Or is there some helper function I missed? ] The mechanics aren't complicated, but I seem to recall there being a Real Good Reason why you want to leave it disabled 99% of the time. No, I don't recall that reason :( But my fuzzy memory seems to think that "enable, grab a slice o 'rom, disable" was viable. Jeff --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport
Larry McVoy wrote:
On Mon, Aug 11, 2003 at 01:15:58PM -0400, Jeff Garzik wrote:
if (expr) statement; // OK
The test and the statement run together visually, which is it is
preferred to put the statement on the following line.
Nah.
if (!p) return (whatever);
if (foo) {
statement;
} else {
statement;
statement;
}
if (!p) return (whatever);
Perfectly readable. We have a few hundred thousand lines of code written
Ug. The first and last 'if' need spreading out away from the big fat
block, and the "return (whatever)" fools your eyes into thinking they
are function calls at a 10-nanosecond glance. Also, having two styles
of 'if' formatting in your example just screams "inconsistent" to me :)
like this and I review all of it. I suspect that I do more reviewing than
99% of the people on this list which makes my opinion count more because
anything that makes my tired eyes absorb the info faster is a good thing.
Absolutely not. I'm cooler, so my opinion counts more.
Same for your eyes when you get to my age.
I bet when you were in school, you had to chip your homework into slate,
and dinner was brontosaurus-kebob, right?
I also make people do
if ((a <= B) || (c >= d)) {
xxx
}
even though I know, if I think about it, what the precedence is. It doesn't
matter that I know or you know, what matters is the number of lines of code
a day you can correctly review. Anything that helps that means that you
are helping people make the source base better. Try reading 30K lines of
diffs at one sitting and tell me again that I'm wrong. If you do, bump it
up to 60K lines :)
Absolutely agreed. I do the same myself out of habit.
if (!pointer) return (-EINVAL);
Short, sweet, readable, no worries.
return is not a function ;-)
See, there is that age thing again. Think V6. And it is sort of a function,
it unravels the stack frame.
hehe :) I suppose one could say I'm biased towards the compiler view of
things, 'return' being a compiler intrinsic, controlling code flow like
several other compiler intrinsics.
Jeff, who also despises longjmp()
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport
Larry McVoy wrote:
On Mon, Aug 11, 2003 at 01:53:17PM -0400, Jeff Garzik wrote:
Larry McVoy wrote:
are function calls at a 10-nanosecond glance. Also, having two styles
of 'if' formatting in your example just screams "inconsistent" to me :)
It is inconsistent, on purpose. It's essentially like perl's
return unless pointer;
which is a oneliner, almost like an assert().
perl is a yucky language full of hacks like this... one of the reasons
why I love it :)
So while perl's syntax sugar allows my hands to type a bit less, I'll
often find myself following a C style and doing
return
unless statement;
In general, I will continue to say the 'if' test should be completely
separately from the statement, no matter how short either are.
Maybe this will help: I insist on braces on anything with indentation so
that I can scan them more quickly. If I gave you a choice between
if (!pointer) {
return (whatever);
}
if (!pointer) return (whatever);
which one will you type more often? I actually don't care which you use,
I prefer the shorter one because I don't measure my self worth in lines
of code generated, I tend to favor lines of code deleted :) But either
one is fine, I tend to use the first one if it has been a problem area
and I'm likely to come back and shove in some debugging.
Before you say "lose the braces" try reading more code and see how much faster
it is if all indented stuff has braces. You whiz through it.
Unless you get more than one or two independent 'if' tests like that,
then all those braces for a one-line test eat up wasted screen real
estate, slowing down the person reading the code.
So, if you gave me the choice above, I would choose option C, neither :)
Absolutely not. I'm cooler, so my opinion counts more.
You are in North Carolina, I'm in San Francisco. No competition, you are
sweating like a pig :)
Same for your eyes when you get to my age.
I bet when you were in school, you had to chip your homework into slate,
and dinner was brontosaurus-kebob, right?
Dinner? You got dinner? Damn, you were spoiled.
hehe :)
Jeff
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport
Larry McVoy wrote: A few comments on why I don't like this patch: 1) It's a formatting only patch. That screws over people who are using BK for debugging, now when I double click on these changes I'll get to your cleanup patch, not the patch that was the last substantive change. This is true, but at the same time, in Linux CodingStyle patches culturally acceptable. I think the general logic is just "don't go overboard; reformat a tiny fragment at a time." 2) "if (expr) statement;" really ought to be considered legit coding style. It's a one line "shorty" and it lets you see more of the code on a screen. On the other hand, the author carried things too far when they did if (expr) statement; else statement; that's too hard for your eyes to parse quickly IMO. tee hee :) This is why we have Documentation/CodingStyle, for just this type of discussion. I actually prefer your "author carried ... too far" example, with the reasoning: if you _must_ deviate from CodingStyle, at least don't run the damn lines together like if (test) foo else bar; or if (test) foo else bar; The alignment of the statements visually separates out the test more clearly. Jeff --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport
Larry McVoy wrote: That ought to be balanced with "don't screw up the revision history, people use it". It's one thing to reformat code that is unreadable, for the most part this code didn't come close to unreadable. Granted. I wasn't suggesting that. I was saying if (expr) statement; // OK The test and the statement run together visually, which is it is preferred to put the statement on the following line. The exception I was saying was reasonable is if you are doing something like if (!pointer) return (-EINVAL); Short, sweet, readable, no worries. return is not a function ;-) Jeff --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
