[Mesa-dev] [RFC] preparation for qxl sw wrapper driver

Dave Airlie airlied at gmail.com
Mon Mar 18 21:40:35 PDT 2013


So we have this virtual GPU with nothing approaching a 3D engine,
so we are currently running llvmpipe with drisw on it. However
this incurs some overheads that now that we have a kernel driver,
I believe we can remove.

The main overheads are putimage for all rendering from
a 3D compositor and getimage calls for all texture-from-pixmap
operations. So implementing a dri2 qxl driver that wraps
llvmpipe operations using the sw winsys wrapper, seemed like
a good idea.

So I ran into two problems implementing this,
a) QXL rendering upside down, so when you texture from pixmap,
what you get is upside down. Now we can handle this my supporting
negative strides in enough places so texture sampling works. I've
done this in patch 1, it just changes a bunch of unsigned->int,
and works for me with the QXL driver once it adjust the transfer
map to point at the other end of the texture.

b) So DRI2 expects the hw/kernel to deal with the TFP ordering
of the DDX rendering and the 3D driver using the output. However
when your 3D driver is actually a sw renderer, you need some
way to make sure the rendering on the GPU is finished before
sampling. Now I expected we'd get a texture transfer for every
access, but it appears we set the texture transfers up for dri2
buffers once in their lifetime, which kinda makes sense. So I
saw there is an update_tex_buffer hook that looked like I could use
it. So I added new hooks into the pipe screen and sw winsys
to make it all happen.

These are both RFCs, I'd like to know if people have any better
ideas on how to handle these, I think the second case might be
something someone who knows the dri state trackers a bit better
might come up with something decent for. The first case I do
feel like handling negative strides is useful in some cases,
but I'm not sure how far we'd need to expand it (I don't
think rendering to negative strides works) and test coverage
could be fun.

Dave.



More information about the mesa-dev mailing list