From: Smitty <sm...@wa...> - 2003-03-01 19:13:40
|
> The 3Dfx Voodoo 3 and Banshee specs are available, as are docs > for other 3D hardware. Who is working on that right now? 3Dfx > released the source code of Glide3 for example. I dont think a > single line of code has been written for Glide3 for 2 years now. Probably because, 3DFX is dead, a V3 gets smacked around by a TNT2, Glide is not neccessary if you have OpenGL or DirectX, and Glide is low level 3dfx only. A useless API for old and slow not to mention dead technology. Which is probably why Molton is trying to instigate a divorce from Glide for the V3. Or am I being too harsh? <g> Liam ---- it depends |
From: Smitty <sm...@wa...> - 2003-03-02 21:13:38
|
> (oh, and please, I prefer being referred to by my first name.) one Molton many Ian's <g> From: "Daniel Vogel" <vo...@ep...> To: "Smitty" <sm...@wa...>, <dri...@li...> Subject: RE: [Dri-devel] Re: future of DRI? -> why no one plays with Glide3. Date: Sat, 1 Mar 2003 16:35:15 -0500 > a V3 gets smacked around by a TNT2, FWIW, a Voodoo 3 clearly outperforms a TNT2 with Unreal Tournament 2003 (on Windows, using D3D). It's a PITA to develop for though ;) OK how about GF256? I still have lots of cards to name. <g> Liam ---- it depends |
From: Mike A. H. <mh...@re...> - 2003-03-01 20:05:23
|
On Sat, 1 Mar 2003, Smitty wrote: >> The 3Dfx Voodoo 3 and Banshee specs are available, as are docs >> for other 3D hardware. Who is working on that right now? 3Dfx >> released the source code of Glide3 for example. I dont think a >> single line of code has been written for Glide3 for 2 years now. > >Probably because, >3DFX is dead, I completely realize that 3Dfx is dead. My point is that even when they were alive still at the end, there wasn't much going on with the 3Dfx drivers. >a V3 gets smacked around by a TNT2, Not with open source drivers it doesn't. >Glide is not neccessary if you have OpenGL or DirectX, >and Glide is low level 3dfx only. I'm also well aware of that. >A useless API for old and slow not to mention dead technology. Yes, it is. But you missed my point. The point being that code exists and nobody is hacking on it. I'm not *blaming* anyone. Volunteers work on what volunteers are interested in working on. That's obviously not Glide3. Point is, there is code and docs that have been available to people that have not seen much contributions at all except by funded development. Look at the Intel i8x0 driver for example. The Intel specs are publically available, and Intel funds development of the driver. The hardware is readily available too. Yet there is not any major contributions to the code at all other than what is produced by funded development. This is hardware that is brand new, and by a company that is not dead. Forgive my bad example of choosing 3Dfx and Glide3. >Which is probably why Molton is trying to instigate a divorce >from Glide for the V3. I certainly support that move. Anholt was working on Glide3 recently a bit as well. I dunno how far he got, but I've been meaning to ask. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |
From: Ian M. <sp...@f2...> - 2003-03-01 20:50:30
|
On Sat, 1 Mar 2003 15:05:37 -0500 (EST) "Mike A. Harris" <mh...@re...> wrote: > Look at the > Intel i8x0 driver for example. The Intel specs are publically > available, and Intel funds development of the driver. The > hardware is readily available too. Yet there is not any major > contributions to the code at all other than what is produced by > funded development. I think, sadly, its because the hardware is shit. even on windows, i8x0 performs worse than a voodoo 3 by a LARGE margin... |
From: Keith W. <ke...@tu...> - 2003-03-03 01:31:39
|
Ian Molton wrote: > On Sat, 1 Mar 2003 15:05:37 -0500 (EST) > "Mike A. Harris" <mh...@re...> wrote: > > >>Look at the >>Intel i8x0 driver for example. The Intel specs are publically >>available, and Intel funds development of the driver. The >>hardware is readily available too. Yet there is not any major >>contributions to the code at all other than what is produced by >>funded development. > > > I think, sadly, its because the hardware is shit. > > even on windows, i8x0 performs worse than a voodoo 3 by a LARGE > margin... The newer chipsets (supported by the i830 driver) are a lot faster than the originals. Additionally, the driver until recently (ie before the last lot of changes done by David Dawes & I) didn't do a good job of setting up tiling, which was vital to decent performance. I don't have one up & running to give numbers, but they have come along considerably since the i810/i815. Keith |
From: Martin S. <Mar...@un...> - 2003-03-01 21:23:20
|
"Mike A. Harris" <mh...@re...> wrote: > On Sat, 1 Mar 2003, Smitty wrote: >>Which is probably why Molton is trying to instigate a divorce >>from Glide for the V3. > I certainly support that move. Anholt was working on Glide3 > recently a bit as well. I dunno how far he got, but I've been > meaning to ask. Ian Molton got a Voodoo3 3k from me but he yet did not manage to have the time for necessary work on that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Antonino D. <ad...@po...> - 2003-03-01 22:38:51
|
On Sun, 2003-03-02 at 04:05, Mike A. Harris wrote: > On Sat, 1 Mar 2003, Smitty wrote: > > Yes, it is. But you missed my point. The point being that code > exists and nobody is hacking on it. I'm not *blaming* anyone. > Volunteers work on what volunteers are interested in working on. > That's obviously not Glide3. Point is, there is code and docs > that have been available to people that have not seen much > contributions at all except by funded development. Look at the > Intel i8x0 driver for example. The Intel specs are publically > available, and Intel funds development of the driver. The > hardware is readily available too. Yet there is not any major > contributions to the code at all other than what is produced by > funded development. > I think the Intel 8x0 is also a bad example. Precisely because the XFree86 and DRI drivers are funded by Intel that volunteer work shifts to other areas (fbdev, DirectFB). Secondly, these old Intel chipsets are not a natural choice for doing 3D (70-100 fbs with glxgears :-). Not worth concentrating on with regards to 3D. AFAIK, there are at least 2 versions of the i810 framebuffer driver publicly available, both of which are not possible without the public docs. For the more popular cards, volunteer work exists, not in the hundreds, but significant enough to make a dent. Take Matrox for instance. A significant amount of code is contributed with regards to DirectFB and mplayer. Once in a while, people will request for specifications concerning ATI cards in various mailing list. Whether they'll spend significant developer effort is anyone's guess. I'm not advocating open sourcing hardware specs. If manufacturers do, that's excellent. If they don't, I respect that decision. Tony |
From: Linus T. <tor...@tr...> - 2003-03-01 23:14:05
|
On 2 Mar 2003, Antonino Daplas wrote: > > AFAIK, there are at least 2 versions of the i810 framebuffer driver > publicly available, both of which are not possible without the public > docs. I don't think that answers Mike's criticism that open-source developers don't tend to work on DRI. And I think he's right. The reason you find open-source people working on fbdev and mplayer etc is because those tend to be _easier_ projects to get into. Quite frankly, DRI is the project from hell when it comes to "getting into" it, and I think that's largely because you have to have all the pieces in place to get something working, and you have to understand a wide range of different issues (you can't just understand hardware, you also have to have some understanding of OpenGL). Which just tends to cut down the number of people who are willing and able to do the work. Add to that the fact that for many of the common chipsets documentation is hard to get ("common" here not being in absolute numbers, but in the kind of hw that people who are really interested in 3D would want to buy), and it's no wonder that there aren't that many people working on it - there are just a lot of things working _against_ new people. Look at the size of a 3D driver today, and _especially_ look at how it actually needs at least three totally separate parts - the generic OpenGL part, the card-specific part, and the kernel part. None of which are in any way independent from each other (the generic OpenGL part should be, but as can be seen from what both Nvidia and ATI have done, it ends up being tied into the low-level driver _anyway_ because of issues like feature reporting). Add to the complexity that you have to understand a fairly arcane and arguably badly designed AGP interface too, and no wonder people are not lining up in the streets. I _suspect_ that the fact that most modern graphics cards are designed mainly for DirectX might make the whole thing slightly worse (ie just from causing some additional disconnect between what the hardware does and what the interfaces are). A simpler, more direct, infrastructure to the low-level driver might help. I suspect that is why MS started doing D3D in the first place, and it is clearly why things like glide ever even existed in the first place - avoiding to have to know as much as people currently do have to know. Assume people are stupid. We usually are. Linus |
From: Antonino D. <ad...@po...> - 2003-03-01 23:44:47
|
On Sun, 2003-03-02 at 07:11, Linus Torvalds wrote: > > On 2 Mar 2003, Antonino Daplas wrote: > > > > AFAIK, there are at least 2 versions of the i810 framebuffer driver > > publicly available, both of which are not possible without the public > > docs. > > I don't think that answers Mike's criticism that open-source developers > don't tend to work on DRI. > > And I think he's right. The reason you find open-source people working on > fbdev and mplayer etc is because those tend to be _easier_ projects to get > into. > Don't get me wrong, I completely agree with Mike when he said that, to paraphrase, "hundreds will not flock to code for DRM except for a stout few". I just meant that nobody is contributing to i810 development because it is a "dead-end" chipset for DRI. However, I still believe enough in open source that if Intel did not provide drivers for them, nor pay a coder to do it, someone in the multitude will. Tony |
From: Alan C. <al...@lx...> - 2003-03-02 00:17:37
|
On Sat, 2003-03-01 at 23:11, Linus Torvalds wrote: > Quite frankly, DRI is the project from hell when it comes to "getting > into" it, and I think that's largely because you have to have all the > pieces in place to get something working, and you have to understand a > wide range of different issues (you can't just understand hardware, you > also have to have some understanding of OpenGL). In addition even if you know the pieces its a lot of work to make it do anything - but getting better. DRI now has credible documentation but it still has stuff like each card using its own vertex arrays, texture manager and the like. Thats one reason I'd love to see the C++ framework proposed. Hell I can draw triangles on my SiS6326, its just there isn't a way to plug that code into an existing framework yet. > Add to that the fact that for many of the common chipsets documentation is > hard to get ("common" here not being in absolute numbers, but in the kind > of hw that people who are really interested in 3D would want to buy), and > it's no wonder that there aren't that many people working on it - there > are just a lot of things working _against_ new people. Old SiS - public Trident - public Drivers - none. > I _suspect_ that the fact that most modern graphics cards are designed > mainly for DirectX might make the whole thing slightly worse (ie just from > causing some additional disconnect between what the hardware does and what > the interfaces are). DirectX affects 2D mostly - it means some of the line drawing hardware is broken for X. > A simpler, more direct, infrastructure to the low-level driver might help. > I suspect that is why MS started doing D3D in the first place, Mesa vertex lists seem suspiciously D3D like to me |
From: Linus T. <tor...@tr...> - 2003-03-02 00:37:25
|
On 2 Mar 2003, Alan Cox wrote: > > Thats one reason I'd love to see the C++ framework proposed. Hell I can > draw triangles on my SiS6326, its just there isn't a way to plug that > code into an existing framework yet. I think this is the perfect example of "hard to get into". A person who knows what he's doing, has documentation, hardware and motivation, and _still_ finds it hard to actually get started at doing anything. Yeah, you can't expect to get Doom 3 working overnight. But if there was some _simple_ way to get some very basic initial stuff working in a driver, that might make people more able to get into it. Linus |
From: Frank E. <fe...@ai...> - 2003-03-06 03:11:57
|
On Saturday 01 March 2003 07:19 pm, Alan Cox wrote: > Old SiS - public > Trident - public > > Drivers - none. Old SiS - Utah-GLX. They had an alpha of a driver for that chipset (I happened to have one, but not the time to pursue improving upon it at the time...). As for me and helping out, I've been a bit overwhelmed with the concerns around me- I've been for all intents and purposes unemployed for well over a year now and I've been trying to keep a house over my head, etc. Not really conducive to working on code that doesn't put food in your mouth and a roof over your head. What makes the situation with some of the older chips worse is that they're not suited, as you've noticed, to what DRI offers. They're almost better off with something else- of what, I'm not precicely sure yet. -- Frank Earl |
From: Jon S. <jon...@ya...> - 2003-03-02 00:56:19
|
--- Linus Torvalds <tor...@tr...> wrote: > A simpler, more direct, infrastructure to the > low-level driver might help. X has served us well for a long time but I just don't think it is sufficient to be the standard video platform for desktop Linux over the next ten years. We're not going to replace X overnight, but we need a path to slowly evolve it. I am amazed at the rate of change in the kernel, but X hardly seems to change at all. How can we speed things up? I agree that X is very complicated to work on. Mozilla has the same problem, everything is connected to everything. There is no way to work on a piece of Mozilla without working on the whole thing. Mozilla is trying to fix this but they still have a long ways to go. For me, a layered approach where each piece can be compiled, used and tested independently would make X much more manageable. Something like this: Kernel level - fusion of DRM and FB, libDRM OpenGL - Mesa + DRI Xserver rest of X I'm sure people with more experience on X can divide it in a better way, but the key is in dividing it into smaller, more digestible chunks. These layers need to build and run independently. The DRI tree has close to 10,000 files in it right now and DRI isn't even a complete X tree. That's an awful lot of code to read and understand as a single package. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Alan C. <al...@lx...> - 2003-03-02 01:26:14
|
On Sun, 2003-03-02 at 00:56, Jon Smirl wrote: > X has served us well for a long time but I just don't > think it is sufficient to be the standard video > platform for desktop Linux over the next ten years. People were saying that ten years ago. They were wrong then, and I suspect they are wrong now. Too many people think X11 == XFree86. XFree86 is an *implementation* (arguably two with kdrive) of X11. > change in the kernel, but X hardly seems to change at > all. How can we speed things up? X changes, its just its very good at not breaking stuff and Xfree itself tends to be deeply conservative, perhaps overly so. XFree86 has been acquiring render extensions, rotation, resize on the fly, a sophisticated security model for partitioning untrusted applications, and much more, its just nobody noticed most of these except maybe the new font stuff. > I agree that X is very complicated to work on. Mozilla 2D XFree86 is *easy* to work with. It took me a day to learn how to write input drivers, it took me a couple of days to learn how the X driver model worked to rewrite the Cyrix driver to actually work. You can write a 2D Xserver in under a week. You might spend a while longer debugging it because all the hardware has crazy bugs. 2D XFree you copy a driver example, fill in your PCI idents and your mode switch code. Compile, debug and you have an unaccelerated X server. You plug in a set of standard Xaa routines one at a time and you get more and more acceleration. You copy the Xv example code fill in the blanks and you get video overlay support. Since XFree 4.0 you don't have to touch the core code, you don't have to duplicate a ton of stuff and you don't need to know zip about DDX, MI and the other core layers. Alan |
From: Jon S. <jon...@ya...> - 2003-03-02 01:55:11
|
--- Alan Cox <al...@lx...> wrote: > People were saying that ten years ago. They were > wrong then, and I suspect they are wrong now. Looking out five years wouldn't OpenGL 2.0+ make a better core graphics API for Linux than XLIB? Hardware is certainly trending towards the 3D model. I'd like to see Linux turn XFree inside out. Instead of OpenGL/DRI being bolted onto X, bolt X onto OpenGL/DRI. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Linus T. <tor...@tr...> - 2003-03-02 02:06:41
|
On Sat, 1 Mar 2003, Jon Smirl wrote: > > I'd like to see Linux turn XFree inside out. Instead > of OpenGL/DRI being bolted onto X, bolt X onto > OpenGL/DRI. It might not even be that painful to try. X largely should support things like that simply thanks to the fact that people have already worked hard at embedding X on top of other things, notably the X on Darwin stuff. And with Keith already having an embedded DRI working on top of fbdev.. The proof is in the pudding. Linus |
From: Alan C. <al...@lx...> - 2003-03-02 21:14:45
|
On Sun, 2003-03-02 at 01:55, Jon Smirl wrote: > --- Alan Cox <al...@lx...> wrote: > > People were saying that ten years ago. They were > > wrong then, and I suspect they are wrong now. > > Looking out five years wouldn't OpenGL 2.0+ make a > better core graphics API for Linux than XLIB? Hardware > is certainly trending towards the 3D model. If you care which one of the two, your higher level abstraction is wrong IMHO. > I'd like to see Linux turn XFree inside out. Instead > of OpenGL/DRI being bolted onto X, bolt X onto > OpenGL/DRI. Radeon already uses DRI to do some of the rendering stuff when also doing 3D. You can choose to implement your XAA accelerations with 3D primitives, or you can go up a layer higher. There is definitely scope for a server which treats all the 2D objects as textures. It makes stuff like alpha a lot lot simpler but at a memory cost. |
From: Linus T. <tor...@tr...> - 2003-03-02 01:57:43
|
On 2 Mar 2003, Alan Cox wrote: > > Since XFree 4.0 you don't have to touch the core code, you > don't have to duplicate a ton of stuff and you don't need > to know zip about DDX, MI and the other core layers. Yeah, I don't think regular X is problematic. The Xv stuff used to be quite messy, but even that seems simpler these days (although I also haven't had any real reason to worry about it any more, so maybe I just _think_ it's cleaner these days). The lack of commit rights to the X tree might be a problem for some, but I don't think regular 2D X has anywhere _near_ the kind of lack of people and time that DRI ends up having. Partly because the problem set is simpler, I'm sure. But also largely because the abstraction issues _have_ been worked on for a long time and it's just easier to do a driver these days as a result. Linus |
From: Ian M. <sp...@f2...> - 2003-03-02 03:15:52
|
On 02 Mar 2003 02:26:04 +0000 Alan Cox <al...@lx...> wrote: > > > change in the kernel, but X hardly seems to change at > > all. How can we speed things up? > > X changes, its just its very good at not breaking stuff Agreed. I've been pleasantly surprised at how fast XF86 has been evolving lately. I was losing confidence in it around 3.x.x but the 4.2/3 series have come on in leaps and bounds... |
From: Mike A. H. <mh...@re...> - 2003-03-02 03:05:21
|
On Sat, 1 Mar 2003, Jon Smirl wrote: >X has served us well for a long time but I just don't >think it is sufficient to be the standard video >platform for desktop Linux over the next ten years. >We're not going to replace X overnight, but we need a >path to slowly evolve it. I am amazed at the rate of >change in the kernel, but X hardly seems to change at >all. How can we speed things up? I believe it can be done by creating an X devlopment community/environment that is more conducive to future progress, and more open, accepting, and encouraging of new developers. The DRI project IMHO works pretty good in this aspect for ages now. >For me, a layered approach where each piece can be >compiled, used and tested independently would make X >much more manageable. Something like this: > >Kernel level - fusion of DRM and FB, libDRM >OpenGL - Mesa + DRI >Xserver >rest of X > >I'm sure people with more experience on X can divide >it in a better way, but the key is in dividing it into >smaller, more digestible chunks. These layers need to >build and run independently. I can't agree more. I think X should be broken into several pieces personally that are independant of each other. The drivers should be decoupled from the huge monolithic sources IMHO, and built separately against a DDK of some kind. Not unlike the existing XFree86 "sdk" that I don't believe anyone uses currently. I'm investigating this currently in my tinkerings. I'd like to split up X sources sometime in the future into at least: 1) fonts 2) docs 3) video drivers 4) various applications not needed at X server build/install time 5) X server and everything else That's just phase 1 idea. I think it oculd be broken down much finer than that. The benefits IMHO would be large. >The DRI tree has close to 10,000 files in it right now >and DRI isn't even a complete X tree. That's an awful >lot of code to read and understand as a single >package. Agreed. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |
From: Philip B. <ph...@bo...> - 2003-03-02 07:39:14
|
On Sun, Mar 02, 2003 at 02:26:04AM +0000, Alan Cox wrote: > People were saying that ten years ago. They were wrong > then, and I suspect they are wrong now. Too many people > think X11 == XFree86. XFree86 is an *implementation* > (arguably two with kdrive) of X11. Even ignoring kdrive, I'd call it two implementations in one. After all xfree86 is still basically a "bolt-on" to the old standard X11R6. There are still TWO SEPARATE APIs for doing 2d drivers. There's the stock-standard Xserver/hw/{standard-driver-here} (eg: Xserver/hw/sun) and then there's Xserver/hw/xfree86/drivers/{xfree-extensions-driver-here} I havent studied the ramifications of supporting both those models in detail, but just the fact that xfree is still essentially a bolt-on product, strikes me as a Bad Thing, for a "nice, clean" implementation of an X server. > > I agree that X is very complicated to work on. Mozilla > > 2D XFree86 is *easy* to work with. It took me a day to learn > how to write input drivers, ... Funny. It took me a lot longer, because - first I followed the x consortium docs on how to write an XINPUT module... - found it was lacking a bit from how the "standard" X11 framework wanted things to be - found that was slightly different from how the average XFREE86 input module was implemented - found neither of the two were exactly like how Xsun did XINPUT modules... Okay, the last one isnt exactly relevant to this discussion ;-> but serves as grist for the mill of "there aint no truely standard X server" > Since XFree 4.0 you don't have to touch the core code, you > don't have to duplicate a ton of stuff and you don't need > to know zip about DDX, MI and the other core layers. Sounds nice. Too bad the core itself hasnt been cleaned up to unified the card driver models more. Oh, and for what it's worth... "implementation of an X server" still isnt what most people care about to run (2d) programs. Most people care about "Can I compile something that expects libX11.so" ? Which really means, for 95% of users out there, all you "really" need, is a lookalike for libX11. I had basic X11 apps compiling on (durnit, have to verify 6809 vs 68000) (searches google...) Damn.. Too far back. Some time in 1988, I think. Anyhow, I believe I had some X11 apps compiling and running on a 6809, running OS9 on a computer with 512k of memory (64k max addressible at a time) You think I had an X server running? ha-ha. Nope, progs just care about the X11 lib. So for the "X on top of OpenGL" afficionados... you could get away with just writing a libX11 clone on top of a direct OpenGL implementation like Embedded Mesa or something. Skip the whole server fiasco entirely. Mind you, you'd need to cobble together some kind of window manager behind the scenes. My old hack relied on a native window manager to take care of that sort of thing. |
From: Michel <mi...@da...> - 2003-03-02 14:56:04
|
On Son, 2003-03-02 at 08:39, Philip Brown wrote: > On Sun, Mar 02, 2003 at 02:26:04AM +0000, Alan Cox wrote: > > People were saying that ten years ago. They were wrong > > then, and I suspect they are wrong now. Too many people > > think X11 == XFree86. XFree86 is an *implementation* > > (arguably two with kdrive) of X11. > > Even ignoring kdrive, I'd call it two implementations in one. > After all xfree86 is still basically a "bolt-on" to the old standard > X11R6. > > There are still TWO SEPARATE APIs for doing 2d drivers. > There's the stock-standard > > Xserver/hw/{standard-driver-here} > (eg: Xserver/hw/sun) > > and then there's > > Xserver/hw/xfree86/drivers/{xfree-extensions-driver-here} Isn't the former rather a complete DDX, whereas the latter is merely a video driver of the XFree86 DDX? > > > I agree that X is very complicated to work on. Mozilla > > > > 2D XFree86 is *easy* to work with. It took me a day to learn > > how to write input drivers, ... > > Funny. It took me a lot longer, because > > - first I followed the x consortium docs on how to write an XINPUT > module... > > - found it was lacking a bit from how the "standard" X11 framework wanted > things to be > > - found that was slightly different from how the average XFREE86 > input module was implemented > > - found neither of the two were exactly like how Xsun did XINPUT > modules... > > Okay, the last one isnt exactly relevant to this discussion ;-> but > serves as grist for the mill of "there aint no truely standard X server" You just need to realize early on that any real X development is happening in XFree86 these days. :-P -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Jon S. <jon...@ya...> - 2003-03-02 15:41:34
|
--- Philip Brown <ph...@bo...> wrote: > So for the "X on top of OpenGL" afficionados... you > could get away with just writing a libX11 clone on > top of a direct OpenGL implementation like > Embedded Mesa or something. Skip the whole > server fiasco entirely. Mind you, you'd need to > cobble together some kind of window manager > behind the scenes. My old hack relied on a native > window manager to take care of that sort of thing. The window manager problem was what started all of this. The Mac and Windows Longhorn are both starting to use 3D features (including 2D transparency) in their window managers. With the current XFree set up there is no way to work on something similar for Linux. My simple idea was that xlib is getting pretty old and OpenGL 2.0 is a well designed API. I was also aware of all of the different drivers inside of Xfree. So it occurred to me why not have OpenGL as the base layer. That would provide an excellent platform API and make an easy target for NVidia and ATI. OpenGL works just as well for 2D as 3D. The trend in hardware also supports the OpenGL direction. In a few years 3D hardware is going to be a dirt cheap commodity. Starting from an OpenGL base will leverage that. With the OpenGL base I could start working on a window manager that used 3D features. I thought that this was a better approach than 3D enabling the root window and then hacking the window manager inside of Xfree. For the Xserver the XFree code base could be used. Or something like http://www.directfb.org/xdirectfb.xml might be easier to work with. I need a scheme for getting the 2D Xwindows to draw into textures so that they can be manipulated. I need to do parallel changes to the 3D buffering system too. There is probably a way to make this work on a minimal footprint with 2D only hardware by using a combo of mesa plus stubbing out a lot of functions but I haven't explored that path yet. The embedded Mesa code looks like the best place to start. I wasn't aware of it before. I only knew about FBDRI which is way out of date and doesn' build. Embedded Mesa looks like FBDRI done right. I'm going to be gone a couple of days but when I get back I'll start working on getting the Embedded Mesa code up on my hardware. I'm also considering starting with a user level OpenGL app on DRI and just changing the XDirectFB code to write to a texture. This scheme would work to demo 2D capability but it won't work for a 3D window. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
From: Michel <mi...@da...> - 2003-03-02 15:58:28
|
On Son, 2003-03-02 at 16:41, Jon Smirl wrote: > > For the Xserver the XFree code base could be used. Or > something like http://www.directfb.org/xdirectfb.xml > might be easier to work with. Which uses the XFree86 code base as well. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Alan C. <al...@lx...> - 2003-03-02 21:03:48
|
On Sun, 2003-03-02 at 07:39, Philip Brown wrote: > There are still TWO SEPARATE APIs for doing 2d drivers. > There's the stock-standard > > Xserver/hw/{standard-driver-here} > (eg: Xserver/hw/sun) Thats the top level "do it the hard way" interface. Thats X11R6 vanilla not Xfree86. > and then there's > Xserver/hw/xfree86/drivers/{xfree-extensions-driver-here} Which is how you actually write a 2D Xserver if you are sane. > I havent studied the ramifications of supporting both those models in > detail, but just the fact that xfree is still essentially a bolt-on > product, strikes me as a Bad Thing, for a "nice, clean" implementation of > an X server. Hw/sun is an implementation, just like kdrive is or xfree86 is. > Okay, the last one isnt exactly relevant to this discussion ;-> but > serves as grist for the mill of "there aint no truely standard X server" Why should there be. If you have an unusual situation where XFree86 doesn't fit you want to be able to create a different X server. What good would a 'standard' X server be if it meant it didn't fit on an iPaq and that was it, game over ? > Sounds nice. Too bad the core itself hasnt been cleaned up to unified > the card driver models more. XFree86 has, you are lost in X11R6.4 base land. You can rm -rf most of that if you run a normal OS. Some of those old server are still used by some vendors with legacy platforms. > Oh, and for what it's worth... "implementation of an X server" still isnt > what most people care about to run (2d) programs. > Most people care about "Can I compile something that expects libX11.so" ? AcceleratedX actually did that with a library that new about fast bypass of the normal communications scheme of things. Its quite a valid model to build an Xserver where the local rendering is done by Xlib and some kind of DRI like setup and remote connections are handled by forking off another client and turning the ops back into DRI operations. Thats also a very good model for handling remote rendering with Mesa especially when you don't have a threaded Xserver |