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

[Jose Fonseca]

----- Original Message -----
> 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.

I have no particular objection with the above in principle, as this seems a perfectly valid use of llvmpipe.

I just have some remarks on implementation details done separately.


For my curiosity sake, how much these changes matter in practice? (For example, what is the % effect of gloss FPS in normal window and fullscreen?)

Jose