Home | History | Annotate | Line # | Download | only in sna
      1  1.1  mrg SandyBridge's New Acceleration
      2  1.1  mrg ------------------------------
      3  1.1  mrg 
      4  1.1  mrg The guiding principle behind the design is to avoid GPU context switches.
      5  1.1  mrg On SandyBridge (and beyond), these are especially pernicious because the
      6  1.1  mrg RENDER and BLT engine are now on different rings and require
      7  1.1  mrg synchronisation of the various execution units when switching contexts.
      8  1.1  mrg They were not cheap on early generation, but with the increasing
      9  1.1  mrg complexity of the GPU, avoiding such serialisations is important.
     10  1.1  mrg 
     11  1.1  mrg Furthermore, we try very hard to avoid migrating between the CPU and GPU.
     12  1.1  mrg Every pixmap (apart from temporary "scratch" surfaces which we intend to
     13  1.1  mrg use on the GPU) is created in system memory. All operations are then done
     14  1.1  mrg upon this shadow copy until we are forced to move it onto the GPU. Such
     15  1.1  mrg migration can only be first triggered by: setting the pixmap as the
     16  1.1  mrg scanout (we obviously need a GPU buffer here), using the pixmap as a DRI
     17  1.1  mrg buffer (the client expects to perform hardware acceleration and we do not
     18  1.1  mrg want to disappoint) and lastly using the pixmap as a RENDER target. This
     19  1.1  mrg last is chosen because when we know we are going to perform hardware
     20  1.1  mrg acceleration and will continue to do so without fallbacks, using the GPU
     21  1.1  mrg is much, much faster than the CPU. The heuristic I chose therefore was
     22  1.1  mrg that if the application uses RENDER, i.e. cairo, then it will only be
     23  1.1  mrg using those paths and not intermixing core drawing operations and so
     24  1.1  mrg unlikely to trigger a fallback.
     25  1.1  mrg 
     26  1.1  mrg The complicating case is front-buffer rendering. So in order to accommodate
     27  1.1  mrg using RENDER on an application whilst running xterm without a composite
     28  1.1  mrg manager redirecting all the pixmaps to backing surfaces, we have to
     29  1.1  mrg perform damage tracking to avoid excess migration of portions of the
     30  1.1  mrg buffer.
     31