While Intel launches its own discrete GPU, please, let me know something about GPU programming.
As far as i know, vendors (such as nVidia or AMD) do not publish specifications for the GPUs.
I'm not sure if there are mnemonics for the GPU instructions.
Are there any attempts or any ready solutions on assemblers for GPUs?
Can the application functions work without CPU at all?
For example, i need to draw a small fractal (e.g. Brownian tree) with 1 millon points.
What do i do now?
1) compute the point coords and colors using FMA,
2) send the results to the bus,
3) store the results in RAM,
4) send the data to the bus,
5) load the data to the proper XMM registers,
6) call certain OpenGL, Vulkan, DirectX functions.
Isn't it easier to compute everything in GPU without CPU, without RAM, and without the entire PC system?

Some GPUs do have published instruction sets. Some don't. Check before you buy.

Your OS should provide an API to talk to the GPU. Check with your OS as to what libraries and APIs it has. Things like CUDA and OpenCL etc. are popular with lots of examples on how to use them. And the high level interface libraries like OpenGL and DirectX will use those lower level APIs.

Plus, every GPU is different in what it can do, and how it works, so it is not easy to talk in general terms except when using the APIs. If you want to go in at a lower level then you necessarily must look to each GPUs specs.

Now i see it, thanks!
The GPU branch grows intensively and extensively so there is no common industrial standard for all GPU architectures. GPU is not a general-purpose unit like CPU.

Contemporary Intel, AMD, and Apple CPUs contain specialized media cores.
Here's an Intel documentation, for example.
https://software.intel.com/content/www/us/en/develop/articles/introduction-to-gen-assembly.html

Are there any assemblers or any extensions for fasm working with GPU (media core) registers or instructions?
If there are no such tools then how difficult is it to create such one?

LLVM has GPU backends for AMD, NVidia, ...
https://llvm.org/docs/AMDGPUUsage.html
https://llvm.org/docs/NVPTXUsage.html

These backends are largely provided/used by the manufacturers.

AMD seems to be more open from an assembly perspective, imho:
https://rocmdocs.amd.com/en/latest/GCN_ISA_Manuals/GCN-ISA-Manuals.html

Whereas NVidia would like programmers to use their high-level APIs.

Large collection of GPU docs:
https://github.com/olvaffe/gpu-docs

Oh, thanks! That's a real treasure!

Yet another useful link: https://docs.nvidia.com/cuda/

RISC-V started to work on a GPU ISA.

Renesas (THE embedded company) started to provide a RISC-V SOC package pin-to-pin compatible with some of its ARM offering.
On it, there is a GPU. That said I dunno if it uses the RISC-V GPU ISA (I doubt it since it is a WIP).

I've found the sweet spot to be with SPIR-V and Vulkan.

https://www.khronos.org/spir/
https://www.vulkan.org/

GPUs take dispatches of work, which you will want to send in overlapping combinations to keep the GPU 'fed.' Otherwise, you will get unnecessary stalls, GPUs can handle more work than just one kernel (executable) at a time.

There ARE capabilities with newer SPIR-V specifications to support device-side-enqueue, meaning the CPU is not needed to start a dispatch, the GPU can instead. One day it can probably run completely independent of the CPU, resizing memory buffers, binding those to slots, but the CPU does that stuff now for the most part.

If you want to expand your Brownian motion simulation to bigger datasets, you can also coordinate the computation between multiple GPUs, again using the CPU.

SPIR-V supports operations common to different GPUs while still being in an assembly-like or binary intermediary format ingestible by the GPU. Vulkan supports this format only and provides the dispatching and related orchestration commands.

I just did a project in the Projects and Ideas section here using both, will put up some samples soon. I've constructed some SPIR-V in binary form before too, but don't have an extensive assembler for it yet using fasmg. Soon.