diff options
author | Andreas Sandberg <andreas.sandberg@arm.com> | 2015-05-23 13:37:03 +0100 |
---|---|---|
committer | Andreas Sandberg <andreas.sandberg@arm.com> | 2015-05-23 13:37:03 +0100 |
commit | db5c9a5f9028fd87a74e1750068511bd311435ae (patch) | |
tree | d2d2125ce8f717355187c767599945ad354470e9 /src/dev/arm/hdlcd.hh | |
parent | 1985d28ef905753423b3ee407c8bf4ee9165302b (diff) | |
download | gem5-db5c9a5f9028fd87a74e1750068511bd311435ae.tar.xz |
base: Redesign internal frame buffer handling
Currently, frame buffer handling in gem5 is quite ad hoc. In practice,
we pass around naked pointers to raw pixel data and expect consumers
to convert frame buffers using the (broken) VideoConverter.
This changeset completely redesigns the way we handle frame buffers
internally. In summary, it fixes several color conversion bugs, adds
support for more color formats (e.g., big endian), and makes the code
base easier to follow.
In the new world, gem5 always represents pixel data using the Pixel
struct when pixels need to be passed between different classes (e.g.,
a display controller and the VNC server). Producers of entire frames
(e.g., display controllers) should use the FrameBuffer class to
represent a frame.
Frame producers are expected to create one instance of the FrameBuffer
class in their constructors and register it with its consumers
once. Consumers are expected to check the dimensions of the frame
buffer when they consume it.
Conversion between the external representation and the internal
representation is supported for all common "true color" RGB formats of
up to 32-bit color depth. The external pixel representation is
expected to be between 1 and 4 bytes in either big endian or little
endian. Color channels are assumed to be contiguous ranges of bits
within each pixel word. The external pixel value is scaled to an 8-bit
internal representation using a floating multiplication to map it to
the entire 8-bit range.
Diffstat (limited to 'src/dev/arm/hdlcd.hh')
-rw-r--r-- | src/dev/arm/hdlcd.hh | 18 |
1 files changed, 14 insertions, 4 deletions
diff --git a/src/dev/arm/hdlcd.hh b/src/dev/arm/hdlcd.hh index ba22cc163..61d2dc5d7 100644 --- a/src/dev/arm/hdlcd.hh +++ b/src/dev/arm/hdlcd.hh @@ -1,5 +1,5 @@ /* - * Copyright (c) 2010-2013 ARM Limited + * Copyright (c) 2010-2013, 2015 ARM Limited * All rights reserved * * The license below extends only to copyright in the software and shall @@ -83,13 +83,15 @@ #define __DEV_ARM_HDLCD_HH__ #include <fstream> +#include <memory> +#include "base/bitmap.hh" +#include "base/framebuffer.hh" #include "dev/arm/amba_device.hh" #include "params/HDLcd.hh" #include "sim/serialize.hh" class VncInput; -class Bitmap; class HDLcd: public AmbaDmaDevice { @@ -142,6 +144,8 @@ class HDLcd: public AmbaDmaDevice /** AXI port width in bytes */ static const size_t AXI_PORT_WIDTH = 8; + static const size_t MAX_BURST_SIZE = MAX_BURST_LEN * AXI_PORT_WIDTH; + /** * @name RegisterFieldLayouts * Bit layout declarations for multi-field registers. @@ -242,11 +246,13 @@ class HDLcd: public AmbaDmaDevice /** Pixel clock period */ const Tick pixelClock; + FrameBuffer fb; + /** VNC server */ VncInput *vnc; /** Helper to write out bitmaps */ - Bitmap *bmp; + Bitmap bmp; /** Picture of what the current frame buffer looks like */ std::ostream *pic; @@ -325,7 +331,7 @@ class HDLcd: public AmbaDmaDevice bool frameUnderrun; /** HDLcd virtual display buffer */ - uint8_t *virtualDisplayBuffer; + std::vector<uint8_t> virtualDisplayBuffer; /** Size of the pixel buffer */ size_t pixelBufferSize; @@ -402,6 +408,8 @@ class HDLcd: public AmbaDmaDevice return fb_line_count.fb_line_count; } + inline size_t area() const { return height() * width(); } + /** * Gets the total number of pixel clocks per display line. * @@ -436,6 +444,8 @@ class HDLcd: public AmbaDmaDevice /** Called when it is time to render a pixel */ void renderPixel(); + PixelConverter pixelConverter() const; + /** Start of frame event */ EventWrapper<HDLcd, &HDLcd::startFrame> startFrameEvent; |