since it is an hot topic...

The current status:

Intel -> has the drivers released in the wild, it working fine and the mess about the hal.so providing Macrovision (MPlayer/xine/ogle implement already a way to avoid such idiocy) and other stuff from the land of DRM.

No, I don't think they'll provide stand alone boards

ATi/AMD -> the opensource driver made by reverse engineering is pretty ok for emails and video, don't ask too much about 3d and you better forget the newest entry. The latest claim told us the we could wait another couple of years before we get some sourcecode from them. Keep in mind that they are providing chips for the Microsoft console, so I think they have some legal bounds about not providing anything on the same arch (guess what? PPC =/)

nVidia -> they already stated that don't see a market big enough for the effort of producing a ppc binary or releasing opensource.

XGI -> There is an opensource driver, we saw that is ready and the only clause is to get enough orders (maybe through genesi since getting XGI at least on europe isn't that easy) to cover the initial development costs.

This proprietary gxf-driver circus is damaging to non-Windows-3D-gaming platforms. There's no reason to support it in any way. Most proprietary Linux-drivers I've run has been of lousy quality.

And now they've even found a new reason to keep the drivers closed: DRM
... *sigh*. DRM is a fundamentally broken concept. Even HDCP was broken long time before it was available in retail. All DRM does is to annoy ordinary legal users and encourage format wars and monopolies.

Anyway... Groklaw linked to this blog about ATI:

http://aseigo.blogspot.com/2006/08/dear-ati.html

>latest XGI board

Is there such a thing?
Afaik these were largely old SIS/Trident designs and the only new stuff they are going to do after ATI took over large parts of their assets is for the embedded/server market without any 3d gfxpower to speak of.
Am I wrong?

Quite a bit, check their site.

Their offerings are pretty well suited for linux overall usage
(XGL, blender, mplayer, etc, etc, etc)

Genesi will release the drivers as binary anyway, if/when we are shipping the cards with machines. Open sourcing is our decision for our platforms, XGI would be happy if we never did, but are fully open to the idea. We just have yet to decide if it is truly a wise idea to open up the code and watch it fork into different drivers, or lose functionality in the process (perhaps component video since it is a 'requirement' to support Macrovision if your intention is to allow playing DVDs, perhaps the ability to ever support HDCP via DVI or HDMI on future cards).

Would you rather have the features or the source? That is the question. Since we have not even started shipping machines with XGI cards yet.. this isn't the best time to ask

_________________
Matt Sealey

Yes.
Yes. XGI have new designs in the works. It's true that most of the current designs are SiS/Trident-based, however improved or with features added. Newer cards are improvements on those same designs.

ATI did only take PEOPLE from XGI, and only a subsidiary for sales and design in China, in order to gain a fast foothold in the Chinese market. They did not secure any 3D, MPEG decoder core, bus technology or card design. XGI is still the same XGI we were dealing with for all this time, and none of the technology has been "lost".

However they did change their product roadmap slightly.. for the better or worse, that is not for us to say, but we have plenty of options for supporting Genesi workstations.

_________________
Matt Sealey

Macrovision scheme is pretty well handled by mplayer, who cares about driver?

About the wire drm stuff, I'm not so interested on it.
Keep that stuff somewhere if you have customers asking for it and let the others enjoy the opensource (useful) part. (NotaBene: that the way Intel is following)

Another point: how many r300 drivers are available around?

ONE and the source is MIT licensed.

I'm a bit sick about those people afraid of "spooky forks", if something got forked either branches could live on their forces or one dies. It's called evolution and that why the opensource software model let you have quite impressive results in short time.

For hardware that mplayer doesn't support? For people who don't use mplayer?
Sorry but the movie industry, and graphics cards manufacturers are. You are stuck with it and by that notion, so are we, and by proxy, so are you.
Yes but this is because someone decided to write it from scratch and there is one development team for it. There is a big difference between "only one driver has ever been developed" and "we will release the source code, do what you like".

There are plenty of commercial softwares which have been open sourced, and now there are multiple implementations of the same thing. One project may get abandoned, one may go further, one may be disabling features to be "better" than another.
Indeed but if it wasn't a problem for anyone, and nobody ever cared or anticipated it, projects like Blender wouldn't be cared for by the Blender Foundation for example. They're explicitly set up to manage the Blender source code and make sure development sticks to one track. There is one version of Blender at the end of the day because of this.
Software development methods are about as far from the theory of evolution as you can get.

Evolution would be when a software "decides" because of it's authors to go a different route for the benefit of the whole software. This might be for instance every time they restructure the IRQ code in Linux or implement a new RAID model or firewall/filtering code, this has been done a few times. That is evolution. Old versions of the software may run better, or faster, but the new ones might be more stable. Survival of the fittest determines which one people RUN. There are still developers who insist that 2.4 is where they want to live, or that they want to use NetBSD pf instead of iptables.

Branching code and making whole new versions, such that there would be an "XGI" version and a "Genesi" version and a "Dell" version etc., based on some ancient release but none of them tracking each other, or implementing all their features in a different way is not evolution. That is like saying the ant should be happy that nature has provided 10 different kinds of anteater.

_________________
Matt Sealey

The 3D driver Genesi has for XGI cards is compatible with the XGI Z7, V3XT, V5, V8, V8 dual core, 8600 and the corresponding embedded variants. We might be adding some support for 8300, but that is not sure yet. ( I need access to a PCIe motherboard with Genesi firmware, and I have not been able to get access to an OSW or one of the other PCIe enabled boards with Genesi Firmware yet ). We do not support old SiS/Trident cards, even though XGI solutions contain both SiS and Trident IP.

The driver source code is about 50 megabyte large.

What people often forget is that for a GPU vendor like ATI and Nvidia to support your platform the GPU vendor has to make a substantial investment. An ATI or Nvidia driver for the Power architecture costs money because engineers have to port the code, and support application providers with fixing driver bugs that are discovered. Getting the driver tested it not easy either. The lifespan of a graphic card is about 12 to 18 months, so the driver has to be continously updated, maintained and supported. That cost money and if you're not selling a few million boards every six months, you'll have a hard time getting vendors like ATI or Nvidia to support you with a driver for every GPU imaginable. I don't think they have some sort of trade embargo for people making Power architecture devices, but it needs to make sense for them to do business.

Open Sourcing a 3D driver is not that easy either because X.org and the Linux kernel change continuously. Even vendors like ATI and Nvidia have trouble keeping up with the continuously evolving open source environment (Newest release of X.org broke both drivers!). If you make your driver open source, it will be modified, cut into pieces and glued together into something your engineers no longer are familiar with when you release new hardware. X.org and Linux developers don't care (and don't know) about some of the driver design features your engineers implemented to allow for example code reuse on Windows. Do you want your engineers to be telling them, or implementing a driver for a new board that is scheduled for release in for example six months? By the time you make a new board, the engineers who wrote the orginal driver, will no longer be able to implement support for this new card because they have to talk to developers located all over the world to figure out where a function went, why something changed and who to talk to get something included. Forget thinking in terms of time to market, start worrying about whether you'll ever get new stuff to market. The only way you can be sure you'll get a card with driver to market before the competition is to clone your engineering staff so that you'll be able to more/less control how a driver that is open sourced evolves, and still be able to get new functionality in. Open source developers will not implement support for new hardware in your open source driver. Making sure your engineers are aware about what is happening in the open source community is costly and requires extra staff.

