To install click the Add extension button. That's it.

The source code for the WIKI 2 extension is being checked by specialists of the Mozilla Foundation, Google, and Apple. You could also do it yourself at any point in time.

4,5
Kelly Slayton
Congratulations on this excellent venture… what a great idea!
Alexander Grigorievskiy
I use WIKI 2 every day and almost forgot how the original Wikipedia looks like.
Live Statistics
English Articles
Improved in 24 Hours
Added in 24 Hours
Languages
Recent
Show all languages
What we do. Every page goes through several hundred of perfecting techniques; in live mode. Quite the same Wikipedia. Just better.
.
Leo
Newton
Brights
Milds

Video Coding Engine

From Wikipedia, the free encyclopedia

Video Code Engine (VCE, was earlier referred to as Video Coding Engine,[1] Video Compression Engine[2] or Video Codec Engine[3] in official AMD documentation) is AMD's video encoding application-specific integrated circuit implementing the video codec H.264/MPEG-4 AVC. Since 2012 it was integrated into all of their GPUs and APUs except Oland.

VCE was introduced with the Radeon HD 7000 series on 22 December 2011.[4][5][6] VCE occupies a considerable amount of the die surface at the time of its introduction[7] and is not to be confused with AMD's Unified Video Decoder (UVD).

As of AMD Raven Ridge (released January 2018), UVD and VCE were succeeded by Video Core Next (VCN).

YouTube Encyclopedic

  • 1/5
    Views:
    469 053
    14 224
    636 901
    132 648
    3 282
  • Creating a Doom-style 3D engine in C
  • AMD's Shadowplay? Advanced Media Framework OBS Codec Tutorial
  • Briggs & Stratton - How To Find Your Engine Model Number
  • Unreal Engine C++ Tutorial - Episode 1: Classes
  • How To Code: Movement Engine In C#

Transcription

