Re: [Mesa3d-dev] Mesa removals
-Original Message- From: Ian Romanick To: mesa3d-dev@lists.sourceforge.net Sent: Mon, Feb 22, 2010 1:46 pm Subject: Re: [Mesa3d-dev] Mesa removals -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: > Starting a new thread on this... > > Here's a proposal of things to remove from the Mesa tree. > > GLU: > glu/mini > glu/mesa > > GLUT: > glut/fbdev > glut/ggi > glut/directfb > glut/dos > glut/mini > glut/os2 > > non-DRI drivers: > drivers/allegro > drivers/directfb > drivers/d3d > drivers/dos > drivers/ggi > drivers/glide > drivers/svga > > DRI drivers: > drivers/dri/fb > drivers/dri/ffb > drivers/dri/gamma > > progs/directfb > progs/ggi > progs/windml > progs/miniglx > > Comments? That list looks good to me. I'm a little sad to see gamma go, but that's mostly sadness that it was never revived after the DRI / DRM architecture started going a different direction. Does anyone have docs for gamma hardware? If so, I'd love to get my hands on it. I still have a gamma board that needs a bit of love! Dee Sharpe -- 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___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Fwd: RFC: libdrm repo
There doesn't seem to be a makefilewhat's the build system? -Original Message- From: Robert Noland To: Dee Sharpe Cc: mesa3d-dev@lists.sourceforge.net Sent: Sun, Nov 22, 2009 11:23 am Subject: Re: [Mesa3d-dev] Fwd: RFC: libdrm repo On Sun, 2009-11-22 at 10:04 -0600, Dee Sharpe wrote: > I meant to send this to the mailing list, instead of an individual > person! > > Dee Sharpe > > > Sent from my iPhone > > Begin forwarded message: > > > > From: Dee Sharpe > > Date: November 22, 2009 9:44:22 AM CST > > To: Robert Noland > > Subject: Re: RFC: libdrm repo > > > > > > > So, none of the *BSD code will ever be used??? Does it even work or > > compile??? I hope so, since I've been using the *BSD code as a basis > > for a Syllable port. I find the *BSD code a bit easier to read. Have > > I been wasting my time??? No, probably not... But the code that is/was there is outdated since trying to track a seperate private repo for each hardware platform is more than difficult enough. Certain vendors decided that it was too much trouble to maintain their code and expected those that still wanted a multi-os multi-vendor repo to backport their code for them. This eventually forced all of the vendors to move to private repos. The place to see the current FreeBSD code is http://svn.freebsd.org/viewvc/base/head/sys/dev/drm/ robert. > > Dee Sharpe > > > > Sent from my iPhone > > > > On Nov 22, 2009, at 8:31 AM, Robert Noland wrote: > > > > > On Sun, 2009-11-22 at 19:01 +1000, Dave Airlie wrote: > > > > On Sun, Nov 22, 2009 at 7:10 PM, vehemens > > > > wrote: > > > > > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: > > > > > > > I see that you deleted bsd-core dispite the requests of a > > > > > > > number of > > > > > > > people that you do not. > > > > > > > > > > > > Its git, nobody has touched any of it in ages, and none of > > > > > > the BSD > > > > > > maintainers used it, you can just get it back by branching > > > > > > from the commit > > > > > > before its removal, if you think revival is needed, don't > > > > > > bring back > > > > > > linux-core when you do please. > > > > > > > > > > I already told the both of you that I was planning to use it > > > > > on IRC, I just > > > > > haven't had time to put anything in. > > > > > > > > > > In addition, he's asking for a repro to libdrm. The way I see > > > > > it, is there > > > > > were two choices: > > > > > 1) repro to libdrm, add the changes, not piss people off > > > > > 2) add the changes, repro to libdrm, piss people off > > > > > > > > I think we pissed one person off, not people, as I said, there > > > > are two > > > > people registered as BSD maintainers for drm code, oga and > > > > rnoland, > > > > neither of them cared. I'm not sure what value the codebase has > > > > if > > > > neither Free or OpenBSD are going to use it. > > > > > > > > Why bother adding code to a common tree that no operating system > > > > has any intention of shipping ever. > > > > > > Well, I think that it is safe to say that I really don't like > > > things as > > > they are. Under the circumstances however, the code there is > > > useless and > > > only provided minor historical value. > > > > > > robert. > > > > > > > Dave. > > > > > > > > -- > > > > Let Crystal Reports handle the reporting - Free Crystal Reports > > > > 2008 30-Day > > > > trial. Simplify your report design, integration and deployment - > > > > and focus on > > > > what you do best, core application coding. Discover what's new > > > > with > > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > > -- > > > > ___ > > > > Dri-devel mailing list > > > > dri-de...@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > -- > > > Robert Noland > > > 2Hip Networks > > > > > > > > > -- > > > Let Crystal Reports handle the reporting - Free Crystal Reports > > > 2008 30-Day > > > trial. Simplify your report design, integration and deployment - > > > and focus on > > > what you do best, core application coding. Discover what's new > > > with > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > -- > > > ___ > > > Dri-devel mailing list > > > dri-de...@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/dri-devel > = > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ Mesa3d-dev mailing list
Re: [Mesa3d-dev] Fwd: RFC: libdrm repo
Sadly, subversion doesn't work correctly on Syllable yet (at least, not for me). I'll see what I can do & try to figure out if it's even worth it to get another tree & rebase off that tree. -Original Message- From: Robert Noland To: Dee Sharpe Cc: mesa3d-dev@lists.sourceforge.net Sent: Sun, Nov 22, 2009 11:23 am Subject: Re: [Mesa3d-dev] Fwd: RFC: libdrm repo On Sun, 2009-11-22 at 10:04 -0600, Dee Sharpe wrote: > I meant to send this to the mailing list, instead of an individual > person! > > Dee Sharpe > > > Sent from my iPhone > > Begin forwarded message: > > > > From: Dee Sharpe > > Date: November 22, 2009 9:44:22 AM CST > > To: Robert Noland > > Subject: Re: RFC: libdrm repo > > > > > > > So, none of the *BSD code will ever be used??? Does it even work or > > compile??? I hope so, since I've been using the *BSD code as a basis > > for a Syllable port. I find the *BSD code a bit easier to read. Have > > I been wasting my time??? No, probably not... But the code that is/was there is outdated since trying to track a seperate private repo for each hardware platform is more than difficult enough. Certain vendors decided that it was too much trouble to maintain their code and expected those that still wanted a multi-os multi-vendor repo to backport their code for them. This eventually forced all of the vendors to move to private repos. The place to see the current FreeBSD code is http://svn.freebsd.org/viewvc/base/head/sys/dev/drm/ robert. > > Dee Sharpe > > > > Sent from my iPhone > > > > On Nov 22, 2009, at 8:31 AM, Robert Noland wrote: > > > > > On Sun, 2009-11-22 at 19:01 +1000, Dave Airlie wrote: > > > > On Sun, Nov 22, 2009 at 7:10 PM, vehemens > > > > wrote: > > > > > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: > > > > > > > I see that you deleted bsd-core dispite the requests of a > > > > > > > number of > > > > > > > people that you do not. > > > > > > > > > > > > Its git, nobody has touched any of it in ages, and none of > > > > > > the BSD > > > > > > maintainers used it, you can just get it back by branching > > > > > > from the commit > > > > > > before its removal, if you think revival is needed, don't > > > > > > bring back > > > > > > linux-core when you do please. > > > > > > > > > > I already told the both of you that I was planning to use it > > > > > on IRC, I just > > > > > haven't had time to put anything in. > > > > > > > > > > In addition, he's asking for a repro to libdrm. The way I see > > > > > it, is there > > > > > were two choices: > > > > > 1) repro to libdrm, add the changes, not piss people off > > > > > 2) add the changes, repro to libdrm, piss people off > > > > > > > > I think we pissed one person off, not people, as I said, there > > > > are two > > > > people registered as BSD maintainers for drm code, oga and > > > > rnoland, > > > > neither of them cared. I'm not sure what value the codebase has > > > > if > > > > neither Free or OpenBSD are going to use it. > > > > > > > > Why bother adding code to a common tree that no operating system > > > > has any intention of shipping ever. > > > > > > Well, I think that it is safe to say that I really don't like > > > things as > > > they are. Under the circumstances however, the code there is > > > useless and > > > only provided minor historical value. > > > > > > robert. > > > > > > > Dave. > > > > > > > > -- > > > > Let Crystal Reports handle the reporting - Free Crystal Reports > > > > 2008 30-Day > > > > trial. Simplify your report design, integration and deployment - > > > > and focus on > > > > what you do best, core application coding. Discover what's new > > > > with > > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > > -- > > > > ___ > > > > Dri-devel mailing list > > > > dri-de...@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > -- > > > Robert Noland > > > 2Hip Networks > > > > > > > > > -- > > > Let Crystal Reports handle the reporting - Free Crystal Reports > > > 2008 30-Day > > > trial. Simplify your report design, integration and deployment - > > > and focus on > > > what you do best, core application coding. Discover what's new > > > with > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > -- > > > ___ > > > Dri-devel mailing list > > > dri-de...@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/dri-devel > = > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new wit
[Mesa3d-dev] Fwd: Winsys
Forgot to just sent this to the Mesa mailing list! Dee -Original Message- From: demetrioussha...@netscape.net To: youne...@gmail.com Sent: Sat, 11 Apr 2009 1:44 pm Subject: Re: [Mesa3d-dev] Winsys Ok, now I have a better understanding of it all.? This means that I have to port the winsys driver to the Syllable appserver driver API.? Also, I'll have to port the other hw winsys drivers to the same API if I want acceleration with those chipsets.? This isn't much different than if I were porting a normal video driver to Syllable.? Doing softpipe first should give me what I need to know in order to port the others.? Thanks! Dee -Original Message- From: Younes Manton To: Dee Sharpe Cc: mesa3d-dev@lists.sourceforge.net Sent: Sat, 11 Apr 2009 11:03 am Subject: Re: [Mesa3d-dev] Winsys On Sat, Apr 11, 2009 at 9:06 AM, Dee Sharpe wrote: > So, this means I'll have to port the winsys for intel & radeon in > addition to a generic winsys for the OS if I want to use Intel & AMD > chipsets??? Each driver/API/OS combo needs a Winsys. Radeon/OpenGL/, Intel/OpenGL/, etc. It might be easier to get Softpipe/OpenGL/ running first. You can see what was done for Windows (src/gallium/winsys/gdi/gdi_softpipe_winsys.c) and X (src/gallium/winsys/xlib/xlib_softpipe.c). The Softpipe "driver" doesn't require a lot from the Winsys, just basically some memory to render to and a way to display it on the screen (via GDI blits, X putimages, etc). Real hardware drivers will require more from their Winsyses, like a way to communicate with their respective kernel modules (and you'll need your own kernel modules if you don't have DRM, I don't think it would be possible to do everything in the Winsys from userspace). Check all of your email inboxes from anywhere on the web. Try the new Email Toolbar now! -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Winsys
Ok, maybe I'm just completely dense.? I've asked this before with no reply & I've looked through the code and the relevant pages.? I still don't understand why there're driver families with their own winsys.? How're non-*nix platforms, that have to provide their own winsys, supposed to be able to use these drivers that have their own winsys??? Dee Sharpe -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Fwd: Re: Gallium HW Drivers & DRI/DRM
I forgot to CC the mesa3d list. Perhaps I should just reply to the list itself. Since we're all going to get these emails anyway, why bother sending them to our personal email accounts? Dee -Original Message- From: demetrioussha...@netscape.net To: mic...@daenzer.net Sent: Mon, 6 Apr 2009 8:22 pm Subject: Re: Gallium HW Drivers & DRI/DRM Ok, I'm starting to get a slight understanding of wheat's going on. I won't understand much more until I dive into the codebase a bit more. So, which branch should I be working on porting? Perhaps gallium-mesa-7.4? Or is there another one that's a better candidate or more of a mainline tree? Dee -Original Message- From: Michel Dänzer To: Dee Sharpe Cc: mesa3d-dev@lists.sourceforge.net Sent: Mon, 6 Apr 2009 8:20 am Subject: Re: Gallium HW Drivers & DRI/DRM On Mon, 2009-04-06 at 08:04 -0500, Dee Sharpe wrote: > Our persistent memory objects are called 'areas', but they're located > in main memory, is that an issue? Shouldn't be. > Also, does this mean that agp access should be initialized in winsys? Probably. > I'm assuming that the drivers have their own ways of handling VRAM. No, resource management is one of the things abstracted from the drivers themselves in the winsys modules. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer The Average US Credit Score is 692. See Yours in Just 2 Easy Steps! -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium HW Drivers & DRI/DRM
Ok, that sounds good.? What we have right now is a very simple 2d driver API that basically blits bitmaps from userspace to the screen.? Our drivers have a duality system.? They use a kernel driver for basic access to the card, but for many drivers, almost everything is MMIO, so the kernel driver doesn't get touched much after it's opened.? I ported the *BSD AGP driver, but I haven't taken advantage of AGP yet, because I wasn't sure of whether I wanted to handle it in the kernel driver or the userland driver; since the userland API has a very primitive memory management system.? I don't think it's used much & the memory is actually managed by the windowing system.? The only thing the video driver actually does, in that aspect, is give the windowing system a pointer to the framebuffer & the rest of the memory.? Otherwise, memory is just allocated in system RAM.? When you say the winsys interfaces with the kernel, do you mean the actual kernel, or the kernel space video driver? Dee -Original Message- From: Corbin Simpson To: demetrioussha...@netscape.net Cc: mesa3d-dev@lists.sourceforge.net; dri-de...@lists.sourceforge.net Sent: Sun, 5 Apr 2009 6:59 pm Subject: Re: [Mesa3d-dev] Gallium HW Drivers & DRI/DRM demetrioussha...@netscape.net wrote: > Sounds good, but here's the catch, I would like to use Gallium to accelerate the whole windowing system.? I want our windowing system to use libGL for all rendering, so Gallium would basically be running on the video card with no windowing system standing in the way. That's not a catch. That's what Gallium was designed to do. You're picturing something like this, I think: Windowing system -> OpenGL windowing system plugin -> kernel But you can do this: Windowing system -> Galliumized windowing system plugin -> kernel (I'm assuming that you already have a rendering plugin system so you can support different video cards in userspace.) If you break down this Galliumized plugin, it would consist of: Syllable state tracker + Syllable winsys + pipes (softpipe, i915, etc.) So the state tracker interfaces with windowing system, the winsys interfaces with kernel, and everything just works. Of course, I know next to nothing about Syllable. ~ C. -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium HW Drivers & DRI/DRM
Sounds good, but here's the catch, I would like to use Gallium to accelerate the whole windowing system.? I want our windowing system to use libGL for all rendering, so Gallium would basically be running on the video card with no windowing system standing in the way. Dee -Original Message- From: Corbin Simpson To: demetrioussha...@netscape.net Cc: mesa3d-dev@lists.sourceforge.net; dri-de...@lists.sourceforge.net Sent: Sun, 5 Apr 2009 6:38 pm Subject: Re: [Mesa3d-dev] Gallium HW Drivers & DRI/DRM demetrioussha...@netscape.net wrote: > So that means that I can get hardware acceleration by writing the winsys for Syllable, regardless of the fact that we don't use DRI/DRM?? I guess the main question is, "Do I have to use the DRI/DRM drivers in order to use the current hardware pipes?" And the main answer is, "no, DRI/DRM is not required." r300, i915, and i965 use a batchbuffer technique, and the nvxx pipes map the ring buffer into userspace, but none of them really know or care about how that's set up by the winsys. Your first target should probably be getting softpipe to run. Softpipe is, as the name suggests, a pipe that does all of its rendering in software, and it can run on top of any winsys. Wikipedia tells me that you guys are POSIX and Unix-like, but not using Xorg for your windowing system, so you will probably need a state tracker for your windowing system too. ~ C. -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium HW Drivers & DRI/DRM
So that means that I can get hardware acceleration by writing the winsys for Syllable, regardless of the fact that we don't use DRI/DRM?? I guess the main question is, "Do I have to use the DRI/DRM drivers in order to use the current hardware pipes?" Dee -Original Message- From: Corbin Simpson To: demetrioussha...@netscape.net Cc: dri-de...@lists.sourceforge.net; mesa3d-dev@lists.sourceforge.net Sent: Sun, 5 Apr 2009 5:07 pm Subject: Re: [Mesa3d-dev] Gallium HW Drivers & DRI/DRM Right now, in order to create a driver, you need to combine three pieces. The pipe is the core of acceleration for a given chipset. It contains all of the code necessary to accelerate things, and exposes two generic structs in the Gallium API: pipe_screen, which is information about the current chipset and buffer/memory setup, and pipe_context, which has methods for rendering things. You probably never need to touch this unless you're adding new chipsets to Gallium. The winsys is a series of bindings that connects a pipe to a windowing system or similar framework. It does this by exposing whatever APIs are needed. At first, DRI was the only API, but now we have a drm_api which can be used to generically and directly set up buffers and pipes for DRM-based drivers. The state tracker is just a library that internally uses a winsys, through drm_api or similar, to set up and use pipes. The external API that the state tracker exposes can be nearly anything; right now, we have state trackers for Xorg, DRI2, GLX, EGL, XvMC, and Python (SWIG). These can be mix'n'matched to come up with the actual driver binaries; for example, Xorg + radeon + r300 = Radeon r300 Xorg driver, EGL + intel + i915 = Intel i915 EGL driver, DRI2 + GLX + nouveau + nv50 = nVidia NV50 DRI2 driver. Obviously, non-DRM-based drivers will need winsys work for Syllable. I don't exactly know how Syllable's userland and kernel communicate; I assume there's some API that they use to talk to each other. You'd probably need to augment or invent winsys that can talk to Syllable's kernel. Then, you'd need a state tracker for Syllable's windowing system. You shouldn't have to touch any of the pipes. Hopefully this answers some questions. (And hopefully I don't have to get corrected by the more knowledgeable guys!) ~ C. -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Gallium HW Drivers & DRI/DRM
I'm not sure which list is the correct one to post these questions, so I'm posting to both.? All diagrams of the Gallium architecture show the ability of using Gallium in various OS's that are completely different with each other.? However, each diagram that has a specific graphics chipset (i915, i965, etc) also show DRI & DRM drivers for that same chipset.? This gives the impression that you need an i915 DRI/DRM combo if you plan on using the i915 Gallium HW driver that sits between the statetracker & winsys.? Is that absolutely necessary?? If it's not, how would an OS that doesn't use DRI/DRM use the standard Gallium HW drivers?? Is there a set API that could be implemented without DRI/DRM that allows these HW drivers to still be used?? I really would love to attemp to port Gallium to Syllable, however, there's just too many X-specific bits & pieces scattered throughout DRI/DRM for that to be feasible at this point.? Can you point me in the right direction? Dee Sharpe -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] R2xx
What a shameThanks! Dee Sharpe -Original Message- From: Alex Deucher <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: mesa3d-dev@lists.sourceforge.net; [EMAIL PROTECTED] Sent: Tue, 26 Aug 2008 8:54 am Subject: Re: [Mesa3d-dev] R2xx On Tue, Aug 26, 2008 at 9:48 AM, <[EMAIL PROTECTED]> wrote: > Does anyone know if the datasheets & programming guides for AMD's old R2xx > cards have been released? If so, where could I find them? They are not yet available without an NDA. Alex - 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=100&url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] R2xx
Does anyone know if the datasheets & programming guides for AMD's old R2xx cards have been released?? If so, where could I find them? Dee Sharpe - 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=100&url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
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: mesa3d-dev@lists.sourceforge.net Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net 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=100&url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] DRM question
Yeah, you're right on the money about the architecture, except that we also have a hardware specific userspace driver that the windowing system uses to either take care of video operations with MMIO or by sending the command to the kernel driver. My plan is to replace the kernel drivers with drm drivers. After that, I'll remove the windowing system's dependence on the video driver & instead link it to libGL. At that point, I would have already gotten DRI to build successfully. The one thing that really stumps me is providing DRM capabilities fully as they are in Linux, considering that a lot of our hardware abstractions are completely different. Also, is there any DRM state info that's stored and active in drm.ko? I've also tried to do this without touching the stuff in shared-core, but there are some things in there that doesn't quite fit with Syllable, but are needed for DRM. I may have to add some '#ifdef's' to a few of the headers. There are some things that pretty much expect to be compiled in an XWindow's environment. Also, we support shared object loading, however we can't reference functions from one driver to the next. Dee Sharpe -Original Message- From: Nicolai Hähnle <[EMAIL PROTECTED]> To: mesa3d-dev@lists.sourceforge.net Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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] cape.net: > 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=100&url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] DRM question
THIS EMAIL IS BEING SENT TO MULTIPLE MAILING LISTS IN HOPES THAT IT WILL REACH SOMEONE WHO WILL HELP ME Hello all, 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. Dee Sharpe P.S.? For anyone who follows Syllable, there was an attempt a few years ago to convience me of the virtues of DRI, but I wouldn't listen.? Consider me convienced, please help me. - 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=100&url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Fwd: Mesa design question
I mistakenly sent this to the wrong address.;) -Dee Sharpe -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tue, 3 Oct 2006 8:34 AM Subject: [Mesa3d-dev] Mesa design question What exactly does the dispatch table do. I understand that it is a function pointer table, however, I do not fully understand what the pros and cons of using it is. I see that Haiku's implementation now uses it. I am trying to evaluate it to see if it would benefit me in the design of the 3d driver foundation for Syllable. Any help that you can give me will be greatly appreciated. Thanks. -Dee Sharpe Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
