Quote: >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?
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.
|