[[Clacking noises from a handheld puzzle]] Shalom! How is life, family, circumstances and everything? Ah, that's nice. Anyway, [[Action music starts]] In today's video I am going to show what it takes to create a Doom-style 3D engine from scratch. First, some important questions. Why in the classic PC game of Doom when you make a map, it requires a slow and expensive process of building a "BSP" before the map can be rendered in 3D, while in Duke Nukem 3D's BUILD, you can change the map and render it in real time? Why in Duke Nukem 3D it is possible to create multi-stair buildings and even non-Euclidean geometry, while in Doom it is not? First, let's brush up on some basic vector and perspective calculations. [[Music changes to a calm theme]] Let's declare a wall, which is a line segment, with two ends. An X and Y coordinate for both ends. The player also has an X and Y coordinate, and an angle for where he is looking towards. Let's create some sample BASIC code for visualizing the world we just created. Sorry about using such an obsolete language, but I have found that in graphical programming, BASIC still makes for an excellent prototyping tool. And let's face it: Even if you have never programmed in BASIC, you can probably follow the meaning of this code very well for the most part. The yellow line represents the wall, and the white dot is the player, with a small line that indicates where the player is looking towards. In order to make a first-person engine, the global view must be transformed into a first-person view. This concept should be familiar to anyone who watched my previous video about OpenGL programming. In OpenGL, the camera never moves. Instead, the whole world is moved, rotated and shorn around the perfectly immobile camera. Here, we do exactly the same. Transform the world. We can see in the second window how the player is always in the center, and the world moves around him. This creates an illusion of a first-person view. But this isn't 3D yet. The third important step we need to learn is perspective. To perspective-project 3D coordinates into 2-dimensional screen coordinates, you take the X and Y coordinates and divide them with the Z coordinate. That's as simple as it is. As you can see here, the wall seems to get smaller when the player moves away from it and larger when the player gets closer. There is a slight problem though: When the wall is even partially behind the player, something odd happens, because of negative signs that are produced by the perspective calculations. Some additional mathematics needs to be added into the program to address this specific problem. Mathematically speaking, it is the hardest part of this all. Frankly, I am not even sure if I am doing it right. To clip the wall, we need to find out where it intersects with the player's field of vision. Finding these intersections involves a formula called "vector cross product". The vector cross product is like black magic. I still don't understand what it does, but somehow it ended up all around in my video after I read a few Wikipedia articles. The wall only needs to be clipped if it's partially behind the player, i.e. one of its Z coordinates is negative. If both are negative, the wall is totally behind the player and it does not even need to be rendered. Now we can see that even when the player gets close to the wall, it is rendered properly. You can change the wireframe wall into a solid wall by rendering vertical lines in a loop. A meaningful scene should also have many walls, not just one. You can notice that ceiling is always everything above the wall, and floor is always everything below the wall. Here I have colored the ceiling gray and the floor blue. The only way this differs from the previous version is that there's now five walls instead of one. This works perfectly as long as your level geometry is completely convex. Convex means that there are no dents in it. It's like a rubberband stretched over all the edge points. Real world scenes, and indeed 3D game maps rarely however are convex. Here's what happens if we try to apply the same algorithm to a non-convex map. It seems to work all right, until... well, it doesn't work right. The engine appears to be drawing a far-side wall over a near-side wall. Well, that's easy to fix, you might think! Let's just reverse the rendering order. And yes, this did fix the error in this very instance, but see, there is now another error, that wasn't there before. Figuring out how to prevent far-side walls from showing through near-side walls is a problem that every 3D engine in the world must solve. A related problem is when you have a huge map that consists of thousands or millions of walls, how to render only those walls that can possibly contribute to the view, and not spend time futilely rendering all those walls that are completely behind other walls? Unsurprisingly there are many different ways to solve both problems. [[Music fades out]] For the remainder of the video, let's study how Duke Nukem 3D solves the latter problem, but could in fact solve both at once, and then create our own 3D engine. [[Ambient action music starts]] This is the Duke Nukem 3D level editor, called "BUILD". Let's create a sample map. So far it's just a simple rectangular room. But suppose we wanted to have the ceiling in one part higher than in another part? We would have to divide the map into two sections, called "sectors". The ceiling and floor heights for different sectors can be adjusted separately. This geometry is still all convex. There are no indents anywhere in the map geometry. Suppose we create some obstacles, though. Now the map geometry contains obstacles and corners through which you cannot see something anymore. In other words, it is non-convex. However, each individual sector of the map is still convex. Non-convex geometry is created by joining several convex sectors together. If you pay attention to how it is all rendered, you will see that there are now two types of walls, or sector edges: Regular walls, that span from our floor to our ceiling. And doorways, or portals, which have three segments: A wall that spans from our floor to their floor; a window through which the next sector can be seen; and finally a wall that spans from their ceiling to our ceiling. In the editor you can see the difference more clearly: A white edge is one where there's nothing behind, i.e. it's a wall that spans from floor to ceiling. And a red edge is an edge between two sectors. We call these red edges, "portals". Now what happens if their floor is lower than the floor of our sector? The lower wall segment just shrinks, until it doesn't get rendered at all. Similar thing happens with the ceiling. The upper wall is rendered downwards beginning from our ceiling, until we reach their ceiling. If their ceiling is higher, we simply start rendering their sector immediately. For the purpose of this video, I created a simple custom map. This map contains multiple sectors, windows between different sectors, staircases, rooms vertically on top of each others, and even non-euclidean geometry. Perfect for our sample program. Going back to my high-tech illustration board, [[Paper shuffling noises]] I drew the map on paper, and numbered each vertex and each sector, and having done that, I wrote those numbers and their coordinates into a text file. Now I am going to do something revolutionary as far as my videos are concerned. I am going to write some C code. Not C++. I know, this sounds incredible. But as I was designing the tutorial program for this video, I thought to myself: Why not write C for a change? After all, there are people in my audience who love C, but are totally lost when I write C++ code. So today is your day: I am writing code that is strictly C with none of those C++ gimmicks. So the first part of this program deals with loading the map that I just showed to you, into data structures used by this program. Because the file handling code is somewhat dull to watch, I sped it up by 200%. Rest assured, I won't do that again in the remainder of this video. Actually, maybe it's just me who is the dull one here. Maybe I should just shut up and let the code speak for itself. This is the part where I regret a little that I chose to write in C. Oh well. Here is the C version of the "vector cross product" function. As you can see, it can be used to implement several other useful functions. I have no idea why it works, but it does, which is the important thing. Now we are getting to the actual drawing code, so please pay attention. Remember how I explained before how everything is going to be drawn using vertical lines? This vline function will be used to draw ceilings, walls, and floors, i.e. the whole screen. No other graphics functions will be needed for our prototype 3D engine. The rendering will begin from the sector where the player is in. All edges of this sector will be processed: The edge is first translated and rotated so it's relative to the player's gaze, and then the signs of the resulting Z coordinates are inspected to determine whether the edge is visible from the player's point of view. Once we have a visible edge, we can do perspective transformation. This transformation is accomplished by these "scale" division calculations. From the perspective transformations, we get screen coordinates: An X coordinate for the left side of the wall and an X coordinate for the right side of the wall, and a Y coordinate for the floor and ceiling heights in both sides of the wall. Oh, before that, we must do the clipping trick that I explained at 2:52 in this video. Anyway, from those coordinates, drawing the wall is just a matter of linear interpolation and calling vline in a loop. We will draw three vertical lines on each X coordinate: One from top of window to the ceiling height, indicating the ceiling. One from the floor height to the bottom of the window, indicating the floor. And one from the ceiling height to the floor height, indicating the wall. For now, we draw walls with different colors when they are portals or when they are actual walls. Here's what it looks like! Remember, walls are drawn white. Portals are drawn red. The floor is blue, and the ceiling is gray. On the right, you can see the map for reference. Observe how a different view gets drawn when the player crosses a sector edge. Now the next step is to add the upper and lower walls, above and below the portal. This was explained at 6:20 in this video, so if you are confused as to what's happening, please watch that part again. [[Music becomes louder as the narrator pauses]] And this is how it changed as a result of this update. The lower wall is drawn in magenta. The upper wall is drawn in white. And the window, or portal, is drawn in red. The only thing remaining is to draw the neighboring sector in that window! To do that, we need three things: First is some means to draw another sector. You could use recursion to do that. Here I used a circular buffer as a queue of pending sector draw requests. Second is the window size. By window, I mean the screen area where this sector can be drawn. For the player's sector, this area is the entire screen. For any neighboring sector, it is a smaller view: There is a left edge (sx1), and a right edge (sx2). Additionally, there's a top and bottom Y coordinate for each column on the screen. This vertical window gets smaller and smaller the deeper you go in the view. And thirdly, you need... Wait, I guess you only need two things after all. This clip shows in slow motion how the screen gets rendered by this algorithm. Aside from the familiar colors, it shows the current window in green. You can see quite clearly how it considers each edge (green) in turn, drawing either a fully white wall, or a white upper wall, a red portal, and a magenta lower wall. Here is another viewpoint. When all edges of the current sector have been rendered, it picks one of the remaining red portals, and repeats the process inside that window. This is the rendering at normal speed. Observe how things like tunnels under the stairs, or windows in walls, are supported without problems. On the right, you can see a from-top illustration of what the player is currently seeing. The current sector is indicated in red shading. Any part of a floor or a ceiling that is currently within the player's view is indicated in green, violet or gray shading, for an effect that looks a bit like a torch beam. Now I cheated here a little, because I demonstrated the program before it was even finished. I didn't even add the main program yet! For the sake of completeness, I will add the remaining parts to the program, so you will not feel cheated. This function, MovePlayer, is responsible for making sure that the game always knows which sector the player currently is in, even as he moves around and crosses the edges of the sectors. Calculating the intersection between two lines is a vital part of the algorithm: The game must know when the player crosses an edge between two sectors. If you are currently in college or high school, or in gymnasium, or in some other type of school, where you study geometry and other advanced aspects of mathematics, it is things like this -- calculating the intersection between the player character's movement vector and the edge of the sector -- where what you have learned in school becomes crucial to your success. Now let me emphasize this: While it is very useful that you learn all these mathematical formulae, the above all, hands down, most important skill that you should learn is the ability to identify the type of the answer you are looking for, and then look for it. In the case of this program: When the player moves from a sector to another sector, you need to identify that you need a way to detect whether two line segments intersect or not. Even if you don't know how to determine whether two line segments intersect, you can use cool websites like Wikipedia or Wolfram Alpha to find your answer, like I did. You don't necessarily need to remember the mathematical formula, though it helps a lot. But if you cannot even identify the problem you are having, it would be very difficult to find an answer to the problem. You could then try asking in the Internet, on sites like Stack Overflow, but chances of getting a good answer would be significantly lower. Here's another instance of where I identified the problem and looked for answers in the Internet. When the player is pushing against the wall, we need to a formula that produces a vector that is parallel to the wall, but has a length that depends on the angle between the player's movement and the wall's direction. This formula is called "vector projection", and I copied it directly from Wikipedia. This produces the "sliding along the wall" effect that is standard in all thirdperson games today. This simple hack here adds support for looking up and down, with the restriction that all walls still remain perfectly vertical. Now, suppose we want to add some depth shading to the walls. A very simple way to do that is to color the vertical line with a darker color when the wall is farther from the camera, i.e. Z coordinate is higher. Here is what it looks like in practice. [[Sporty action music starts]] Compared to the previous version, the difference is huge, even though it is still all drawn using vertical lines of single color. Now, just for my own entertainment, eventually I also added texture mapping to the program. And feeling that isn't enough, I also added lightmapping. I am however not feeling that my texture mapping code is particularly presentable, so I won't show that in my video. If you are interested though, you can read the video description: A link to a page containing all the source code related to this video's programs is included in the video description, including the code that renders textures and precalculates lightmaps using raytracing. Now as usually happens in programming, the devil is in the details: Relatively small things can end up consuming the bulk of the time of the programmer. There are some errors in this program, such as in the collision checks, causing bugs from time to time. I didn't even cover a very important part of adding objects and actors to the scene, such as health packs or enemies, because I couldn't yet think of an efficient way to do it. That will remain as another problem to solve. Thanks for watching! See you next time, bye.

