{{Short description|Computer graphics design system for retained mode command storage and execution}}
{{off topic|date=January 2024}}
A '''display list''', also called a command list in Direct3D 12 and a command buffer in Vulkan, is a series of graphics commands or instructions that are run when the list is executed.<ref>{{cite web |title=Chapter 7 - OpenGL Programming Guide |url=https://www.glprogramming.com/red/chapter07.html |accessdate=18 November 2018 |website=www.glprogramming.com |publisher=Addison-Wesely}}</ref> Systems that make use of display list functionality are called retained mode systems, while systems that do not are as opposed to immediate mode systems. In OpenGL, display lists are useful to redraw the same geometry or apply a set of state changes multiple times.<ref name=":3">{{cite book |title=OpenGL programming guide: the official guide to learning OpenGL, version 1.1 |date=1997 |publisher=Addison Wesley |isbn=978-0201461381 |edition=2nd}}</ref><ref>Mark Segal, Kurt Akeley, ''The Design of the OpenGL Graphics Interface.'' http://www.graphics.stanford.edu/courses/cs448a-01-fall/design_opengl.pdf</ref> This benefit is also used with Direct3D 12's bundle command lists. In Direct3D 12 and Vulkan, display lists are regularly used for per-frame recording and execution.
==Origins in vector displays== The vector monitors or ''calligraphic displays'' of the 1960s and 1970s used electron beam deflection to draw line segments, points, and sometimes curves directly on a CRT screen. Because the image would immediately fade, it needed to be redrawn many times a second (storage tube CRTs retained the image until blanked, but they were unsuitable for interactive graphics). To refresh the display, a dedicated CPU called a Display Processor or Display Processing Unit (DPU) was used, which had a memory buffer for a "display list", "display file", or "display program" containing line segment coordinates and other information. Advanced Display Processors also supported control flow instructions, which were useful for drawing repetitive graphics such as text, and some could perform coordinate transformations such as 3D projection.<ref>{{cite web | url=https://rottedbits.blogspot.com/2013/05/an-introduction-to-imlac-pds-1.html | title=An introduction to the Imlac PDS-1 | last=Dersch | first=Josh | date=10 May 2013 | access-date=1 September 2024}}</ref><ref>{{cite book | last1=Foley | first1=James D. | author-link1=James D. Foley | last2=Van Dam | first2=Andries | author-link2=Andries van Dam | year=1982 | title=Fundamentals of Interactive Computer Graphics | publisher=Addison-Wesley Publishing Company, Inc. | isbn=0-201-14468-9 | pages=19, 93-94, 394, 400-404}}</ref>
==Home computer display list functionality== One of the earliest systems with a true display list was the Atari 8-bit computers. The display list (actually called so in Atari terminology) is a series of instructions for ANTIC, the video co-processor used in these machines. This program, stored in the computer's memory and executed by ANTIC in real-time, can specify blank lines, any of six text modes and eight graphics modes, which sections of the screen can be horizontally or vertically fine-scrolled, and trigger Display List Interrupts (called raster interrupts or HBI on other systems).<ref>{{cite book | last1=Small | first1=David | last2=Small | first2=Sandy | last3=Blank | first3=George | title=The Creative Atari | date=1983 | isbn=978-0-916688-34-9 | page=| publisher=Creative Computing Press }}</ref>
The Amstrad PCW family contains a Display List function called the 'Roller RAM'. This is a 512-byte RAM area consisting of 256 16-bit pointers in RAM, one for each line of the 720 × 256 pixel display. Each pointer identifies the location of 90 bytes of monochrome pixels that hold the line's 720 pixel states. The 90 bytes of 8 pixel states are spaced at 8-byte intervals, so there are 7 unused bytes between each byte of pixel data. This suits how the text-orientated PCW constructs a typical screen buffer in RAM, where the first character's 8 rows are stored in the first 8 bytes, the second character's rows in the next 8 bytes, and so on. The Roller RAM was implemented to speed up display scrolling as it would have been unacceptably slow for its 3.4 MHz Z80 to move up the 23 KB display buffer 'by hand' i.e. in software. The Roller RAM starting entry used at the beginning of a screen refresh is controlled by a Z80-writable I/O register. Therefore, the screen can be scrolled simply by changing this I/O register.{{Citation needed|date=January 2024}}
Another system using a Display List-like feature in hardware is the Amiga, which, not coincidentally, was also designed by some of the same people who developed the custom hardware for the Atari 8-bit computers. Once directed to produce a display mode, it would continue to do so automatically for every following scan line. The computer also included a dedicated co-processor, called "Copper", which ran a simple program or 'Copper List' intended for modifying hardware registers in sync with the display. The Copper List instructions could direct the Copper to wait for the display to reach a specific position on the screen, and then change the contents of hardware registers. In effect, it was a processor dedicated to servicing raster interrupts. The Copper was used by Workbench to mix multiple display modes (multiple resolutions and color palettes on the monitor at the same time), and by numerous programs to create rainbow and gradient effects on the screen. The Amiga Copper was also capable of reconfiguring the sprite engine mid-frame, with only one scanline of delay. This allowed the Amiga to draw more than its 8 hardware sprites, so long as the additional sprites did not share scanlines (or the one scanline gap) with more than 7 other sprites. i.e., so long as at least one sprite had finished drawing, another sprite could be added below it on the screen. Additionally, the later 32-bit AGA chipset allowed the drawing of bigger sprites (more pixels per row) while retaining the same multiplexing. The Amiga also had dedicated block-shifter ("blitter") hardware, which could draw larger objects into a framebuffer. This was often used in place of, or in addition to, sprites.{{Citation needed|date=January 2024}}
In more primitive systems, the results of a display list can be simulated, though at the cost of CPU-intensive writes to certain display modes, color control, or other visual effect registers in the video device, rather than a series of rendering commands executed by the device. Thus, one must create the displayed image using some other rendering process, either before or while the CPU-driven display generation executes. In many cases, the image is also modified or re-rendered between frames. The image is then displayed in various ways, depending on the exact way in which the CPU-driven display code is implemented.{{Citation needed|date=January 2024}}
Examples of the results possible on these older machines requiring CPU-driven video include effects such as Commodore 64/128's [http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm FLI] mode, or Rainbow Processing on the ZX Spectrum.{{Citation needed|date=January 2024}}
==Usage in OpenGL== To delimit a display list, the <code>glNewList</code> and <code>glEndList</code> functions are used, and to execute the list, the <code>glCallList</code> function is used. Almost all rendering commands that occur between the function calls are stored in the display list. Commands that affect the client state are not stored in display lists.<ref name=":0">{{Cite book |last=Martz |first=Paul |url=https://books.google.com/books?id=ckpNmNlLE_sC&q=display+list&pg=PR7 |title=OpenGL Distilled |publisher=Addison-Wesley Professional PTG |year=2006 |isbn=9780132701785 |edition=1st |pages= |access-date=28 December 2023}}</ref> Display lists are named with an integer value, and creating a display list with the same name as one already created overrides the first.<ref>{{Cite book |last1=Wright |first1=Richard S. |url=https://dl.acm.org/doi/10.5555/1895026 |title=OpenGL SuperBible: Comprehensive Tutorial and Reference |last2=Haemel |first2=Nicholas |last3=Sellers |first3=Graham |last4=Lipchak |first4=Benjamin |publisher=Addison-Wesley Professional |year=2010 |isbn=978-0-321-71261-5 |edition=5th}}</ref>
The <code>glNewList</code> function expects two arguments: an integer representing the name of the list, and an enumeration for the compilation mode. The two modes include <code>GL_COMPILE_AND_EXECUTE</code>, which compiles and immediately executes, and <code>GL_COMPILE</code>, which only compiles the list.<ref>{{Cite web |last=White |first=Steve |date=2021-03-09 |title=glNewList function (Gl.h) - Win32 apps |url=https://learn.microsoft.com/en-us/windows/win32/opengl/glnewlist |access-date=2023-12-28 |website=learn.microsoft.com |language=en-us}}</ref>
Display lists enable the use of the retained mode rendering pattern, which is a system in which graphics commands are recorded (retained) to execute in succession at a later time. This is contrary to immediate mode, where graphics commands are immediately executed on client calls.<ref name="rm_vs_im">{{Cite web|title = Retained Mode Versus Immediate Mode|work = Win32 apps|author = Quinn Radich|publisher = Microsoft|date = May 30, 2018|access-date = 21 December 2019|url = https://docs.microsoft.com/en-us/windows/win32/learnwin32/retained-mode-versus-immediate-mode}}</ref>
==Usage in Direct3D 12== Command lists are created using the <code>ID3D12Device::CreateCommandList</code> function.<ref name=":1">{{Cite web |last1=White |first1=Steven |last2=Jenks |first2=Alma |last3=badasahog |last4=Coulter |first4=David |last5=Kelly |first5=John |last6=Kinross |first6=Austin |last7=Wenzel |first7=Maira |last8=Jacobs |first8=Mike |last9=Satran |first9=Michael |date=2021-12-30 |title=Creating and recording command lists and bundles - Win32 apps |url=https://learn.microsoft.com/en-us/windows/win32/direct3d12/recording-command-lists-and-bundles |access-date=2024-01-05 |website=learn.microsoft.com |language=en-us}}</ref> Command lists may be created in several types: direct, bundle, compute, copy, video decode, video process, and video encoding. Direct command lists specify that a command list the GPU can execute, and doesn't inherit any GPU state.<ref name=":2">{{Cite web |last=White |first=Steve |date=2023-02-14 |title=D3D12_COMMAND_LIST_TYPE (d3d12.h) - Win32 apps |url=https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_command_list_type |access-date=2024-01-06 |website=learn.microsoft.com |language=en-us}}</ref> Bundles, are best used for storing and executing small sets of commands any number of times. This is used differently than regular command lists, where commands stored in a command list are typically executed only once.<ref name=":1" /> Compute command lists are used for general computations, with a common use being calculating mipmaps.<ref>{{Cite web |last=Loggini |first=Riccardo |date=2020-10-31 |title=Compute Shaders in D3D12 |url=https://logins.github.io/graphics/2020/10/31/D3D12ComputeShaders.html |access-date=2024-01-06 |website=Riccardo Loggini |language=en-US}}</ref> A copy command list is strictly for copying and the video decode and video process command lists are for video decoding and processing respectively.<ref name=":2" />
Upon creation, command lists are in the recording state. Command lists may be re-used by calling the <code>ID3D12GraphicsCommandList::Reset</code> function. After recording commands, the command list must be transitioned out of the recording state by calling <code>ID3D12GraphicsCommandList::Close</code>. The command list is then executed by calling <code>ID3D12CommandQueue::ExecuteCommandLists</code>.<ref name=":1" />
==See also== * List of home computers by video hardware * Scanline rendering
==Further reading==
* White, Steven; Danielsson, David; Jenks, Alma; Satran, Michael (2023-03-08). "Design Philosophy of Command Queues and Command Lists - Win32 apps". ''learn.microsoft.com''. Retrieved 2024-01-26.
==References== {{reflist}}
Category:Computer graphics Category:OpenGL Category:DirectX