The vendor has to spend money and isn't sure that he'll sell more GPUs. Are people buying Sparc computers because the cpu design is GPL'ed? Or do they buy the closed source, cheaper alternatives? The answer is not clear cut if you ask me.

Also, please don't forget that if you plug in a Graphic card on a Power motherboard, that won't work automagically. Graphic cards contain embedded x86 BIOS instructions in ROM. If you want to use a graphic card, you either have to translate that ROM code to something that is useable on PowerPC (Which you cannot do for every card, you have to make a selection, and spend lots of engineering resources, ...) or you can license Genesi Firmware, which is the only OpenFirmware implementation that includes an x86 BIOS Rom code interpreter and can initialize -any- graphic card on a non-x86 architecture just fine. A third option (which is what Apple did) is to ask GPU vendors to make custom cards for your platform. That didn't work well for Apple. E.g. many bought an Apple Quad G5, but realized they should have gone with the 7800 instead of the 6600 GPU, but couldn't upgrade without spending like $1000 on a custom card which costs only $250 for x86 users. Apple was continuously lagging behind x86 because it needed custom stuff and didn't have something like the Genesi x86 BIOS rom emulator in their firmware implementation.

Regarding the XGI roadmap: The great thing about XGI is that they make cards with very unique features. You have a High-Def mpeg decoder on board of every card (except for the Z7), you have 5-field motion deinterlacing, which is the best thing available on the market. The cards are cheaper. 3D support is better than the reverse engineered ATI drivers. I doubt it is good idea to get your hopes up and expect $1000 SLI or Crossfire graphic cards from XGI. (You can still use such an ATI card with our board if you wanted to) What you can expect is just enough 3D and cool stuff like mpeg decoders, maybe even h264 accelerators, best of class deinterlacers, composite / s-video out, etc. XGI has their niche market and they're supporting us. XGI is a SiS spin-off, XGI bought Trident four years ago. SiS has a part in the Xbox360, XGI is found in many laptop and desktop computers (e.g Dell computers).