Overview

In "full-fixed mode" the entire computation is done by the fixed-function VCE unit. Full-fixed mode can be accessed through the OpenMAX IL API.
The entropy encoding block of the VCE ASIC is also separately accessible, enabling "hybrid mode". In "hybrid mode" most of the computation is done by the 3D engine of the GPU. Using AMD's Accelerated Parallel Programming SDK and OpenCL developers can create hybrid encoders that pair custom motion estimation, inverse discrete cosine transform and motion compensation with the hardware entropy encoding to achieve faster than real-time encoding.

The handling of video data involves computation of data compression algorithms and possibly of video processing algorithms. As the template compression methods shows, lossy video compression algorithms involve the steps: motion estimation (ME), discrete cosine transform (DCT), and entropy encoding (EC).

AMD Video Code Engine (VCE) is a full hardware implementation of the video codec H.264/MPEG-4 AVC. It is capable of delivering 1080p at 60 frames/sec. Because its entropy encoding block is also a separately accessible Video Codec Engine, it can be operated in two modes: full-fixed mode and hybrid mode.[8][9]

By employing AMD APP SDK, available for Linux and Microsoft Windows, developers can create hybrid encoders that pair custom motion estimation, inverse discrete cosine transform and motion compensation with the hardware entropy encoding to achieve faster than real-time encoding. In hybrid mode, only the entropy encoding block of the VCE unit is used, while the remaining computation is offloaded to the 3D engine of the GPU, so the computing scales with the number of available compute units (CUs).

VCE 1.0

As of April 2014, there are two versions of VCE.[1] Version 1.0 supports H.264 YUV420 (I & P frames), H.264 SVC Temporal Encode VCE, and Display Encode Mode (DEM).

It can be found on:

  • Piledriver-based
    • Trinity APUs (Ax-5xxx, e.g. A10-5800K)
    • Richland APUs (Ax-6xxx, e.g. A10-6800K)
  • GPUs of the Southern Islands generation (GCN1: CAYMAN, ARUBA (Trinity/Richland), CAPE VERDE, PITCAIRN, TAHITI). These are
    • Radeon HD 7700 series (except HD 7790 with VCE 2.0)
    • Radeon HD 7800 series
    • Radeon HD 7900 series
    • Radeon HD 8570 to 8990 (except HD 8770 with VCE 2.0)
    • Radeon R7 250E, 250X, 265 / R9 270, 270X, 280, 280X
    • Radeon R7 360, 370, 455 / R9 370, 370X
    • Mobile Radeon HD 77x0M to HD 7970M
    • Mobile Radeon HD 8000-Series
    • Mobile Radeon Rx M2xx Series (except R9 M280X with VCE 2.0 and R9 M295X with VCE 3.0)
    • Mobile Radeon R5 M330 to R9 M390
    • FirePro cards with 1st Generation GCN (GCN1) (Except W2100, which is Oland XT)

VCE 2.0

Compared to the first version, VCE 2.0 adds H.264 YUV444 (I-Frames), B-frames for H.264 YUV420, and improvements to the DEM (Display Encode Mode), which results in a better encoding quality.

