gem5 - gem5

Age	Commit message (Collapse)	Author
2017-12-06	base: Split out the pixel class in framebuffer.(cc\|hh).	Gabe Black
	These are really two separate things. Also, while it's realitively straightforward to write a unit test for the pixel conversion code, the framebuffer object is serializable and brings in more dependencies. Change-Id: If954caeb0bfedb1002cfb1a7a115a00c90d56d19 Reviewed-on: https://gem5-review.googlesource.com/6341 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2015-07-07	base: Add serialization support to Pixels and FrameBuffer	Andreas Sandberg
	Serialize pixels as unsigned 32 bit integers by adding the required to_number() and stream operators. This is used by the FrameBuffer, which now implements the Serializable interface. Users of frame buffers are expected to serialize it into its own section by calling serializeSection().
2015-05-23	base: Redesign internal frame buffer handling	Andreas Sandberg
	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.