Regarding Genesi plans for XGI: Any strategy for an XGI driver for the Power architecture will involve getting XGI cards and Power development boards in the hands of developers. I was hoping we could bundle XGI cards with the Efika development boards but unfortunately the Efika doesn't seem to be shipping yet. OS vendors etc. interested in driver development can then be exposed to the source code/documentation and can roll their own binary, individual developers can fix any bugs they discover. Any changes have to be fed to our developers or made in a branch of our SCM repository, so we can figure out the best way of managing/merging them. The kernel parts will be GPL right from the start (and we hope they get forked/merged into the kernel), the 3D X part will have low barriers to source code and documentation, but we need to manage and control this initially and come up with a plan for open sourcing the entire driver if that is what the market wants.

Let me rephrase: EVERY opensource player bypass Macrovision, on decent system you can't care more about Macrovision.
That is mplayer, xine, vlc, ogle and so on.
Nope as long as I can vote with my money and make other people aware that they would be paying with their money something that isn't useful at all.
No, there isn't, the fact there is only one means that every people intereste on in worked on a single source since there isn't much to say.

If the XGI driver will get polished enough to be part of Xorg you won't have to care the same way.
Name them
No, blender got gpl'd because their developers went that way and got the community supporting that decision paying quite a lot of money to get all the source free from bindings.

What is preventing anybody me or anybody to fork it? Nothing as long as I comply with GPL. In practice, nobody has problems with that software that the current development team isn't addressing.

doesn't happen for r300 or any other video driver, tell me why it should happen for xgi.

Oh does this mean the efika will have a graphics 'card' or will the chip be on the board itself?

good point no vendor is willing to pour money into a proverbial hole if they cant turn a profit from hardware sales to that particular platform. However the concept of open sourcing certain components of graphics drivers (like ATI is thinking about) can be a good strategy to increase market saturation because at the moment the only option for good 3d support on x86 is nvidia and as a result nvidia dominates the linux market (much like a monopoly)

The last time I asked the plan was to ship the board with a PCI slot and a riser because that was most flexible solution. We might do an Efika with an embedded gpu afterwards but that depends on a number of factors. Please take this with a grain of salt. Matt is at the source and can probably be more specific about what we will be shipping when.

Sorry for digging up this old topic :P But has anyone heard of the present state of the XGI drivers for PPC?

Yes. We have ported XGI's proprietary Linux driver to the Power Architecture. Our firmware brings up the card correctly. Framebuffer, native X driver all works flawlessly. We recently started adding Xvmc support to the driver.

XGI is currently deciding how and if it will manage the process of open sourcing their driver. The 3D part of the driver (in its current state) needs to be rewritten if adoption by the Mesa project is part of the medium-long term plan. The scope of our involvement (and what graphics hardware we will bring to market) depends on this rather important strategic decision.

Great, so are the working drivers available for download?