It can be found on:

  • Steamroller-based
    • Kaveri APUs (Ax-7xxx, e.g. A10-7850K)
    • Godavari APUs (Ax-7xxx, e.g. A10-7890K)
  • Jaguar-based
    • Kabini APUs (e.g. Athlon 5350, Sempron 2650)
    • Temash APUs (e.g. A6-1450, A4-1200)
  • Puma-based
    • Beema and Mullins
  • GPUs of the Sea Islands generation as well Bonaire or Hawaii GPUs (2nd Generation Graphics Core Next), such as
    • Radeon HD 7790, 8770
    • Radeon R7 260, 260X / R9 290, 290X, 295X2
    • Radeon R7 360 / R9 390, 390X
    • Mobile Radeon R9 M280X
    • Mobile Radeon R9 M385, M385X
    • Mobile Radeon R9 M470, M470X
    • FirePro cards with 2nd Generation GCN (GCN2)

VCE 3.0

Video Code Engine 3.0 (VCE 3.0) technology features a new high-quality video scaling and - since version 3.4 - High Efficiency Video Coding (HEVC/H.265).[10][11]

It, together with UVD 6.0, can be found on 3rd generation of Graphics Core Next (GCN3) with "Tonga", "Fiji", "Iceland", and "Carrizo" (VCE 3.1) based graphics controller hardware, which is now used AMD Radeon Rx 300 series (Pirate Islands GPU family) and VCE 3.4 by actual AMD Radeon Rx 400 series and AMD Radeon 500 series (both Polaris GPU family).

  • Tonga: Radeon R9 285, 380, 380X; Mobile Radeon R9 M390X, M395, M395X, M485X
  • Tonga XT: FirePro W7100, S7100X, S7150, S7150 X2
  • Fiji: Radeon R9 Fury, Fury X, Nano; Radeon Pro Duo (2016); FirePro S9300, W7170M ; Instinct MI8
  • Polaris: RX 460, 470, 480; RX 550, 560, 570, 580; Radeon Pro Duo (2017)

VCE 3.0 removes support for H.264 B-frames.[12]

VCE 4.0

The Video Code Engine 4.0 encoder and UVD 7.0 decoder are included in the Vega-based GPUs.[13][14]

VCE 4.1

AMD's Vega20 GPU, present in the Instinct Mi50, Instinct Mi60 and Radeon VII cards, include VCE 4.1 and two UVD 7.2 instances.[15][16]

Feature overview

APUs

The following table shows features of AMD's processors with 3D graphics, including APUs (see also: List of AMD processors with 3D graphics).

Platform High, standard and low power Low and ultra-low power
Codename Server Basic Toronto
Micro Kyoto
Desktop Performance Raphael Phoenix
Mainstream Llano Trinity Richland Kaveri Kaveri Refresh (Godavari) Carrizo Bristol Ridge Raven Ridge Picasso Renoir Cezanne
Entry
Basic Kabini Dalí
Mobile Performance Renoir Cezanne Rembrandt Dragon Range
Mainstream Llano Trinity Richland Kaveri Carrizo Bristol Ridge Raven Ridge Picasso Renoir
Lucienne
Cezanne
Barceló
Phoenix
Entry Dalí Mendocino
Basic Desna, Ontario, Zacate Kabini, Temash Beema, Mullins Carrizo-L Stoney Ridge Pollock
Embedded Trinity Bald Eagle Merlin Falcon,
Brown Falcon
Great Horned Owl Grey Hawk Ontario, Zacate Kabini Steppe Eagle, Crowned Eagle,
LX-Family
Prairie Falcon Banded Kestrel River Hawk
Released Aug 2011 Oct 2012 Jun 2013 Jan 2014 2015 Jun 2015 Jun 2016 Oct 2017 Jan 2019 Mar 2020 Jan 2021 Jan 2022 Sep 2022 Jan 2023 Jan 2011 May 2013 Apr 2014 May 2015 Feb 2016 Apr 2019 Jul 2020 Jun 2022 Nov 2022
CPU microarchitecture K10 Piledriver Steamroller Excavator "Excavator+"[17] Zen Zen+ Zen 2 Zen 3 Zen 3+ Zen 4 Bobcat Jaguar Puma Puma+[18] "Excavator+" Zen Zen+ "Zen 2+"
ISA x86-64 v1 x86-64 v2 x86-64 v3 x86-64 v4 x86-64 v1 x86-64 v2 x86-64 v3
Socket Desktop Performance AM5
Mainstream AM4
Entry FM1 FM2 FM2+ FM2+[a], AM4 AM4
Basic AM1 FP5
Other FS1 FS1+, FP2 FP3 FP4 FP5 FP6 FP7 FL1 FP7
FP7r2
FP8
? FT1 FT3 FT3b FP4 FP5 FT5 FP5 FT6
PCI Express version 2.0 3.0 4.0 5.0 4.0 2.0 3.0
CXL
Fab. (nm) GF 32SHP
(HKMG SOI)
GF 28SHP
(HKMG bulk)
GF 14LPP
(FinFET bulk)
GF 12LP
(FinFET bulk)
TSMC N7
(FinFET bulk)
TSMC N6
(FinFET bulk)
CCD: TSMC N5
(FinFET bulk)

