Re: [Dri-devel] Which DRI driver/card is usable for modern games?
I'm fully aware of the lack of documentation for recent graphics cards and the problems associated with that. Maybe the open source vs closed source problem is already a lost battle especially already. The situation seems to be much better for other HW such as audio cards, NICs, printers, etc needed by the kernel though, except maybe for WiFi cards. However, my original question remain: Which card is usable with DRI open source drivers for modern games? Also, is the S3TC issue resolved for the cards I mentioned before: Mach64, G400, Banshee and Radeon 9000 PRO. Since I'm replying to your mail Vladimir, how about the TV-out issue especially with the GATOS drivers and for XFree86/X.org in general. Are all these efforts in vain for GNU/Linux and other open source OSes. Only binary driver alternatives remains, or other OSes not to mention here.. On Thu, 2004-05-06 at 00:54, Vladimir Dergachev wrote: Is there any hope for open source drivers for high performance cards, taking into consideration the binary alternatives available for cards from ATI, Nvidia or Matrox (Parhelia), etc? One thing to keep in mind about this issue is that ATI and NVidia start working on their 3d drivers even before their cards are released yet. We are still asking for documentation for the next to latest generation of ATI cards (R300) (and, AFAIK, NVidia does not provide docs at all). So open source driver will always be late. However the question of how late depends a lot on how easy it is to program using current frameworks (i.e. Mesa, DRI, X11). best Vladimir Dergachev --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Which DRI driver/card is usable for modern games?
Svante Signell wrote: However, my original question remain: Which card is usable with DRI open source drivers for modern games? Also, is the S3TC issue resolved for the cards I mentioned before: Mach64, G400, Banshee and Radeon 9000 PRO. It's absolutely resolved for mach64, G400, and banshee: the hardware does NOT support it in any way, shape, or form. The Radeon 9000 Pro (a R200 like chip) supports it with some patches that are floating around. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 TexCoord3f patch for cubemaps
Ian Romanick wrote: Ian Romanick wrote: The one caveat with this patch is the x86 SSE codegen is disabled for all TexCoord and MultiTexCoord commands. If you look at the changes to r200_vtxfmt_c.c, you'll see that I had to make some changes to the way those routines work. The previous patch is committed. The attached patch adds x86 SSE codegen back. I've changed the way the codegen works just slightly. Each codegen stub consists of a bit of assembly code that needs to be reloced / fixed-up at run-time. Prepended to the assembly code is a small preamble that describes how to do this. The preamble contains the size of the assembly stub and array of fix-ups that need to be done. The stub code follows immediatly after the array of fix-ups. At run-time, the function r200_do_codegen is called to create the executable stub. It is passed a pointer to the stub's preamble and an array of fix-up values. Each entry in the stub's fix-up array specifies a size, an offset in the stub, and an element index to use for the fix-up. This is similar to how a reloc table works in an object file. There are two obvious advantages. If a stub is modified, it is likely that only one file (the file containing the stub) needs to be updated. Code size (in the form of FIXUP macros) is cut way down. There are a couple of advantages to this that aren't fully realized in this code. This is a *lot* more cross-platform. The only difference between r200_makeX86TexCoord2f and r200_makeSSETexCoord2f (and the non-existent r200_makePowerPCTexCoord2f) is a single pointer passed to r200_do_codegen. This should make it possible to cut down on a lot of redundant code. Additionlly, since the codegen stubs contain all the information needed to do the fix-ups, it should be possible to share common assembly stubs in multiple places (i.e., _x86_Vertex3f in r200, radeon, and t_vertex). One disadvantage is if the codegen_stub structure is changed. If that structure is changed, all of the assembly files will also have to change. However, there won't be any compiler warnings for any that are missed. We'll just get mysterious codegen related bugs. :( Another disadvantage is that this code seems to be more prone to cut-and-paste type errors. If this new method is acceptable to everyone, I'll modify the rest of the codegen stubs in the R200 driver to use it. I'd really like to put some form of r200_do_codegen in a shared location so that other places that do codegen can re-use it. I can't help thinking there's a right way to do these fixups and we're just not using it. For instance, I don't know how the assembler marks addresses requiring relocation so that ld.so can find them efficiently later on - or whether we could use the same or simlar mechanism. I know linux does a related trick with its copy_from_user code by emitting labels or pointers to another section of the object file. It seems like your approach still involves guessing (or pre-calculating) offsets into the generated machine-code. We've done a slightly different thing in the t_vtx_* codegen by using a distinctive dword (0x10101010+n, as it turns out), and basically doing a search replace on that value, which seems to work. The C code still knows which order the fixups are supposed to occur in the code being fixed up. I guess the approaches could be combined, so that the 'n' value took on the same meaning as the 'entry' field in your structs, so that you might get something like: GLOBL( _x86_MultiTexCoord2fv_stub ) .long _x86_MultiTexCoord2fv_end - _x86_MultiTexCoord2fv .long 2 .long 4, FIXUP(0), 0 .long 4, FIXUP(1), 1 _x86_MultiTexCoord2fv: movl4(%esp), %eax movl8(%esp), %ecx and $TEX_TARGET_MASK, %eax movlFIXUP(0)(,%eax,4), %edx # texcoord_size[unit] is 1, 2, or 3 movlFIXUP(1)(,%eax,4), %eax # texcoord_ptr[unit] decl%edx jne .3_2fv movl(%ecx), %edx movl%edx, (%eax) ret etc. Secondly, I see you're using a single TexCoord2f function to cope with all possible sizes of the texcoord in the actual emitted vertex. This is certainly the simplest appraoch, but it's worth pointing out that it's possible to have multiple versions of TexCoord2f, etc which are specialized for each emitted texcoord size, and thereby eliminate the branches in your code. It's probably not significant, though. Keiht --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] new API/DRM/fb discsusion..
why do I get the impression we are discussing kgi or at least the goals of kgi? without mentioning it ..is kgi a bad word around these parts? :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
Jon Smirl writes: I'm putting together a document for Kernel Summit that describes the issues around graphics device drivers. The kernel developers are currently making first pass comments on it. As soon as I fold their comments in I'll post it to fb-dev, dri-dev and wherever else is appropriate for the next round of comments. Nobody is proposing final solutions yet, I'm just trying to collect everyone's opinion. I fear that we will get a very Linux-centric view on device drivers. This will leave us with device drivers for Linux and a different ones (or none!) for the rest of the world. From an X developers point of view this is a support nightmare as he is the first one users will turn to if things don't work as expected. Furthermore I'd argue that as little as necessary should live in the kernel space. One thing that - in my opinion - should *not* live in there is mode detection and initialization. First of all, we will not be able to do generic VESA mode initialization in the kernel (unless we decide to stick a complete x86 emulator into the kernel). Then many driver developers often take a very naive apporach at things and produce code that I know I don't want to see in my kernel. One can try to educate them which may not always be possible - especailly in the case of closed source drivers. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Which DRI driver/card is usable for modern games?
However, my original question remain: Which card is usable with DRI open source drivers for modern games? Also, is the S3TC issue resolved for the cards I mentioned before: Mach64, G400, Banshee and Radeon 9000 PRO. Since I'm replying to your mail Vladimir, how about the TV-out issue especially with the GATOS drivers and for XFree86/X.org in general. Are Federico Ulivi has written a TV-out driver for Radeon cards. AFAIK it works with R100 and R200 cards that use Rage Theatre for TV-out. (This excludes some laptop chipsets, some VE cards and newer cards that use Rage Theatre 200). all these efforts in vain for GNU/Linux and other open source OSes. Only binary driver alternatives remains, or other OSes not to mention here.. Not necessarily.. Besides, keep in mind that sometimes there is no binary alternative (for most WiFi cards for example). Also, I think Intel has been playing nice - they released some code for their Centrino WiFi, and, looking in the DRI CVS, they have their graphics chipsets supported too. (Please correct me if I am wrong here). best Vladimir Dergachev On Thu, 2004-05-06 at 00:54, Vladimir Dergachev wrote: Is there any hope for open source drivers for high performance cards, taking into consideration the binary alternatives available for cards from ATI, Nvidia or Matrox (Parhelia), etc? One thing to keep in mind about this issue is that ATI and NVidia start working on their 3d drivers even before their cards are released yet. We are still asking for documentation for the next to latest generation of ATI cards (R300) (and, AFAIK, NVidia does not provide docs at all). So open source driver will always be late. However the question of how late depends a lot on how easy it is to program using current frameworks (i.e. Mesa, DRI, X11). best Vladimir Dergachev --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
Another request is that this work be compared to the kgi work so that we don't repeat the same mistakes. I wasn't around for that debate, can someone explain what was learned from attempt? I'll start reworking the proposal to include the feedback I have so far and get it ready for the next round. I suspect the next round on the DRI/FB lists will generate a lot more flames. The graphic driver issue is heating up because MS Longhorn is focusing on accelerated graphics as a major feature. --- Dave Airlie [EMAIL PROTECTED] wrote: why do I get the impression we are discussing kgi or at least the goals of kgi? without mentioning it ..is kgi a bad word around these parts? :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
--- Egbert Eich [EMAIL PROTECTED] wrote: I fear that we will get a very Linux-centric view on device drivers. This will leave us with device drivers for Linux and a different ones Tell me the right non-Linux lists and I will post there too. There have been significant complaints from the Linux kernel developers over the current DRM code. Most of it centers around the crossplatform support. Better division of the platform specfic code from the generic code should address these. kernel space. One thing that - in my opinion - should *not* live in there is mode detection and initialization. I'm making some progress on this front. I think I've talked benh into it, and he's started talking to Linus about it. If Linux goes this path then is someone going to move the other platforms onto this path too? Support is starting to grow for merging FB/DRM into a simgle driver. --- Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: The proposal is for a user space library that does mode setting as well as other common things like cursor support. This library would in turn load plug-in libraries for each card. Ok, we have been discussing all of these points over and over again, and I will be at KS, so I didn't want to restart the whole thing on this list, but I wanted to note a few things though: For the mode setting case the library would read the DDC data for each head using the existing I2C drivers or the driver plug-in lib for non-standard cases. This data would then be combined with config files where the user can override modelines and such. I agree with the idea of moving the EDID decoding mode selection to userland. In this regard, though, I beleive we should aim toward some simple library that sits with the kernel, eventually distributed with the kernel tree, to live in initramfs optionally since it may be required to even get a console at boot (which is fine, initramfs is available early). The video cards themselves have PCI drivers that can trigger detection by the library via hotplug, the library could manage things like persistant configuration, either separate desktops or geometry of a complex desktop, etc... and eventually notification of userland clients of mode changes. One reason for that is lots of monitors lie about their capabilities in their EDID block, so we want override files. The kernel driver in this case doesn't need to be that much different than the current fbdev's though, except that we want to move the HW access for graphics commands to the kernel too, which basically turns into merging the DRI driver and the fbdev. There is no need, I think, to re-invent the wheel from scratch here, it would be a lot more realistic to build on top of those existing pieces. The modelines would be passed into the plug-in libs which would turn them into register values. Finally the plug-in lib would use a private IOCTL to set the state into the video hardware. Note that there are side effect. Changing the mode on a head can trigger a mode change on another. That typically happen when doing things like mirroring in which case you may want to turn your mirrored screen into a mode whose aspect ration is compatible with the second screen. (Typically the case with non-4:3 LCD laptop screens mirroring to 4:3 CRTs). In general, the thing should be designed so that clients can be notified at any time of configuration changes. That along with a lower level arbitration mecanism on actual hardware access. There are numerous pros and cons for both a both schemes. The user space code is swappable, easier to debug, and does not need to be run as root. Cons are that these are more pieces to track. Device driver code is minimized. On the other hand boot time mode setting forces the code back into the kernel. Early user space should also be considered. It may be possible to use the BIOS for display until early user space is there, then change the mode. There's only about a screenful of display before early user space starts. If the userland code is in initramfs, it can be run very early, we can use a small text engine like pmac btext for early debugging if necessary. A side effect of the whole mode setting issue is dual/tri head cards. Once there are multiple heads with multiple framebuffers. FB is going to have to start mem managing the VRAM which it does not currently do. DRI runs a memory manager over the same VRAM and this is a conflict. Yes, that, access arbitration, and config change notifications are the main issues at this time. Another conflict is that the OpenGL/xserver can move the display framebuffer around in memory, for example when going full screen on video. It will be complicated to coordinate the location of the current scan buffers between xserver and fb. Currently Xfree can't do this so it isn't a problem. Ben. = Jon Smirl [EMAIL PROTECTED]
Re: [Dri-devel] Memory management of AGP and VRAM
--- Egbert Eich [EMAIL PROTECTED] wrote: Jon Smirl writes: I'm putting together a document for Kernel Summit that describes the issues around graphics device drivers. The kernel developers are currently making first pass comments on it. As soon as I fold their comments in I'll post it to fb-dev, dri-dev and wherever else is appropriate for the next round of comments. Nobody is proposing final solutions yet, I'm just trying to collect everyone's opinion. I fear that we will get a very Linux-centric view on device drivers. This will leave us with device drivers for Linux and a different ones (or none!) for the rest of the world. From an X developers point of view this is a support nightmare as he is the first one users will turn to if things don't work as expected. We also have to consider the trade off between the interfaces a modern graphics driver needs verses maintianing multi-platform availability. If linux merges the FB/DRM drivers and moves certain things to the kernel, there is nothing stopping other OS kernel developers from adding similar features to their kernels, potentially even re-using the linux fb/drm model (pending licenses). If X standardizes on an interface to hardware, we can leave it up to the kernel people to implement that interface. X develpers won't have to worry about re-implementing support for various buses and quirks that the OS already handles. OSes that choose not to support the new interfaces can always fall back on the older releases of X. Future chipsets may not even be useable down the road in the current model. Furthermore I'd argue that as little as necessary should live in the kernel space. One thing that - in my opinion - should *not* live in there is mode detection and initialization. First of all, we will not be able to do generic VESA mode initialization in the kernel (unless we decide to stick a complete x86 emulator into the kernel). Then many driver developers often take a very naive apporach at things and produce code that I know I don't want to see in my kernel. One can try to educate them which may not always be possible - especailly in the case of closed source drivers. Egbert. __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
--- Egbert Eich [EMAIL PROTECTED] wrote: Jon Smirl writes: I'm putting together a document for Kernel Summit that describes the issues around graphics device drivers. The kernel developers are currently making first pass comments on it. As soon as I fold their comments in I'll post it to fb-dev, dri-dev and wherever else is appropriate for the next round of comments. Nobody is proposing final solutions yet, I'm just trying to collect everyone's opinion. I fear that we will get a very Linux-centric view on device drivers. This will leave us with device drivers for Linux and a different ones (or none!) for the rest of the world. From an X developers point of view this is a support nightmare as he is the first one users will turn to if things don't work as expected. We also have to consider the trade off between the interfaces a modern graphics driver needs verses maintianing multi-platform availability. If linux merges the FB/DRM drivers and moves certain things to the kernel, there is nothing stopping other OS kernel developers from adding similar features to their kernels, potentially even re-using the linux fb/drm model (pending licenses). If X standardizes on an interface to hardware, we can leave it up to the kernel people to implement that interface. X develpers won't have to worry about re-implementing support for various buses and quirks that the OS already handles. OSes that choose not to support the new interfaces can always fall back on the older releases of X. Future chipsets may not even be useable down the road in the current model. Furthermore I'd argue that as little as necessary should live in the kernel space. One thing that - in my opinion - should *not* live in there is mode detection and initialization. First of all, we will not be able to do generic VESA mode initialization in the kernel (unless we decide to stick a complete x86 emulator into the kernel). Then many driver developers often take a very naive apporach at things and produce code that I know I don't want to see in my kernel. One can try to educate them which may not always be possible - especailly in the case of closed source drivers. Egbert. __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
Jon, This issue of whether or not to use kgi goes all the way back to design decisions we made in 1998. Based on my recollection, I believe these were the top issues: 1) kgi was Linux specific. We needed a kernel level module that was more portable. 2) We wanted the bare minimum services in the kernel layer for efficient and fast graphics support, and felt as much of the driver code as possible should stay in user space. 3) GPL License. We needed a BSD style license to allow IHV's the option of a closed source driver. These are the issues I remember from 1998. I'm sure our requirements have evolved since then, but hopefully this short list will give a little insight into our thinking at that time. Jon Smirl wrote: Another request is that this work be compared to the kgi work so that we don't repeat the same mistakes. I wasn't around for that debate, can someone explain what was learned from attempt? I'll start reworking the proposal to include the feedback I have so far and get it ready for the next round. I suspect the next round on the DRI/FB lists will generate a lot more flames. The graphic driver issue is heating up because MS Longhorn is focusing on accelerated graphics as a major feature. --- Dave Airlie [EMAIL PROTECTED] wrote: why do I get the impression we are discussing kgi or at least the goals of kgi? without mentioning it ..is kgi a bad word around these parts? :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
On Thu, 6 May 2004, Jon Smirl wrote: --- Jens Owen [EMAIL PROTECTED] wrote: 2) We wanted the bare minimum services in the kernel layer for efficient and fast graphics support, and felt as much of the driver code as possible should stay in user space. Linux kernel people are strongly in favor of changing Xfree to never touch the hardware except through device drivers. I have to agree with that, Xfree is doing a lot of things that are never going to work in a hotplug system. The only way to make hotplug work is for Xfree to tell the kernel what it is doing. Also, I would venture an opinion that, at the moment, the only Unices we care about is Linux, BSD and Hurd - all open source. The current design of XFree86 (with everything done in userspace) was motivated by the need to support commercial Unices (like Solaris or Unixware). 3) GPL License. We needed a BSD style license to allow IHV's the option of a closed source driver. Top proposal right now is to merge FB and DRM. FB has the GPL license with too many developers so it probably can't be converted to BSD. I would imagine that parts of fb and drm would need to be rewritten to accomodate new requirements. What about making new interfaces LGPL - this should work fine with both GPL and non-GPL software ? There are many advatanges to merging FB/DRM. Top ones include SAK, secure attention key, kdbg support, OOPS while X is running, mode support for mesa-solo, etc I would be delighted to have km functionality (GATOS capture module) merged into DRM/FB combination. best Vladimir Dergachev What is the state of the FB equivalent on BSD? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Which DRI driver/card is usable for modern games?
On Thu, May 06, 2004 at 09:04:28AM +0200, Svante Signell wrote: Also, is the S3TC issue resolved for the cards I mentioned before Browse dri-devel archive, there was patch for software S3TC support. -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
John, You can think of me as Old School, and take my feedback in that context. My main reason for participating in this discussion is to give some historical perspective. Jon Smirl wrote: --- Jens Owen [EMAIL PROTECTED] wrote: 2) We wanted the bare minimum services in the kernel layer for efficient and fast graphics support, and felt as much of the driver code as possible should stay in user space. Linux kernel people are strongly in favor of changing Xfree to never touch the hardware except through device drivers. I have to agree with that, Xfree is doing a lot of things that are never going to work in a hotplug system. The only way to make hotplug work is for Xfree to tell the kernel what it is doing. Six years ago, most devices could not handle this type of restriction efficiently. Things have improved on the high end; but the low end devices, are still very similar to what we had back in the day. Even today, I would be very cautious of deploying an architecture where no devices can be touched from user space. This will really box many driver developers into a corner they can't get out of. Is that worth it for support of graphics pipeline hot plugging? If you would like to get a flavor for the issue I'm writing about, simply unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I think you'll find many difficult issues crop up related to software fall backs and efficient readback pixel data. 3) GPL License. We needed a BSD style license to allow IHV's the option of a closed source driver. Top proposal right now is to merge FB and DRM. FB has the GPL license with too many developers so it probably can't be converted to BSD. There are many advatanges to merging FB/DRM. Top ones include SAK, secure attention key, kdbg support, OOPS while X is running, mode support for mesa-solo, etc I guess it really just depends on who your target user base is for your architecture. I'm a strong supporter of open source, especially at the infrastructure level; but I have a pragmatic view of IHV's and their need (or perceived need) to withold sources at the module level. If you're not targetting an all inclusive base of IHV's and kernels, then life is much easier for you, and you don't have to worry about the licensing issue. What is the state of the FB equivalent on BSD? It's certainly further along than it was in 1998, but I'm not the right person to ask. If you don't make any progress on their kernel lists, contact me directly, and I can put you in touch with my BSD contacts. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
Around 9 o'clock on May 6, Jens Owen wrote: If you would like to get a flavor for the issue I'm writing about, simply unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I think you'll find many difficult issues crop up related to software fall backs and efficient readback pixel data. I had the impression that this architecture would continue to permit the frame buffer to be mapped into user space. -keith pgp0.pgp Description: PGP signature
Re: [Dri-devel] new API/DRM/fb discsusion..
--- Jens Owen [EMAIL PROTECTED] wrote: Six years ago, most devices could not handle this type of restriction efficiently. Things have improved on the high end; but the low end devices, are still very similar to what we had back in the day. Even today, I would be very cautious of deploying an architecture where no devices can be touched from user space. This will really box many driver developers into a corner they can't get out of. Is that worth it for support of graphics pipeline hot plugging? If you would like to get It not's the graphics cards that are being hotplugged, it's other cards in the system. If xfree hasn't coordinated with the kernel, the kernel hotplug code could easily map the new hardware right on top of the Xfree HW. a flavor for the issue I'm writing about, simply unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I think you'll find many difficult issues crop up related to software fall backs and efficient readback pixel data. Framebuffer access follows the rules; kernel calls are used to map it into user space. The major violations in X are in PCI bus and graphics chip probing. BTW, the mesa-solo radeon driver does not map the framebuffer from the driver or user space. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
Jon Smirl wrote: Framebuffer access follows the rules; kernel calls are used to map it into user space. The major violations in X are in PCI bus and graphics chip probing. If mmapping is okay, then we're still able to touch hardware from user space drivers. I'm fine with that. I don't see any problem with requiring probing to be handled by a kernel space driver, especially since this isn't done a performance critical times. BTW, the mesa-solo radeon driver does not map the framebuffer from the driver or user space. The original radeon Mesa Subset driver that Keith W. wrote didn't have any software fallbacks. If you re-enable a full Mesa driver, I think you'll find it very challenging to support all the necessary software fallbacks without a memory map of the framebuffer...but luckly it doesn't sound like memory mapping the device is a problem. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
Jon Smirl wrote: --- Jens Owen [EMAIL PROTECTED] wrote: Six years ago, most devices could not handle this type of restriction efficiently. Things have improved on the high end; but the low end devices, are still very similar to what we had back in the day. Even today, I would be very cautious of deploying an architecture where no devices can be touched from user space. This will really box many driver developers into a corner they can't get out of. Is that worth it for support of graphics pipeline hot plugging? If you would like to get It not's the graphics cards that are being hotplugged, it's other cards in the system. If xfree hasn't coordinated with the kernel, the kernel hotplug code could easily map the new hardware right on top of the Xfree HW. This doesn't sound like a huge problem, XFree could simply inform the kernel about what it has done, or use a kernel api to do the mappings for it. It doesn't seem to require moving the driver to kernel space. Keith --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Redesign of kernel graphics interface
At the X Developers Conference there was a discussion of the issues around framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for discussion. I'm going to try and list all of the issues I've heard from all sides so some of the proposed solutions are in conflict. The goal of this list is to provide direction for a topic discussion at the Ottawa Kernel Summit. The top item is that accessing the video hardware is a free for all. There are two device drivers, FB and DRI, plus numerous user space apps, like X and SVGlib, all trying to control the hardware. The result of this is that it is easy to lock up your machine when switching between the different usages. X does particularly nasty things to the hardware from user space without informing the kernel. First is a little background that should have been in my original post: http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/000399.html Next is the orginal post: http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/000379.html The reply thread on the kernel summit list is here: http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/thread.html Some talk about doing a better video memory manager and kgi is here: http://marc.theaimsgroup.com/?l=dri-develr=1b=200405w=2 A major topic that I missed in the original list was how to handle BSD. DRM is under the BSD license and FB is GPL. If these two code bases are merged, what are we going to do about BSD? I don't know the appropriate BSD lists to post this to so please forward as necessary. Another topic that I missed was, why did kgi fail and what can we do to avoid repeating the same path this time around. After the flames from this settle down I'll try to write a document summarizing the conclusions reached, if any. The best possible outcome would be a design document for review at Kernel Summit. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
Vladimir Dergachev wrote: Also, I would venture an opinion that, at the moment, the only Unices we care about is Linux, BSD and Hurd - all open source. The current design of XFree86 (with everything done in userspace) was motivated by the need to support commercial Unices (like Solaris or Unixware). Ooops, is it true that support for Solaris is supposed to be dropped ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
Martin Spott wrote: Vladimir Dergachev wrote: Also, I would venture an opinion that, at the moment, the only Unices we care about is Linux, BSD and Hurd - all open source. The current design of XFree86 (with everything done in userspace) was motivated by the need to support commercial Unices (like Solaris or Unixware). Ooops, is it true that support for Solaris is supposed to be dropped ? I doubt it. Even if it was, this isn't the list for making that decision. Keith --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
On Thu, 6 May 2004, Keith Whitwell wrote: Jon Smirl wrote: --- Jens Owen [EMAIL PROTECTED] wrote: Six years ago, most devices could not handle this type of restriction efficiently. Things have improved on the high end; but the low end devices, are still very similar to what we had back in the day. Even today, I would be very cautious of deploying an architecture where no devices can be touched from user space. This will really box many driver developers into a corner they can't get out of. Is that worth it for support of graphics pipeline hot plugging? If you would like to get It not's the graphics cards that are being hotplugged, it's other cards in the system. If xfree hasn't coordinated with the kernel, the kernel hotplug code could easily map the new hardware right on top of the Xfree HW. This doesn't sound like a huge problem, XFree could simply inform the kernel about what it has done, or use a kernel api to do the mappings for it. It doesn't seem to require moving the driver to kernel space. One problem that I encountered is that DRM driver does not know how to reinitialize video mode in case of a lockup. So it would be real nice to have DRM and FB merged so that a failed WaitForIdle could reinit the hardware and call FB mode setting code to restore video mode. Thus this part of 2d driver *wants* to be inside the kernel. As far as acceleration - either 2d or 3d - it makes sense for it to stay in userspace.. best Vladimir Dergachev Keith --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
On Thu, 6 May 2004, Martin Spott wrote: Vladimir Dergachev wrote: Also, I would venture an opinion that, at the moment, the only Unices we care about is Linux, BSD and Hurd - all open source. The current design of XFree86 (with everything done in userspace) was motivated by the need to support commercial Unices (like Solaris or Unixware). Ooops, is it true that support for Solaris is supposed to be dropped ? No, no, I was simply speaking from personal perspective. For example, a couple of years ago I was making a specific effort to make my code as much user-space as possible, just for portability sake, but I decided to stop doing it. Writing drivers for Linux is involving enough and if no stupid architecture decisions are made the port to Hurd or BSD should not be too difficult. best Vladimir Dergachev Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] new API/DRM/fb discsusion..
--- Vladimir Dergachev [EMAIL PROTECTED] wrote: As far as acceleration - either 2d or 3d - it makes sense for it to stay in userspace. X and everything else needs to stop mapping the registers to user space and instead start using an IOCTL interface to a driver. The problem is that X or whatever sets a bunch of register values. Then a VT swap happens and something else writes all over those register values. The kernel driver is needed to track this state and restore it on VT swap. Simple example, DRM starts GPU coprocessor running. VT swap happens. New user stops coprocessor. VT swap back to DRM. Now DRM thinks it left the coprocessor running but that's not true now. DRM and FB conflict when FB is using the coprocessor for accelerated text. We can tell everyone to implement save/restore functions for VT swap. But the save/restore function for DRM is going to have to save all of the registers, VRAM, AGP space, coprocessor state, etc. This is a huge amount of state to save. It is much better to have a common driver. With a common driver the state save/restore problem goes away. Timesharing device drivers on the graphics hardware at VT swap is a very broken design. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] problems with compressed textures
developers, I am having experiancing a sementation fault when calling glCompressedTexImage2DARB. I have checked the pointer returned from GetProcAddress and it seems to be valid (not NULL). i placed a breakpoint in teximage.c (a mesa source file) on the function _mesa_CompressedTexImage2DARB. I am not getting to this mesa function before the segmentation fault. The debugger is giving me fits and i can not look at a backtrace to determine where the crash occurred. even loading a core dump yields no useful information. My question is what should i check? how do i determine if the pointer returned is actually the right one? is _mesa_CompressedTexImage2DARB is obviously not called directly by glCompressedTexImage2DARB, so how does it get called? this last question is related to flow, has does an opengl call in an application make it to the appropriate place in the driver? mark
[Dri-devel] Re: [Mesa3d-users] XQueryExtension problem ?
Sérgio Monteiro Basto wrote:
Hi
I find on internet morpheus-0.3 project.
and had had this problem:
#gdb morpheus
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
This GDB was configured as i386-redhat-linux-gnu...Using host
libthread_db library /lib/libthread_db.so.1.
(gdb) run
Starting program: /usr/local/bin/morpheus
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 7185)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 7185)]
0x40328227 in XQueryExtension () from /usr/X11R6/lib/libX11.so.6
(gdb) bt
#0 0x40328227 in XQueryExtension () from /usr/X11R6/lib/libX11.so.6
#1 0x404c07b3 in glXQueryExtension (dpy=0x0, errorBase=0x0,
eventBase=0x0) at glxcmds.c:758
#2 0x40470884 in gdk_gl_query () from /usr/lib/libgtkgl.so.5
#3 0x0804b8d4 in main (argc=1, argv=0x40473150) at main.c:189
The gdk_gl_query function comes in gtkglarea-1.2.2-17 rpm.
finding gdk_gl_query in code, only this lines in ./src/main.c
if( gdk_gl_query() == FALSE ) {
g_print( no OpenGL capability\n );
return 0;
}
Well, I deleted this 4 lines from code and morpheus works well.
I try this with mesa from cvs+savage dri and in other computer with
XFree4.4 from cvs and with X.org R6.7 compiled from sources,
the difference was when morpheus runed with XFree4.4 instead of
Segmentation fault, gdk_gl_query() return FALSE.
I'm cross-replying to the DRI list in case anyone there is familiar
with the problem. Though, I don't really understand what you're
saying at the end.
-Brian
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] problems with compressed textures
Mark Cass wrote:
developers,
I am having experiancing a sementation fault when calling
glCompressedTexImage2DARB. I have checked the pointer returned from
GetProcAddress and it seems to be valid (not NULL). i placed a
breakpoint in teximage.c (a mesa source file) on the function
_mesa_CompressedTexImage2DARB. I am not getting to this mesa function
before the segmentation fault. The debugger is giving me fits and i can
not look at a backtrace to determine where the crash occurred. even
loading a core dump yields no useful information.
gdb has always worked for me, as long as libGL and the driver are
compiled with -g.
My question is what should i check? how do i determine if the pointer
returned is actually the right one? is _mesa_CompressedTexImage2DARB is
obviously not called directly by glCompressedTexImage2DARB, so how does
it get called? this last question is related to flow, has does an opengl
call in an application make it to the appropriate place in the driver?
When you call glCompressedTexImage2DARB, you're calling a function in
libGL, either implemented in C or x86 assembly.
The C code is implemented with macro/template code (see dispatch.c and
glapitemp.h), but boils down to something like this:
void glCompressedTexImage2DARB(GLenum target, GLint level, GLenum
internalformat, GLsizei width, GLsizei height, GLint border, GLsizei
imageSize, const GLvoid * data)
{
_glapi_Dispatch-CompressedTexImage2DARB, target, level,
internalformat, width, height, border, imageSize, data);
}
The alternate assembly code is:
ALIGNTEXT16
GLOBL_FN(GL_PREFIX(CompressedTexImage2DARB,[EMAIL PROTECTED]))
GL_PREFIX(CompressedTexImage2DARB,[EMAIL PROTECTED]):
MOV_L(CONTENT(GLNAME(_glapi_Dispatch)), EAX)
JMP(GL_OFFSET(_gloffset_CompressedTexImage2DARB))
In either case, the variable '_glapi_Dispatch' is a pointer to the
dispatch table (a big struct of function pointers). The entry for
CompressedTexImage2DARB typically points to the
_mesa_CompressedTexImage2DARB function. This assignment is done in
the mesa/src/main/state.c file.
The use of a dispatch table lets us efficiently switch between
immediate mode and display list mode, between direct and indirect
rendering mode, and thread-safe and non-threadsafe mode.
-Brian
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
--- Nicolas Souchu [EMAIL PROTECTED] wrote: A major topic that I missed in the original list was how to handle BSD. DRM is under the BSD license and FB is GPL. If these two code bases are merged, what are we going to do about BSD? I don't know the appropriate BSD lists to post this to so please forward as necessary. What is exactly your question concerning licenses? FB is GPL licensed. DRM is BSD licensed. If FB and DRM are merged the end result will be GPL licensed code because of the way the licenses work. To change that you would have to get permission from every FB contributor to relicense their contribution from GPL to BSD. I suspect that it is pratically impossible to track all of the FB contributors down and what do you do if some won't cooperate? If the FB/DRM combo is GPL it can't be merged back into the BSD kernels. What we could do is build a merged driver and continue to have some of the source files licensed BSD and some GPL. The big reason for merging is memory management. If FB supports multiple heads it is forced into doing memory management. DRI has memory management needs that go far beyond what FB needs so a merged system has to use DRM memory management. Ian has made proposals on how to do this and he is working on improving them. BenH and others have made proposals for pushing the mode setting code into a user space library in order to reduce kernel footprint and ease debugging. Most of the code needed for this library already exists in the current Linux FB drivers. I'm not sure if this could be relicensed BSD when it is moved to user space. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Thu, May 06, 2004 at 11:16:39AM -0700, Jon Smirl wrote: At the X Developers Conference there was a discussion of the issues around framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for discussion. I'm going to try and list all of the issues I've heard from all sides so some of the proposed solutions are in conflict. The goal of this list is to provide direction for a topic discussion at the Ottawa Kernel Summit. [...] A major topic that I missed in the original list was how to handle BSD. DRM is under the BSD license and FB is GPL. If these two code bases are merged, what are we going to do about BSD? I don't know the appropriate BSD lists to post this to so please forward as necessary. What is exactly your question concerning licenses? Another topic that I missed was, why did kgi fail and what can we do to avoid repeating the same path this time around. KGI failed to be accepted by linus/linux. You surely don't want repeating this ;) Otherwise, its design is still valid, I believe. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
Alex Deucher writes: We also have to consider the trade off between the interfaces a modern graphics driver needs verses maintianing multi-platform availability. If linux merges the FB/DRM drivers and moves certain things to the kernel, there is nothing stopping other OS kernel developers from adding similar features to their kernels, potentially even re-using the linux fb/drm model (pending licenses). If X standardizes on an 1. We are not only supporting OS kernels. And if we do there may exist licenses problems (as you've noted already). Disfranchising these OSes and showing them the finger would be extremely rude. 2. A single code base with thin abstraction wrappers will help to reduce the support burdeon. Requiring to duplicate code in different kernels will introduce different errors on every OS. interface to hardware, we can leave it up to the kernel people to implement that interface. X develpers won't have to worry about re-implementing support for various buses and quirks that the OS already handles. OSes that choose not to support the new interfaces I agree that we should get rid of this crap. When we were finalizing XFree86 4.x I already suggested to move a lot of functionalities that currently exist in the Xserver to the kernel. At this time I was stonewalled by people saying that we will have to be able to support older kernels anyway. Finally I gave up and stuck everything into the Xserver (even duplicating stuff that was already in the newer kernel - because people wanted to use the old cruft) can always fall back on the older releases of X. Future chipsets may not even be useable down the road in the current model. That would be a support nightmare. We still occasionally see bug reports for XFree86 3.x. We probably can dump a lot of the stuff that is currently in the Xserver into an external lib and not worry about it much any more. This lib can be used by everybody who - for whatever reason - doesn't have the kernel interfaces. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Thu, 6 May 2004, Jon Smirl wrote:
Another topic that I missed was, why did kgi fail and what can we do to avoid
repeating the same path this time around.
IIRC, the main reasons were:
- GGI wanted to do too much at once and was too intruisive (conclusion:
always advance in small steps, not big leaps):
o kernel graphics drivers (KGI)
o new input subsystem (similar to what we're heading to now)
o user space library (libggi, AFAIK the only part that's still alive)
- fbdev was better in multi-platform handling (m68k - PPC - ia32 - SPARC
- alpha - ...)
Please correct me if I'm wrong ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-users] XQueryExtension problem ?
The gdk_gl_query function comes in gtkglarea-1.2.2-17 rpm.
finding gdk_gl_query in code, only this lines in ./src/main.c
if( gdk_gl_query() == FALSE ) {
g_print( no OpenGL capability\n );
return 0;
}
Well, I deleted this 4 lines from code and morpheus works well.
I try this with mesa from cvs+savage dri and in other computer with
XFree4.4 from cvs and with X.org R6.7 compiled from sources,
the difference was when morpheus runed with XFree4.4 instead of
Segmentation fault, gdk_gl_query() return FALSE.
I'm cross-replying to the DRI list in case anyone there is familiar
with the problem. Though, I don't really understand what you're
saying at the end.
I test in my laptop with dri cvs trunk savage drive.
and at work, on one desktop P4 xenon with one SIS 671FX, I try 2
differents sources Xfree4.4cvs and X.org R6.7 plus SIS drive 20040424.
with X.org, gdk_gl_query() give segmentation fault, with Xfree4.4cvs
returns FALSE, that is not wight either.
all with Fedora Core 1 OS
Thanks,
--
Sérgio M. B.
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-users] XQueryExtension problem ?
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 7185)] 0x40328227 in XQueryExtension () from /usr/X11R6/lib/libX11.so.6 (gdb) bt #0 0x40328227 in XQueryExtension () from /usr/X11R6/lib/libX11.so.6 #1 0x404c07b3 in glXQueryExtension (dpy=0x0, errorBase=0x0, eventBase=0x0) at glxcmds.c:758 #2 0x40470884 in gdk_gl_query () from /usr/lib/libgtkgl.so.5 #3 0x0804b8d4 in main (argc=1, argv=0x40473150) at main.c:189 The NULL dpy pointer passed to glXQueryExtension seems suspicious. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote: --- Nicolas Souchu [EMAIL PROTECTED] wrote: A major topic that I missed in the original list was how to handle BSD. DRM is under the BSD license and FB is GPL. If these two code bases are merged, what are we going to do about BSD? I don't know the appropriate BSD lists to post this to so please forward as necessary. What is exactly your question concerning licenses? FB is GPL licensed. DRM is BSD licensed. If FB and DRM are merged the end result will be GPL licensed code because of the way the licenses work. To change that you would have to get permission from every FB contributor to relicense their contribution from GPL to BSD. I suspect that it is pratically impossible to track all of the FB contributors down and what do you do if some won't cooperate? If the FB/DRM combo is GPL it can't be merged back into the BSD kernels. What we could do is build a merged driver and continue to have some of the source files licensed BSD and some GPL. But who cares? Do you really intend to keep a common BSD and Linux API/code base? Offering both solutions under BSD and GPL would be good for suggesting correct license usage in the embedded world. GPL is too often bypassed. The big reason for merging is memory management. If FB supports multiple heads it is forced into doing memory management. DRI has memory management needs that go far beyond what FB needs so a merged system has to use DRM memory management. Ian has made proposals on how to do this and he is working on improving them. What is best? Bring modesetting to DRM or memory management to FB? BenH and others have made proposals for pushing the mode setting code into a user space library in order to reduce kernel footprint and ease debugging. Most of the code needed for this library already exists in the current Linux FB drivers. I'm not sure if this could be relicensed BSD when it is moved to user space. One advantage of true graphic drivers (opposed to VESA or more generally bios modes) is that they can boot some archs in graphic mode (no text mode) without bios. Exactly what linuxfb was originaly designed to. How do you perform this from userspace? -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.freebsd.org/~nsouch/kgi4BSD --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] problems with compressed textures
On Thursday 06 May 2004 15:58, Brian Paul wrote: Mark Cass wrote: developers, I am having experiancing a sementation fault when calling glCompressedTexImage2DARB. I have checked the pointer returned from GetProcAddress and it seems to be valid (not NULL). i placed a breakpoint in teximage.c (a mesa source file) on the function _mesa_CompressedTexImage2DARB. I am not getting to this mesa function before the segmentation fault. The debugger is giving me fits and i can not look at a backtrace to determine where the crash occurred. even loading a core dump yields no useful information. gdb has always worked for me, as long as libGL and the driver are compiled with -g. In my experience, gdb easily gets confused when function pointers are involved. I've had one or two coredumps while working on the x11 DRI driver where it wouldn't even print a backtrace. In every case that's been because an unintialized function pointer was being called/dereferenced. gdb 6.0 appears to handle this case much better than 5.x did. - ajax --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
I for one have been waiting to see much of the graphics driver moved to the kernel as well. From a vendor perspective there is quite a lot to be gained. 1) If the mode setting can be removed from the X server then we can leverage that module for whatever graphics system is required. Some times we need an X server, some times we need something more like a framebuffer. Putting this in one place is a must. 2) Providing one place for rendering code would be nice too. We cannot assume that X is the way to go for all customers. If there were a place to put the device dependent rendering code (kernel module or low level library) then we could write X servers or custom graphics interfaces to use that library. 3) Some times you can just do the job easier or better from kernel space. Trapping interrupts instead of polling can save huge amounts of CPU cycles for some usage scenarios. Power management is easier. Sometimes the hardware needs some special memory considerations etc. No need to really harp on any of the details, it is just nice to have the full power of the OS when/if you need it. I think the best way to make everyone happy is to try to achieve two things. 1) A small, device-independent, API that can be used to set modes and do some very simple rendering. I would suggest get, set, put, copy. That would allow the kernel to render consoles or oopsen regardless of the mode (debugging the kernel on top of your X session?), and allow for any API of the month to make use of some very basic functionality. Mode setting should just be small as well, leave all the one-off features for extensions. No need to clutter an API with features that are rare. Although the fbdev is already available, I wouldn't suggest that it is a great platform to build on. The mode setting API is really not very good and it does not have modern concepts of twin, clone etc. I think a clean slate design that didn't try to accomplish everything in device independent manner could be a much more attractive target. 2) A mechanism to make all the device dependent extensions your heart desires. Then the X servers, opengl libs, etc can just have a DD component to access the hardware specific API. The more things you try to have a device independent API for, the more problems you will have trying to get agreement. Leave the API's to themselves. We should be trying to create a driver model, not a new graphics API. Ogl, X11, DirectFB, etc should be out of scope. -Matt --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
Around 16 o'clock on May 6, Sottek, Matthew J wrote: 1) If the mode setting can be removed from the X server then we can leverage that module for whatever graphics system is required. Some times we need an X server, some times we need something more like a framebuffer. Putting this in one place is a must. 'one place' appears to mean a common library API and not a common kernel API; some cards require extensive code to manage mode selection which can't be effectively implemented in kernel mode (like the current X i810 drivers). 2) Providing one place for rendering code would be nice too. For cards which can support it, I'd like to suggest that the GL API seems a natural fit here. Retargeting the X server to GL appears possible, and I hope to have a proof of concept running by OLS to show people. For other cards, I suggest that there aren't a whole lot of useful accelerated operations; 2D only cards generally don't support general image compositing, so the only critical operations for modern applications are video-video blt and (optionally) solid fill. I've implemented rather a lot of X servers in this way to good effect. 1) A small, device-independent, API that can be used to set modes and do some very simple rendering. Yes, the lowest level graphics driver needs to be able to request a specific mode and find out how that affects the hardware. I would suggest that the 'mode' selected here be indirect -- a 'symbolic' mode which reflects a more sophisticated configuration as specified by some device-specific mechanism. For instance, it would be nice to start a graphics application in TV mode without that application needing to know about all of the underlying complexities. This is similar to how standard modes are specified in X today -- you request a resolution, which is really just a symbolic name for a list of modes. The driver then selects one of those modes which the monitor can support. 2) A mechanism to make all the device dependent extensions your heart desires. Absolutely -- both for driver writers and mode selection mechanisms. Of course, one thing here is to make sure the kernel API isn't just a 'bag of bits in an ioctl'. Perhaps the kernel API could accept a list of register name/value pairs for the desired mode; the kernel driver would then be responsible for setting the register values appropriately. -keith pgp0.pgp Description: PGP signature
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
--- James Simmons [EMAIL PROTECTED] wrote: 2) Ben suggestion that we mount userland inside the kernel during early boot and use a userland library. If we would use a library then it MUST be OpenGL. This would be the forced standard on all platforms. This would mean Mesa would be needed to build the kernel. We could move over Mesa into the kernel like zlib is in the tree right now. It is not true that it must be OpenGL. The suggestion is for an independent library that would support mode setting and cursor control. Actually OpenGL does not specify an API for these things, we would need to develop one. But broader issues are at work. Microsoft has decided to recode all graphics in Longhorn to use Direct3D. This was done to get at the performance gains provided by D3D and hardware accelerated graphics. For example a Cairo implementation hat uses X rendering vs Cairo on OpenGL was benchmarked at being a 100:1 faster. A proposal has been made that OpenGL be promoted as the primary base graphics API on Linux. Then things like Cairo and the xserver be implemented on top of OpenGL. 1) OpenGL is the only fully accelerated API that Linux has. We don't have D3D or anything else like it. Fully accelerated interfaces are a pain to build and it would stupid to do another one. 2) OpenGL is extremely well documented. Just go to your local book store and you can buy a manual for it. It is available on Linux, Mac, Windows, Solaris, etc. Colleges teach classes on how to use it. 3) It is a high level interface, the framebuffer interface is way too low level and is mostly impossible to accelerate. Only about half of OpenGL is currently accelerated, over the next two or three chip generations it will probably become 100% accelerated. Using OpenGL as the API allows these features to be integrated into hardware without disrupting the apps. 4) It makes life easy for Nvidia and ATI. This is actually an important one if you want to use the latest hardware. Even though we don't like it this design makes it easy to releaese a monolithic blob that only exposes the OpenGL API. 5) Don't think of this as 2D vs 3D. xserver and Cairo only use the 2D features of OpenGL. Think of this as accelerated coprocessor vs programmed IO. 6) What about low memory embedded systems? mesa has an excellent implementation of OpenGL-ES available for free. http://www.khronos.org/opengles/ It already supports running out of a dumb framebuffer. OpenGL-ES is small enough that Qualcomm is putting it into phones. Of course you can always ignore the GUI standard and do what you want in an embedded system. 7) Going to OpenGL does not mean the end of X or remote access. xserver, http://www.freedesktop.org/Software/xserver, still talks the X protocol and still supports xlib. It just uses OpenGL (when Keith gets it working) to draw instead of XAA. If you use Glitz, http://www.freedesktop.org/Software/glitz, the OpenGL Cairo implementation, it will draw direct rendered and by-pass the xserver for local drawing. 8) If we don't get our act together soon, Longhorn is going to kick Linux's butt on the desktop. Go look at some of the demos if you don't believe this. http://www.osnews.com/topic.php?icon=37 Longhorn's Real Job: Trying to Gore Linux http://www.eweek.com/article2/0,1759,1580477,00.asp?kc=ewnws043004dtx1k599 = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
1) If the mode setting can be removed from the X server then we can leverage that module for whatever graphics system is required. Some times we need an X server, some times we need something more like a framebuffer. Putting this in one place is a must. 'one place' appears to mean a common library API and not a common kernel API; some cards require extensive code to manage mode selection which can't be effectively implemented in kernel mode (like the current X i810 drivers). Exactly. I have no real concern on where one place is, as long as all the clients (And the kernel booting is a client) can access it. I would contend that it is perhaps just a long held fear that mode setting is too big and complex for the kernel. It will be big, complex, and highly privileged code no matter where it lives. At some point we will cross the line between what is too complex. If we aren't there now we will be some day soon. Lots of OS designs have had mode setting kernel-side for a long time. The driver contains register level hardware knowledge and elevated privileges. The client does not have either. It knows only the driver's API. Same as DD OGL (client) and DRM (driver). 2) Providing one place for rendering code would be nice too. For cards which can support it, I'd like to suggest that the GL API seems a natural fit here. Retargeting the X server to GL appears possible, and I hope to have a proof of concept running by OLS to show people. I think you are straying into the area I wanted to stay away from. The driver model will have some chunk of device dependent code talking to the hardware that knows nothing of the high level API. It isn't X related, it isn't OGL related. It is hardware related only. Then there are corresponding DD parts for X, OGL or whatever that know this hardware specific API. As a vendor I want to write this low level component once no matter what the future design of the higher level clients. You cannot predict with any degree of accuracy what the future of graphics is going to be, but that doesn't preclude getting the driver model right. If you want to stack X on top of OGL... fine. I'm talking about the API between the DD parts of OGL and the hardware driver. For other cards, I suggest that there aren't a whole lot of useful accelerated operations; 2D only cards generally don't support general image compositing, so the only critical operations for modern applications are video-video blt and (optionally) solid fill. I've implemented rather a lot of X servers in this way to good effect. Exactly. The driver model interface (maybe call it a HAL) looks like the hardware. For older generation cards there would be very little here, just some 2d stuff. The DD portion of OGL or whatever would be doing it all in software (probably punting) This is similar to how standard modes are specified in X today -- you request a resolution, which is really just a symbolic name for a list of modes. The driver then selects one of those modes which the monitor can support. We have correctly moved most of the X world away from modelines and toward a symbolic name, however the DI-DD part is still broken. X tells the driver the set of timings but X knows nothing about the hardware so the more advanced drivers throw those timings away and use a correct set that most closely matches. It should be DD component telling DI component what is possible and DI component choosing from that list. 2) A mechanism to make all the device dependent extensions your heart desires. Absolutely -- both for driver writers and mode selection mechanisms. Of course, one thing here is to make sure the kernel API isn't just a 'bag of bits in an ioctl'. Correct. Bag o bits is what I'd like to see removed from the fbdev. I think a command interface would be a good design. i.e. Write commands rather than ioctls. (or one ioctl that takes a command buffer) that way you can get one context switch (all privilege elevations will require this, even if it isn't a Ring3-Ring0 thing) for a lot of commands. Plus it is easy to version, and support multiple versions concurrently. Command0 == Set command interface to version 1.0 command1 == draw foo command2 == dispatch dma buffer xyz and another client... command == set command interface to version 1.2 command1 == draw foo (slightly different interface than 1.0) Perhaps the kernel API could accept a list of register name/value pairs for the desired mode; the kernel driver would then be responsible for setting the register values appropriately. I would actually hate to see this for the mode setting part. This is a complete over-simplification of modern hardware. You would end up defining a whole language of sleeps, wait_for_bits, and register writes to get the job done correctly. You cannot just blast register values to hardware. On Intel hardware you will need to wait for vsyncs, talk to external devices over i2c, etc. Trying to let user-space determine all the register
Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
Around 17 o'clock on May 6, Jon Smirl wrote: A proposal has been made that OpenGL be promoted as the primary base graphics API on Linux. Then things like Cairo and the xserver be implemented on top of OpenGL. I respectfully disagree with this plan. OpenGL should be the sole API for accessing the graphics card for systems which support it, but I encourage application developers to continue coding to the X API so that there aren't unexpected surprises when run on a machine which doesn't support OpenGL. That the X server will use OpenGL to talk to these graphics cards is an implementation detail which shouldn't be visible to applications. -keith pgp0.pgp Description: PGP signature
Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
--- Keith Packard [EMAIL PROTECTED] wrote: Around 17 o'clock on May 6, Jon Smirl wrote: A proposal has been made that OpenGL be promoted as the primary base graphics API on Linux. Then things like Cairo and the xserver be implemented on top of OpenGL. I respectfully disagree with this plan. OpenGL should be the sole API for accessing the graphics card for systems which support it, but I encourage application developers to continue coding to the X API so that there aren't unexpected surprises when run on a machine which doesn't support OpenGL. That the X server will use OpenGL to talk to these graphics cards is an implementation detail which shouldn't be visible to applications. Read point #7 7) Going to OpenGL does not mean the end of X or remote access. xserver, http://www.freedesktop.org/Software/xserver, still talks the X protocol and still supports xlib. It just uses OpenGL (when Keith gets it working) to draw instead of XAA. If you use Glitz, http://www.freedesktop.org/Software/glitz, the OpenGL Cairo implementation, it will draw direct rendered and by-pass the xserver for local drawing. -keith ATTACHMENT part 2 application/pgp-signature = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
Another topic that I missed was, why did kgi fail and what can we do to avoid repeating the same path this time around. IIRC, the main reasons were: - GGI wanted to do too much at once and was too intruisive (conclusion: always advance in small steps, not big leaps): o kernel graphics drivers (KGI) o new input subsystem (similar to what we're heading to now) o user space library (libggi, AFAIK the only part that's still alive) - fbdev was better in multi-platform handling (m68k - PPC - ia32 - SPARC - alpha - ...) Please correct me if I'm wrong ;-) The KGI is way to complex. I attempted to write a driver using that system but I was totally lost. Fbdev, especially now is much easier to develope. The input system we have is very similiar to what they had. I'm really glad we have a input system. As for the library. Well it has always been a dream to have a universal library by many people. It never happened and never will happen. When it comes it libraries you have issues like licenses and people fighting --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
But who cares? Do you really intend to keep a common BSD and Linux API/code base? Offering both solutions under BSD and GPL would be good for suggesting correct license usage in the embedded world. GPL is too often bypassed. What about a dual license. The big reason for merging is memory management. If FB supports multiple heads it is forced into doing memory management. DRI has memory management needs that go far beyond what FB needs so a merged system has to use DRM memory management. Ian has made proposals on how to do this and he is working on improving them. What is best? Bring modesetting to DRM or memory management to FB? Bring mode setting to DRM since all FB does is mode setting, color maps and 3 accel functions for the console. With sysfs we could bring both together. BenH and others have made proposals for pushing the mode setting code into a user space library in order to reduce kernel footprint and ease debugging. Most of the code needed for this library already exists in the current Linux FB drivers. I'm not sure if this could be relicensed BSD when it is moved to user space. One advantage of true graphic drivers (opposed to VESA or more generally bios modes) is that they can boot some archs in graphic mode (no text mode) without bios. Exactly what linuxfb was originaly designed to. How do you perform this from userspace? The idea was to mount userland inside the kernel while booting and run a library to initialize the mode. We have two options: 1) Keep mode switching in the kernel. Merge DRI and fb together via sysfs interface. 2) Ben suggestion that we mount userland inside the kernel during early boot and use a userland library. If we would use a library then it MUST be OpenGL. This would be the forced standard on all platforms. This would mean Mesa would be needed to build the kernel. We could move over Mesa into the kernel like zlib is in the tree right now. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
Around 18 o'clock on May 6, Sottek, Matthew J wrote: I would contend that it is perhaps just a long held fear that mode setting is too big and complex for the kernel. With a library API instead of a kernel API, each driver author can choose precisely where the split belongs. I think you are straying into the area I wanted to stay away from. The driver model will have some chunk of device dependent code talking to the hardware that knows nothing of the high level API. Yes, that's certainly true -- the kernel shouldn't know anything about the machinations of user-mode API layering. It should be DD component telling DI component what is possible and DI component choosing from that list. Yes, surely -- the graphics application has no business asserting what video timings the monitor can accept. The rest of your comments seem quite reasonable to me; let's keep discussion on this list focused on the kernel aspects of video card support and ignore what's going out in userland. -keith pgp0.pgp Description: PGP signature
