Jerome Glisse wrote: > On Mon, 2009-06-08 at 11:54 +0300, Shachar Kaufman wrote: >> Hi Guys, >> >> Since working with Mesa 7.3 and building my driver kept me quite busy, >> and in spite some scouting I'm not really up to speed with Gallium, >> DRI2 state trackers and other 7.5 mumbo jumbo. >> >> I have an X driver but, for performance, the driver I eventually used >> is something new I added on the "src/drivers" level to patch into my >> embedded platform's native API. I'd like to start porting this >> embedded graphics system driver from Mesa 7.3 to 7.5. >> >> 1. Am I thinking straight? >> >> My rationale for doing this is that I'd like to use the recent >> additions making GLES and OpenVG available - first for the sake of >> playing with them, and second hoping this would be a good way of >> getting something like SVG working smoothly on my platform. I can't >> find alternative implementations for Linux and implementing these >> myself is well beyond my reach. I'm concerned that for instance SVG >> won't get accelerated since there's no SW implementation yet that I >> could find to use OpenVG (I suppose since until now there was no real >> OpenVG support...) but that's another matter. >> >> 2. Where do I start then? >> >> First I need to get better acquainted with the driver modules >> necessary for the new architecture - what's the best way of doing >> this?. >> Then you'll probably say read the latest RC code. Fine - what parts of >> it then? for each module of driver that I need to write, which >> existing drivers set a good example? >> >> If I've neglected to mention information necessary for obtaining the >> directions I seek do let me know and I'll fill in the gaps. >> >> Cheers! >> s > > > You need to write a gallium driver if you want to take advantage of > state tracker like openvg/opengles ... Gallium require that your > hw support fragment shader like GLSL (it could be a subset of GLSL > and your driver will fallback to software on shader it doesn't > support).
To be technical, you need to support all of ARB_fragment_program's opcodes in your fragment shader. GLSL/ARB_fragment_shader support is nice, but not technically required. Everything else is optional. > I think the easiest working driver is i915simple but there are lot > others driver see : > > http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers i915's the best one to use as a template/read through. r300 is very clean but also very incomplete. :3 > Basically driver is split in two half the core driver which does > the GPU rendering command stream built and the winsys layer which > is responsible to provide an interface for the core driver to > submit command to the GPU see : > > http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/drm > > I don't think there is better documentation than code. Yeah, you'll have to provide a winsys layer. The winsys is basically glue to manage buffers, and the common Linux winsys all use DRM for that. Most of the current ones are based on KMS kernel-side MM; I don't exactly know how your HW is set up, but presumably it's got some way to handle buffers. Additionally, Gallium's API is not stable yet, so out-of-tree drivers will suffer since we can't update them whenever the API changes. Why not add your driver to the main tree? ~ C. ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
