Would something like mesa/r600_demo be appropriate ? -----Original Message----- From: Keith Whitwell [mailto:kei...@vmware.com] Sent: Friday, July 17, 2009 9:24 AM To: Harald Welte Cc: dri-devel@lists.sourceforge.net; richard...@via.com.tw; gre...@suse.de; brucech...@via.com.tw; josephc...@via.com.tw; benjamin...@viatech.com Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Fri, 2009-07-17 at 04:37 -0700, Harald Welte wrote: > On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote: > > On Fri, Jul 17, 2009 at 4:36 PM, <brucech...@via.com.tw> wrote: > > > To whom it may ceoncern: > > > The following 3 patches are the DRM kernel module that support VIA Chorme9 GFX chipset. They are based on 2.6.31-rc3. Please kindly help to integrate into kernel. > > > > > > > Is there a userspace, or available documentation to write a > > userspace to use this code. > > Dear David, the situation is still like it was some time ago: > > 1) VIA's 3D Xorg driver cannot be released as FOSS since it cotains 3rd party > licensed code > > 2) VIA is very supportive of anybody in the community who will work on a FOSS > 3D driver for Chrome9. However, we are not aware of any such > project :( > > 3) VIA has released all the programming documentation that it has for this > specific chipset, it is available from http://www.x.org/docs/via/ > What is still missing is the pixel shader documentation, which will join > those public documents soon. > > 4) VIA does not have the resources to write an entirely new 3D driver for > Chrome9, especially since future products contain a different, incompatible > GPU. I think it's much more useful to focus the resources at getting things > "right" for those future products. > > So, as you can see, the situation is far from being perfect. However, > it could also be much worse. > > I would be the first person to argue in favour of having some FOSS > userspace code against this DRM kernel driver - but I can also > understand the practical constraints. Given that the technical issues > (32bit ioctl compat, ...) can be adressed, I would hope the driver can get merged. > > So far I was not aware that there is an absolute precondition of > existing 3D FOSS userspace code to get a DRM driver merged. Yes, we > all want it. But is it a strong requirement? Maybe VIA can provide some userspace code without putting together an entire driver. A handful of standalone programs that exercise the interface would help evaluate the interfaces and might be sufficient to serve as guide to someone wanting to use this module. A handful would include: -- draw a triangle -- draw a textured triangle -- draw a triangle using indexed vertices -- some sort of occlusion query At least then there would be some concrete examples of this in use so that an interested party wouldn't later have to work from scratch. Keith ------------------------------------------------------------------------ ------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