cIOD: TSMC N6
(FinFET bulk)
TSMC 4nm
(FinFET bulk)
TSMC N40
(bulk)
TSMC N28
(HKMG bulk)
GF 28SHP
(HKMG bulk)
GF 14LPP
(FinFET bulk)
GF 12LP
(FinFET bulk)
TSMC N6
(FinFET bulk)
Die area (mm2) 228 246 245 245 250 210[19] 156 180 210 CCD: (2x) 70
cIOD: 122
178 75 (+ 28 FCH) 107 ? 125 149 ~100
Min TDP (W) 35 17 12 10 15 105 35 4.5 4 3.95 10 6 12 8
Max APU TDP (W) 100 95 65 45 170 54 18 25 6 54 15
Max stock APU base clock (GHz) 3 3.8 4.1 4.1 3.7 3.8 3.6 3.7 3.8 4.0 3.3 4.7 4.3 1.75 2.2 2 2.2 3.2 2.6 1.2 3.35 2.8
Max APUs per node[b] 1 1
Max core dies per CPU 1 2 1 1
Max CCX per core die 1 2 1 1
Max cores per CCX 4 8 2 4 2 4
Max CPU[c] cores per APU 4 8 16 8 2 4 2 4
Max threads per CPU core 1 2 1 2
Integer pipeline structure 3+3 2+2 4+2 4+2+1 1+3+3+1+2 1+1+1+1 2+2 4+2 4+2+1
i386, i486, i586, CMOV, NOPL, i686, PAE, NX bit, CMPXCHG16B, AMD-V, RVI, ABM, and 64-bit LAHF/SAHF Yes Yes
IOMMU[d] v2 v1 v2
BMI1, AES-NI, CLMUL, and F16C Yes Yes
MOVBE Yes
AVIC, BMI2, RDRAND, and MWAITX/MONITORX Yes
SME[e], TSME[e], ADX, SHA, RDSEED, SMAP, SMEP, XSAVEC, XSAVES, XRSTORS, CLFLUSHOPT, CLZERO, and PTE Coalescing Yes Yes
GMET, WBNOINVD, CLWB, QOS, PQE-BW, RDPID, RDPRU, and MCOMMIT Yes Yes
MPK, VAES Yes
SGX
FPUs per core 1 0.5 1 1 0.5 1
Pipes per FPU 2 2
FPU pipe width 128-bit 256-bit 80-bit 128-bit 256-bit
CPU instruction set SIMD level SSE4a[f] AVX AVX2 AVX-512 SSSE3 AVX AVX2
3DNow! 3DNow!+
PREFETCH/PREFETCHW Yes Yes
GFNI Yes
AMX
FMA4, LWP, TBM, and XOP Yes Yes
FMA3 Yes Yes
AMD XDNA Yes
L1 data cache per core (KiB) 64 16 32 32
L1 data cache associativity (ways) 2 4 8 8
L1 instruction caches per core 1 0.5 1 1 0.5 1
Max APU total L1 instruction cache (KiB) 256 128 192 256 512 256 64 128 96 128
L1 instruction cache associativity (ways) 2 3 4 8 2 3 4 8
L2 caches per core 1 0.5 1 1 0.5 1
Max APU total L2 cache (MiB) 4 2 4 16 1 2 1 2
L2 cache associativity (ways) 16 8 16 8
Max on--die L3 cache per CCX (MiB) 4 16 32 4
Max 3D V-Cache per CCD (MiB) 64
Max total in-CCD L3 cache per APU (MiB) 4 8 16 64 4
Max. total 3D V-Cache per APU (MiB) 64
Max. board L3 cache per APU (MiB)
Max total L3 cache per APU (MiB) 4 8 16 128 4
APU L3 cache associativity (ways) 16 16
L3 cache scheme Victim Victim
Max. L4 cache
Max stock DRAM support DDR3-1866 DDR3-2133 DDR3-2133, DDR4-2400 DDR4-2400 DDR4-2933 DDR4-3200, LPDDR4-4266 DDR5-4800, LPDDR5-6400 DDR5-5200 DDR5-5600, LPDDR5x-7500 DDR3L-1333 DDR3L-1600 DDR3L-1866 DDR3-1866, DDR4-2400 DDR4-2400 DDR4-1600 DDR4-3200 LPDDR5-5500
Max DRAM channels per APU 2 1 2 1 2
Max stock DRAM bandwidth (GB/s) per APU 29.866 34.132 38.400 46.932 68.256 102.400 83.200 120.000 10.666 12.800 14.933 19.200 38.400 12.800 51.200 88.000
GPU microarchitecture TeraScale 2 (VLIW5) TeraScale 3 (VLIW4) GCN 2nd gen GCN 3rd gen GCN 5th gen[20] RDNA 2 RDNA 3 TeraScale 2 (VLIW5) GCN 2nd gen GCN 3rd gen[20] GCN 5th gen RDNA 2
GPU instruction set TeraScale instruction set GCN instruction set RDNA instruction set TeraScale instruction set GCN instruction set RDNA instruction set
Max stock GPU base clock (MHz) 600 800 844 866 1108 1250 1400 2100 2400 400 538 600 ? 847 900 1200 600 1300 1900
Max stock GPU base GFLOPS[g] 480 614.4 648.1 886.7 1134.5 1760 1971.2 2150.4 3686.4 102.4 86 ? ? ? 345.6 460.8 230.4 1331.2 486.4
3D engine[h] Up to 400:20:8 Up to 384:24:6 Up to 512:32:8 Up to 704:44:16[21] Up to 512:32:8 768:48:8 128:8:4 80:8:4 128:8:4 Up to 192:12:8 Up to 192:12:4 192:12:4 Up to 512:?:? 128:?:?
IOMMUv1 IOMMUv2 IOMMUv1 ? IOMMUv2
Video decoder UVD 3.0 UVD 4.2 UVD 6.0 VCN 1.0[22] VCN 2.1[23] VCN 2.2[23] VCN 3.1 ? UVD 3.0 UVD 4.0 UVD 4.2 UVD 6.0 UVD 6.3 VCN 1.0 VCN 3.1
Video encoder VCE 1.0 VCE 2.0 VCE 3.1 VCE 2.0 VCE 3.1
AMD Fluid Motion No Yes No No Yes No
GPU power saving PowerPlay PowerTune PowerPlay PowerTune[24]
TrueAudio Yes[25] ? Yes
FreeSync 1
2
1
2
HDCP[i] ? 1.4 2.2 2.3 ? 1.4 2.2 2.3
PlayReady[i] 3.0 not yet 3.0 not yet
Supported displays[j] 2–3 2–4 3 3 (desktop)
4 (mobile, embedded)
4 2 3 4 4
/drm/radeon[k][27][28] Yes Yes
/drm/amdgpu[k][29] Yes[30] Yes[30]
  1. ^ For FM2+ Excavator models: A8-7680, A6-7480 & Athlon X4 845.
  2. ^ A PC would be one node.
  3. ^ An APU combines a CPU and a GPU. Both have cores.
  4. ^ Requires firmware support.
  5. ^ a b Requires firmware support.
  6. ^ No SSE4. No SSSE3.
  7. ^ Single-precision performance is calculated from the base (or boost) core clock speed based on a FMA operation.
  8. ^ Unified shaders : texture mapping units : render output units
  9. ^ a b To play protected video content, it also requires card, operating system, driver, and application support. A compatible HDCP display is also needed for this. HDCP is mandatory for the output of certain audio formats, placing additional constraints on the multimedia setup.
  10. ^ To feed more than two displays, the additional panels must have native DisplayPort support.[26] Alternatively active DisplayPort-to-DVI/HDMI/VGA adapters can be employed.
  11. ^ a b DRM (Direct Rendering Manager) is a component of the Linux kernel. Support in this table refers to the most current version.

