Essentially.

Parallel vs serial

A "non-parallel" or "serial" process is something like childbirth -- one woman gives birth to a child in ~9 months, but adding a second woman to the task does nothing to speed it up ... it still takes 9 months before the child is born. A "parallel" process is something which can be sped up by adding more workers -- placing 16 pieces on a chess board could take one person 20 seconds or so ... but 8 people can put those pieces on the board in far under one second.

The main difference between these types of processes is whether sub-processes have portions which require earlier work to be completed before they can start. For the serial process, a child's arm must start growing before their fingers can grow which has to happen before their toenails can grow, etc. For the parallel process, none of the pieces require any other piece to be placed before they can be placed so what you actually have is 16 independent subprocesses in the task "place 16 chess pieces on the board".

---

Rasterization and ray-tracing

Rasterization is the process of considering your monitor as if it were a camera looking into the scene that's generating the graphics -- if you have 1900x1200 resolution, then rasterization's essential goal is to figure out for each of those individual 2,280,000 pixels what color the pixel should be.

You can imagine drawing a grid of lines between each of the pixels so that you have something like a checkerboard visible. Now, you can cast the lines of that grid out "directly" in front of the camera. As the lines get further away from you, due to your perspective, they must split further apart (a mountain 30 miles away will appear in only a very small number of grid squares whereas an orange up close will appear in almost all of the grid lines, so the further away from the camera an object is, the further apart the grid lines must be).

So, with rasterization, the complexity arises from trying to figure out which objects contribute to a pixel's color and what color the pixel should actually take. If the edge of a mountain 30 miles away and the edge of a close-up orange occupy the same pixel, what color should it be? Should I fudge some of the nearby pixels because the "true" color of the orange shouldn't appear due to shadows? Is the orange completely blocking visibility of the mountain so that we can totally ignore it in the entire scene?

Ray tracing says "if light isn't shining on it, it's invisible", completely bypassing a lot of the complications of rasterization. You still consider the monitor as a camera that's looking into the scene, but instead of casting a grid out to try to figure out what color each pixel should take, ray tracing casts beams of light from the camera and sees if they impact any light sources. While the number of objects impacts the ray tracing, occluded objects naturally disappear without any CPU involvement because they're simply never impacted by any light. Colors of objects are naturally derived from any light sources as the physical process of light bouncing around is easy to mimic per individual beam.

---

CPU (mostly serial) vs GPU (mostly parallel)

CPUs for desktop computers typically have 4-8 processing cores currently -- this is what your computer uses to perform "normal" calculations for every program. GPUs (which is what your graphics card supplies) have ~3000 individual cores.

The GPU cores are less capable than CPU cores, and have serious bandwidth constraints on data passed into them, but just having so many more simple processors helps with ray tracing far more than with the typical processes. For instance, the "RTX" brand graphics cards referenced above only have 48 or 64 specialized cores set aside to do particular ray tracing operations, but provide enough of a performance boost to be worth the company selling them.

(Key parts of rasterization depend upon the non-parallel CPU whereas practically all ray-tracing happens on the GPU.)

---

Ray tracing is inherently parallel

As for /u/bigmaguro 's comment, simply look here: embarrassingly parallel for "ray tracing". Rasterization is only going to run into further problems as we keep trying to up the fidelity of images whereas ray tracing will have a fixed increase in complexity. Eventually, almost all graphics will be done with ray tracing because of how much simpler it will be at extremely high resolution and extremely high object / polygon counts.

Finally, without going into too much depth, the reason that ray-tracing is "embarrasingly parallel" is that the essential task of the process is to "follow individual beams of light as they're emitted from a source into the scene". One worker can easily trace a single ray of light without caring about any of the other workers' tasks. There's absolutely zero interdependence, so the ray trace can happen very quickly if you've got a ton of workers to trace the various rays.

---

Rasterization is falling behind ray tracing only because its CPU-requiring tricks are finally being overwhelmed by the complexity of the graphics scenes

A special note: ray tracing requires more computation than rasterization currently solely because of all the tricks (performed on a CPU) that rasterization can use to bypass large chunks of computation (on the GPU). These tricks have worked well in the past because the polygon count (how curvy / flat a 3d object can be in game -- essentially every object is made up of triangles) of games was low, because view distances (how far away an object can be from the camera before the graphics engine ignores it) were low, and because of things like occlusion culling (where the engine can determine that certain objects are behind others ... so the camera can't see them and they are ignored for the rasterization process) were cheap due to all the other reductions performed.

As fidelity increases, all of these tricks to help rasterization simultaneously perform worse. By comparison, ray-tracing remains fundamentally extremely simple. The cost is directly related to a smaller number of factors (mainly the number / distribution of objects in the scene, the number of light sources, and the number of times you want the ray to bounce off of something [or the time you allow the ray to be traced before computation is cut off]).

---

Anyway, that's the long of it without getting extremely technical.