#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