GPUs

The following table shows features of AMD/ATI's GPUs (see also: List of AMD graphics processing units).

Name of GPU series Wonder Mach 3D Rage Rage Pro Rage 128 R100 R200 R300 R400 R500 R600 RV670 R700 Evergreen Northern
Islands
Southern
Islands
Sea
Islands
Volcanic
Islands
Arctic
Islands
/Polaris
Vega Navi 1x Navi 2x Navi 3x
Released 1986 1991 Apr
1996
Mar
1997
Aug
1998
Apr
2000
Aug
2001
Sep
2002
May
2004
Oct
2005
May
2007
Nov
2007
Jun
2008
Sep
2009
Oct
2010
Jan
2012
Sep
2013
Jun
2015
Jun 2016, Apr 2017, Aug 2019 Jun 2017, Feb 2019 Jul
2019
Nov
2020
Dec
2022
Marketing Name Wonder Mach 3D
Rage
Rage
Pro
Rage
128
Radeon
7000
Radeon
8000
Radeon
9000
Radeon
X700/X800
Radeon
X1000
Radeon
HD 2000
Radeon
HD 3000
Radeon
HD 4000
Radeon
HD 5000
Radeon
HD 6000
Radeon
HD 7000
Radeon
200
Radeon
300
Radeon
400/500/600
Radeon
RX Vega, Radeon VII
Radeon
RX 5000
Radeon
RX 6000
Radeon
RX 7000
AMD support Ended Current
Kind 2D 3D
Instruction set architecture Not publicly known TeraScale instruction set GCN instruction set RDNA instruction set
Microarchitecture TeraScale 1
(VLIW)
TeraScale 2
(VLIW5)
TeraScale 2
(VLIW5)

up to 68xx
TeraScale 3
(VLIW4)

