[Mesa-dev] New "state tracker": Pylladium

[José Fonseca]

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