#1671 NORM Gen2: DCON2 wishlist

Zarro Boogs per Child bugtracker at laptop.org
Sat Jun 9 14:21:46 EDT 2007


#1671: DCON2 wishlist
-------------------------+--------------------------------------------------
 Reporter:  ajax         |       Owner:  mlj 
     Type:  enhancement  |      Status:  new 
 Priority:  normal       |   Milestone:  Gen2
Component:  hardware     |     Version:      
 Keywords:               |    Verified:  0   
-------------------------+--------------------------------------------------
 DCON was a good start, but could be a lot better.  The following is a
 running log of things to address or consider in the next version.

 The current DCONLOAD semantics are just broken.  "Load a frame and take
 over display" is one atomic operation, which essentially means userspace
 has to stall rendering for a full frame time in order to ensure the DCON
 loads a buffer that's not in the middle of being drawn.  (Alternatively,
 it doesn't stall, but the half-drawn result stays on screen for at least
 one full frame time, since it takes at least one frame to go back from
 DCON to GPU.)  "Load a frame into DCON RAM" and "take over display" should
 be independent operations.

 For that matter, we don't really know what the power draw would be if the
 DCON were just continuously loading frames.  X doesn't have a way of
 knowing nothing's going to be drawn in the future, it has to guess.
 Currently the heuristic is "well, nothing's been drawn for a frame time".
 At which point, we have to wait another frame for DCON to load.  If DCON's
 shadow buffer were continuously loading, this would be less of an issue;
 the heuristic would instead be "nothing's been drawn for a frame time, so
 flip to DCON control _now_".  Much faster.

 GPU->DCON transtions are glitch free because the DCON will slave frame
 start to the incoming vblank.  This is really hard to do in the other
 direction, because on most GPUs you don't get a way to halt and reset the
 output of the pixel pump to line 0, and the pixel clocks drift relative to
 each other.  (You could in principle try to PLL the two clocks together,
 but that means waking up a lot.)  Geode LX, and many other GPUs, can
 genlock to an external sync source, which ought to just be generated from
 the DCON all the time, and would make the reverse transition way easier to
 do glitch-free.

 DCON's maximum output refresh rate is locked at 50Hz, and it can only
 divide down from there.  It would be pleasant to be able to speed it up as
 well.  The panel likely doesn't care that much how fast you clock data in
 (up to a point), and being able to complete a frame quickly would allow us
 to get in and out of DCON control faster, which means better perceptual
 latency.  Right now it looks like there's no way to be in DCON control for
 less than 40ms, which is a big chunk of the ~100ms perceptual threshold.
 Shouldn't even be a problem for the AV people, since they're never going
 to want the DCON to have control anyway.

 If you want to go really second-system, just implement the good bits out
 of DPVL.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1671>
One Laptop Per Child <http://laptop.org/>



More information about the Bugs mailing list