in 69xx [31][32]
GCN 1st
gen
GCN 2nd
gen
GCN 3rd
gen
GCN 4th
gen
GCN 5th
gen
RDNA RDNA 2 RDNA 3
Type Fixed pipeline[a] Programmable pixel & vertex pipelines Unified shader model
Direct3D 5.0 6.0 7.0 8.1 9.0
11 (9_2)
9.0b
11 (9_2)
9.0c
11 (9_3)
10.0
11 (10_0)
10.1
11 (10_1)
11 (11_0) 11 (11_1)
12 (11_1)
11 (12_0)
12 (12_0)
11 (12_1)
12 (12_1)
11 (12_1)
12 (12_2)
Shader model 1.4 2.0+ 2.0b 3.0 4.0 4.1 5.0 5.1 5.1
6.5
6.7
OpenGL 1.1 1.2 1.3 2.1[b][33] 3.3 4.5 (on Linux: 4.5 (Mesa 3D 21.0))[34][35][36][c] 4.6 (on Linux: 4.6 (Mesa 3D 20.0))
Vulkan 1.0
(Win 7+ or Mesa 17+)
1.2 (Adrenalin 20.1.2, Linux Mesa 3D 20.0)
1.3 (GCN 4 and above (with Adrenalin 22.1.2, Mesa 22.0))
1.3
OpenCL Close to Metal 1.1 (no Mesa 3D support) 1.2+ (on Linux: 1.1+ (no Image support on clover, with by rustiCL) with Mesa 3D, 1.2+ on GCN 1.Gen) 2.0+ (Adrenalin driver on Win7+)
(on Linux ROCM, Linux Mesa 3D 1.2+ (no Image support in clover, but in rustiCL with Mesa 3D, 2.0+ and 3.0 with AMD drivers or AMD ROCm), 5th gen: 2.2 win 10+ and Linux RocM 5.0+
2.2+ and 3.0 windows 8.1+ and Linux ROCM 5.0+ (Mesa 3D rustiCL 1.2+ and 3.0 (2.1+ and 2.2+ wip))[37][38][39]
HSA / ROCm Yes ?
Video decoding ASIC Avivo/UVD UVD+ UVD 2 UVD 2.2 UVD 3 UVD 4 UVD 4.2 UVD 5.0 or 6.0 UVD 6.3 UVD 7 [13][d] VCN 2.0 [13][d] VCN 3.0 [40] VCN 4.0
Video encoding ASIC VCE 1.0 VCE 2.0 VCE 3.0 or 3.1 VCE 3.4 VCE 4.0 [13][d]
Fluid Motion [e] No Yes No ?
Power saving ? PowerPlay PowerTune PowerTune & ZeroCore Power ?
TrueAudio Via dedicated DSP Via shaders
FreeSync 1
2
HDCP[f] ? 1.4 2.2 2.3 [41]
PlayReady[f] 3.0 No 3.0
Supported displays[g] 1–2 2 2–6 ?
Max. resolution ? 2–6 ×
2560×1600
2–6 ×
4096×2160 @ 30 Hz
2–6 ×
5120×2880 @ 60 Hz
3 ×
7680×4320 @ 60 Hz [42]

7680×4320 @ 60 Hz PowerColor
7680x4320

@165 HZ

/drm/radeon[h] Yes
/drm/amdgpu[h] Experimental [43] Optional [44] Yes
  1. ^ The Radeon 100 Series has programmable pixel shaders, but do not fully comply with DirectX 8 or Pixel Shader 1.0. See article on R100's pixel shaders.
  2. ^ R300, R400 and R500 based cards do not fully comply with OpenGL 2+ as the hardware does not support all types of non-power of two (NPOT) textures.
  3. ^ OpenGL 4+ compliance requires supporting FP64 shaders and these are emulated on some TeraScale chips using 32-bit hardware.
  4. ^ a b c The UVD and VCE were replaced by the Video Core Next (VCN) ASIC in the Raven Ridge APU implementation of Vega.
  5. ^ Video processing for video frame rate interpolation technique. In Windows it works as a DirectShow filter in your player. In Linux, there is no support on the part of drivers and / or community.
  6. ^ a b To play protected video content, it also requires card, operating system, driver, and application support. A compatible HDCP display is also needed for this. HDCP is mandatory for the output of certain audio formats, placing additional constraints on the multimedia setup.
  7. ^ More displays may be supported with native DisplayPort connections, or splitting the maximum resolution between multiple monitors with active converters.
  8. ^ a b DRM (Direct Rendering Manager) is a component of the Linux kernel. AMDgpu is the Linux kernel module. Support in this table refers to the most current version.

Operating system support

The VCE SIP core needs to be supported by the device driver. The device driver provides one or multiple interfaces, e. g. OpenMAX IL. One of these interfaces is then used by end-user software, like GStreamer or HandBrake (HandBrake rejected VCE support in December 2016,[45] but added it in December 2018[46]), to access the VCE hardware and make use of it.

AMD's proprietary device driver AMD Catalyst is available for multiple operating systems and support for VCE was added to it[citation needed]. Additionally, a free device driver is available. This driver also supports the VCE hardware.

Linux

Support for the VCE ASIC is contained in the Linux kernel device driver amdgpu.

Windows

The software "MediaShow Espresso Video Transcoding" seems to utilize VCE and UVD to the fullest extent possible.[51]

XSplit Broadcaster supports VCE from version 1.3.[52]

Open Broadcaster Software (OBS Studio) supports VCE for recording and streaming. The original Open Broadcaster Software (OBS) requires a fork build in order to enable VCE.[53]

AMD Radeon Software supports VCE with built in game capture ("Radeon ReLive") and use AMD AMF/VCE on APU or Radeon Graphics card to reduce FPS drop when capturing game or video content.[54]

HandBrake added Video Coding Engine support in version 1.2.0 in December 2018.[46]

Successor

The VCE was succeeded by AMD Video Core Next in the Raven Ridge series of APUs released in October 2017. The VCN combines both encode (VCE) and decode (UVD).[55]

See also

Video hardware technologies

AMD

Others

References

  1. ^ a b "Introducing the Video Coding Engine (VCE) - AMD". developer.amd.com. Archived from the original on 4 June 2016. Retrieved 15 January 2022.
  2. ^ "Product brief". amd.com.
  3. ^ "Updates" (PDF). amd.com.
  4. ^ "White Paper AMD UnifiedVideoDecoder (UVD)" (PDF). 2012-06-15. Retrieved 2017-05-20.
  5. ^ "AnandTech Portal | AMD Radeon HD 7970 Review: 28nm And Graphics Core Next, Together As One". Anandtech.com. Retrieved 2014-03-27.
  6. ^ "AMD's Radeon HD 7970 graphics processor - The Tech Report - Page 5". The Tech Report. 3 January 2012. Retrieved 2014-03-27.
  7. ^ "AMD A-Series APU block diagram". 2011-06-30. Retrieved 2015-01-22.
  8. ^ "Video & Movies: The Video Codec Engine, UVD3, & Steady Video 2.0". AnandTech. December 22, 2011. Retrieved 2017-05-20.
  9. ^ "Radeon HD 8900 Specs". AMD. Retrieved 2016-07-18.
  10. ^ "Mailing Lists". lists.freedesktop.org. 4 June 2015. Retrieved 25 September 2023.
  11. ^ "VCEEnc". June 10, 2023 – via GitHub.
  12. ^ "Video Encode API: BFrames not supported on RX 4xx? · Issue #8 · GPUOpen-LibrariesAndSDKs/AMF". GitHub.
  13. ^ a b c d Killian, Zak (March 22, 2017). "AMD publishes patches for Vega support on Linux". Tech Report. Retrieved March 23, 2017.
  14. ^ Larabel, Michael (20 March 2017). "AMD Sends Out 100 Patches, Enabling Vega Support In AMDGPU DRM". Phoronix. Retrieved 25 August 2017.
  15. ^ Deucher, Alex (15 May 2018). "[PATCH 50/57] drm/amdgpu/vg20:Enable the 2nd instance IRQ for uvd 7.2". Retrieved 2019-01-13.
  16. ^ Deucher, Alex (15 May 2018). "[PATCH 42/57] drm/amd/include/vg20: adjust VCE_BASE to reuse vce 4.0 header files". Retrieved 2019-01-13.
  17. ^ "AMD Announces the 7th Generation APU: Excavator mk2 in Bristol Ridge and Stoney Ridge for Notebooks". 31 May 2016. Retrieved 3 January 2020.
  18. ^ "AMD Mobile "Carrizo" Family of APUs Designed to Deliver Significant Leap in Performance, Energy Efficiency in 2015" (Press release). 20 November 2014. Retrieved 16 February 2015.
  19. ^ "The Mobile CPU Comparison Guide Rev. 13.0 Page 5 : AMD Mobile CPU Full List". TechARP.com. Retrieved 13 December 2017.
  20. ^ a b "AMD VEGA10 and VEGA11 GPUs spotted in OpenCL driver". VideoCardz.com. Retrieved 6 June 2017.
  21. ^ Cutress, Ian (1 February 2018). "Zen Cores and Vega: Ryzen APUs for AM4 – AMD Tech Day at CES: 2018 Roadmap Revealed, with Ryzen APUs, Zen+ on 12nm, Vega on 7nm". Anandtech. Retrieved 7 February 2018.
  22. ^ Larabel, Michael (17 November 2017). "Radeon VCN Encode Support Lands in Mesa 17.4 Git". Phoronix. Retrieved 20 November 2017.
  23. ^ a b "AMD Ryzen 5000G 'Cezanne' APU Gets First High-Res Die Shots, 10.7 Billion Transistors In A 180mm2 Package". wccftech. Aug 12, 2021. Retrieved August 25, 2021.
  24. ^ Tony Chen; Jason Greaves, "AMD's Graphics Core Next (GCN) Architecture" (PDF), AMD, retrieved 13 August 2016
  25. ^ "A technical look at AMD's Kaveri architecture". Semi Accurate. Retrieved 6 July 2014.
  26. ^ "How do I connect three or More Monitors to an AMD Radeon™ HD 5000, HD 6000, and HD 7000 Series Graphics Card?". AMD. Retrieved 8 December 2014.
  27. ^ Airlie, David (26 November 2009). "DisplayPort supported by KMS driver mainlined into Linux kernel 2.6.33". Retrieved 16 January 2016.
  28. ^ "Radeon feature matrix". freedesktop.org. Retrieved 10 January 2016.
  29. ^ Deucher, Alexander (16 September 2015). "XDC2015: AMDGPU" (PDF). Retrieved 16 January 2016.
  30. ^ a b Michel Dänzer (17 November 2016). "[ANNOUNCE] xf86-video-amdgpu 1.2.0". lists.x.org.
  31. ^ "AMD Radeon HD 6900 (AMD Cayman) series graphics cards". HWlab. hw-lab.com. December 19, 2010. Archived from the original on August 23, 2022. Retrieved August 23, 2022. New VLIW4 architecture of stream processors allowed to save area of each SIMD by 10%, while performing the same compared to previous VLIW5 architecture
  32. ^ "GPU Specs Database". TechPowerUp. Retrieved August 23, 2022.
  33. ^ "NPOT Texture (OpenGL Wiki)". Khronos Group. Retrieved February 10, 2021.
  34. ^ "AMD Radeon Software Crimson Edition Beta". AMD. Retrieved 2018-04-20.
  35. ^ "Mesamatrix". mesamatrix.net. Retrieved 2018-04-22.
  36. ^ "RadeonFeature". X.Org Foundation. Retrieved 2018-04-20.
  37. ^ "AMD Radeon RX 6800 XT Specs". TechPowerUp. Retrieved January 1, 2021.
  38. ^ "AMD Launches The Radeon PRO W7500/W7600 RDNA3 GPUs". Phoronix. 3 August 2023. Retrieved 4 September 2023.
  39. ^ "AMD Radeon Pro 5600M Grafikkarte". TopCPU.net (in German). Retrieved 4 September 2023.
  40. ^ Larabel, Michael (September 15, 2020). "AMD Radeon Navi 2 / VCN 3.0 Supports AV1 Video Decoding". Phoronix. Retrieved January 1, 2021.
  41. ^ Edmonds, Rich (February 4, 2022). "ASUS Dual RX 6600 GPU review: Rock-solid 1080p gaming with impressive thermals". Windows Central. Retrieved November 1, 2022.
  42. ^ "Radeon's next-generation Vega architecture" (PDF). Radeon Technologies Group (AMD). Archived from the original (PDF) on September 6, 2018. Retrieved June 13, 2017.
  43. ^ Larabel, Michael (December 7, 2016). "The Best Features of the Linux 4.9 Kernel". Phoronix. Retrieved December 7, 2016.
  44. ^ "AMDGPU". Retrieved December 29, 2023.
  45. ^ "HandBrake rejected VCE pull request". GitHub. 2016-12-08. Retrieved 2017-08-15.
  46. ^ a b "HandBrake added VCE support in v1.2.0". 2018-12-22. Retrieved 2018-12-31.
  47. ^ König, Christian (4 February 2014). "initial VCE support". mesa-dev (Mailing list). Retrieved 28 November 2015.
  48. ^ König, Christian (24 October 2013). "OpenMAX state tracker". mesa-dev (Mailing list). Retrieved 28 November 2015.
  49. ^ "AMD Open-Sources VCE Video Encode Engine Code". Phoronix. 2014-02-04. Retrieved 2017-05-20.
  50. ^ "st/omx/enc: implement h264 level support". 2014-06-12. Retrieved 2017-05-20.
  51. ^ "MediaShow Espresso Video Transcoding Benchmark". 2014-01-14. Retrieved 2017-05-20.
  52. ^ "XSplit Broadcaster 1.3 maintenance update includes mainly performance enhancements and maintenance fixes including such noteworthy features such as support for AMD's VCE H.264 hardware encoder". Archived from the original on 2014-07-22.
  53. ^ "OBS branch with AMD VCE support". May 2, 2014. Retrieved 2017-05-20.
  54. ^ "Radeon Software Crimson ReLive Edition 16.12.1 Release Notes". Retrieved 2017-05-20.
  55. ^ Larabel, Michael (17 November 2017). "Radeon VCN Encode Support Lands In Mesa 17.4 Git". Phoronix. Retrieved 20 November 2017.
This page was last edited on 1 March 2024, at 16:49
Basis of this page is in Wikipedia. Text is available under the CC BY-SA 3.0 Unported License. Non-text media are available under their specified licenses. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc. WIKI 2 is an independent company and has no affiliation with Wikimedia Foundation.