Re: [PATCH 1/1] Adapt on_each_cpu
On Thu, Aug 07, 2008 at 04:08:49PM -0700, Eric Anholt wrote: a) BSD I'd like to hear Robert's concerns here, but I've been working with some of the BSD folks lately, and it seems like the main concerns are: 1) making it easy for contributors to identify which portions of code are shared 2) licensing Since both the BSDs and Linux effectively copy code out of the DRM repo and into their respective kernel trees at this point, having the actual repo based on one of them shouldn't be an issue as long as both 1 and 2 are handled. The remaining compat macros could probably just be wrapped in some sort of Linux equivalent (DRM_SPINUNLOCK-spin_unlock, what's the difference?), or we could annotate things for the BSD guys to run scripts over. As it stands, they still have to go over things by hand anyway... As an ex-BSD kernel maintainer, I stood against moving to a linux kernel-based tree for a long time. For a long time I felt like I was the only guy holding back the move. I couldn't get NetBSD to work in the upstream tree, and it sounds like OpenBSD's following the same route, so maybe I was doing it wrong all along in trying to have one tree for all OSes to share. As the OpenBSD maintainer it's probably time I mention my reasons for working out of tree. It's quite simple really, In my experience of porting over the code, I found that the BSDs, while similar, are no where near identical, and in the end the level of #ifdefing in the bsd-core area just got insane, it made maintainance a nightmare. So I started working out of tree. If i find a general bug, I reformat against git and send the patch upstream. Otherwise, I watch what happens to git and merge it into my kernel tree along with any OpenBSD specific changes i've needed. This is more like the way the BSDs have shared code for a while now. I know myself and Robert differ on our opinions here, though. I find it better to be able to go over things by hand, it means I better understand what I'm merging, anyway. For that reason, i'm not against master going to a linux kernel tree, since it would change my process very minimally. As long as the licensing doesn't change (IMHO drm is essentially a part of X, and thus should be X11/MIT licensed), I'm fine with it. Process-wise, I'm in agreement with Dave Airlie, that master should track what's in linus' tree, with the rest on branches. Also, I think vblank-rework is now stable enough to go upstream, i've found it has started to work quite nicely. Just my 2p, -0- -- There's no easy quick way out, we're gonna have to live through our whole lives, win, lose, or draw. -- Walt Kelly - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: Please HELP!!! accumulation buffers support FC9
I'm certainly not a great expert in OpenGL, but accumulation buffers can be quite handy. It seems highly unlikely that I'm the only one using them. Besides you can find a simple tricks with the accumulation buffers in every openGL book. I think the more common way is to use frame buffer objects for this nowadays. They more flexible and closer to how the hardware works. I think accumulation buffers are going to be removed in OpenGL 3, but I haven't checked the latest spec. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRM question
What's the minimum I need to port over to have something working? Dee Sharpe -Original Message- From: Nicolai Hähnle [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; dri-devel@lists.sourceforge.net Sent: Wed, 6 Aug 2008 2:43 am Subject: Re: [Mesa3d-dev] DRM question Am Mittwoch 06 August 2008 02:53:23 schrieb [EMAIL PROTECTED]: I've been working on a port of DRM for Syllable.? Syllable doesn't support drivers (or kernel modules) that are on the same level of abstraction communicate with each other.? For example our sound card drivers can't communicate with any other driver normal driver, they can only communicate with busmanagers (PCI, ISA, etc.).? With this in mind, I've been wondering what the signifigance of having a drm kernel object that's seperate from the video driver, but the video driver is dynamicly linked to it.? If I have gotten something wrong, please let me know.? Also, is it a big deal to just compile all of the drm driver code into the video drivers?? I ask this, not because I'm trying to change the way you all do things, but only because I'm trying to find a suitable solution for Syllable. It's been a very long time since I last looked into Syllable, but if I remember things correctly, the setup was something like: 1. Hardware-specific video driver in the kernel 2. Hardware agnostic server in userspace that manages the desktop The Linux setup is like this: 1. Hardware-independent kernel module drm 2. Hardware-specific kernel module, e.g. radeon 3. Hardware-specific module in the Xserver Since you already have a hardware-specific module in the kernel, I think it's reasonable to merge the hardware-specific parts of the drm into that existing module. After all, when you have two hardware-specific modules in the kernel you only end up having to worry about interface compatibility issues when people run versions of the modules that don't match (alternatively you could force the module versions to be the same, but then why separate things into two different modules in the first place). As for the hardware-independent kernel bits (the drm module), perhaps you should think of them not as a driver but as a kind of shared library that contains utility functions for writing a driver? Once you're in that mindset of the drm bits being a library, and if the Syllable kernel really doesn't support shared library loading (that's a very odd design decision), you could always build them as a static library that is linked into each of the hardware-specific drivers. So if that was your original question, no, I don't think it's a big deal if that's the way Syllable works. The important thing is that it should be possible to do all this without touching the shared-core directory by putting the Syllable-specific things in their own directory (as is the case for Linux and BSD today). cu, Nicolai --- -- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7117] openGL irregularly freezes radeon system
http://bugs.freedesktop.org/show_bug.cgi?id=7117 Rolf Leggewie [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ||ggewie.biz --- Comment #21 from Rolf Leggewie [EMAIL PROTECTED] 2008-08-08 18:35:41 PST --- Is this still a problem? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
