----- 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
