On Sun, 2010-05-02 at 09:34 -0700, Corbin Simpson wrote: > So I got bored a few days ago and broke ground on a little bit of code > I've had in mind for a while. This is a new state tracker, Pylladium, > that acts to expose the core Gallium objects of a driver in a clean, > Pythonic fashion, without being overly low-level or abstracted away. > > So why make another tracker when there's already a great one maintained by > Jose? > > 1) SWIG. The current tracker must be compiled against a pipe driver > library, and can't dynamically switch between drivers. Additionally, > it can't be run on any Python besides CPython, which is mostly a > personal annoyance but something some people honestly have to work > with.
This was true at start, but actually this is not strictly true anymore -- it does not need to be compiled against a pipe driver besides softpipe/llvmpipe. It uses custom GLX/WGL extensions to use the driver in system's DLL, but I never got around to implement the GLX extesion on Linux. (^_^;) > 2) The interface, being SWIG'd, is a straight copy of the interface > defined in the Gallium headers, which isn't very Python-friendly. In > particular, there's no encapsulation. Zack indicated this was a > feature, not a bug, and frankly, I agree. It was designed to replicate > the Gallium interface in Python, and it does it well. No need to > change it. > 3) I could not pass up the pun. Seriously, I've been sitting on it for > months, and I finally got fed up and acted on it. > > You can take a look at the general direction I've taken at > http://cgit.freedesktop.org/~csimpson/pylladium . It acts on raw > Gallium drivers, something not present yet in master. My raw-targets > branch of Mesa (http://cgit.freedesktop.org/~csimpson/mesa/log/?h=raw-targets) > has a r300g target already and I have an i915g target that I'll push > when I get home later. These drivers make drm_api_create being > publicly accessible. (I needed to do this because one cannot dlopen() > DRI or EGL drivers in the general case.) A softpipe variant using > null_sw_winsys should be fairly trivial, but I haven't done it yet. > > One thing that I feel is important: This isn't meant to be performant. > At all. Buffers are going to be displayed through a variety of fairly > slow methods, most of them likely involving PIL. ctypes is the binding > I'm using, and it incurs a fair overhead on anything besides PyPy. > This is meant to be a clear demonstration of how the objects in > Gallium interact and work, more than anything else. ctypes is a very nice library. I used it before and was very happy. It is much easier to make bindings pythonic from the python side than from the C side. The drawback is that it requires replicating the structure declarations in python. In particular bitfields thoroughly used in the will be a pain to mimic/maintain. I know there is some .h -> ctypes conversion, but those kind of tools only get 80% of the stuff correctly. > Oh, and a brief demonstration, culled from my main.py: > > da = drm.DrmApi(raw) > > print "Loaded drm_api object, name %s" % da.name > > s = da.create_screen(raw.drmOpen(da.name, None)) > > print "Created screen, name %s vendor %s" % (s.name, s.vendor) > if s.params["GLSL"]: > print "Whoo, GLSL!" > else: > print "No GLSL..." > > b = screen.Bindings() > b.RENDER_TARGET = True > b.SAMPLER_VIEW = True > > g = screen.Geom() > > for name, number in formats.by_name.iteritems(): > if s.is_format_supported(number, 2, b, g): > print "%s is an acceptable FBO colorbuf" % name > > Comments, criticisms, flames, etc. welcome. It's definitely a cool project. My overall feeling is that there is no need for two python state trackers (practically nobody uses the current one except me), but it looks like pylladium still needs quite a bit of work before it covers the full Gallium interface and is ready to be. If you can beef it up and make it a compelling alternative then I'd gladly switch. But in the medium term it seems safer for me to invest in C. In particular I'm thinking of making the trace driver's output format binary and port retrace to C + graw. This will allow to trace complex and long apps, and hopefully get more people maintaining it. > ~ C. > > (Just watch, Phoronix; next time, it'll be a tracker for Flash > rendering. I'll call it, "Galoshes!") lol Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
