Some prehistory for this: recently I finally got a new video card, based on AMD RX 560 specifically to test Plasma on Wayland, and was very disappointed by the fact that kwin_wayland falls back to QPainter compositing.
On my 4k screen this compositing type can be very laggy.
I use amdgpu opensource driver and mesa-18 from git, also xf86-video-amdgpu-18.0.1.

Original error looked like this, eglCreatePlatformWindowSurfaceEXT() failed:

Then I noticed, that if I first start weston, and from weston kwin_wayland --windowed, I can even run full plasma session in that kwin_wayland window running smoothly with OpenGL compositing. So it became clear to me that drm backend was the problem. According to EGL_MESA_platform_gbm spec:

... call eglCreatePlatformWindowSurfaceEXT ...
If <native_window> was created without the GBM_BO_USE_RENDERING flag, or if
the color format of <native_window> differs from the EGL_NATIVE_VISUAL_ID
of <config>, then the function fails and generates EGL_BAD_MATCH.

I supposed that color format can be a problem, so I wrote a small test program to enumerate configs and formats ( github ) that outputs formats FOURCC and number of bits per color channel; its output is:

num egl configs = 10
  0-th GBM format: AR30;  sizes(RGBA) = 10,10,10,2,
  1-th GBM format: AR24;  sizes(RGBA) = 8,8,8,8,
  2-th GBM format: AR30;  sizes(RGBA) = 10,10,10,2,
  3-th GBM format: AR24;  sizes(RGBA) = 8,8,8,8,
  4-th GBM format: AR30;  sizes(RGBA) = 10,10,10,2,
  5-th GBM format: AR24;  sizes(RGBA) = 8,8,8,8,
  6-th GBM format: AR30;  sizes(RGBA) = 10,10,10,2,
  7-th GBM format: AR24;  sizes(RGBA) = 8,8,8,8,
  8-th GBM format: AR30;  sizes(RGBA) = 10,10,10,2,
  9-th GBM format: AR24;  sizes(RGBA) = 8,8,8,8,

Wow, some formats have 10 bits per red, green, blue, and a first one is the one with AR30 format.
Then I tried to patch kwin to be more clever when choosing config, and... it worked. I did that 2 days ago, and since that time I'm running plasma wayland session with hardware accelerated OpenGL compositing with no problems.
I'm currently submitting this diff from this configuration:

At least it fixed the problem for me. Output from kwin_wayland when starting plasma session as usual (startplasmacompositor) is: https://paste.kde.org/p88rlpvso
I used following env vars to get more debug output: EGL_LOG_LEVEL=debug QT_LOGGING_RULES="kwin*.debug=true"
As you can see, more EGL configs match kwin's demand here (80), and first one which is not AR30 - XR24 - matched and is chosen.

...
kwin_wayland_drm: 31 th config GBM format: AR30 ; color sizes (RGBA order): 10 10 10 2
kwin_wayland_drm: 32 th config GBM format: XR24 ; color sizes (RGBA order): 8 8 8 0

Hopefully this doesn't break on intel, If someone has intel hardware, please test :)

And now I'm reading news about mesa-18 new 10-bit color feature and realizing that maybe mesa-18 was my initial problem :)

I looked into Qt sources (QtWayland specifically), and found out that Qt uses similar approach - it loops over received configs and chooses the one that matches user's requested bit depths, if they were specified.
bool QEglConfigChooser::filterConfig(EGLConfig config) const
which is used from QWaylandGLContext class during context creation.

The whole EGLConfig selection part is great.

Is https://bugs.kde.org/show_bug.cgi?id=392716 related or even fixed with this commit?

In D11758#240148, @cfeck wrote:

Is https://bugs.kde.org/show_bug.cgi?id=392716 related or even fixed with this commit?

I didn't know about this bug.
It definitely looks related, though I don't have Intel hardware to test. And in my case I've seen problems only with kwin_wayland, x11 session worked fine...

Could you please backport to Plasma/5.12 branch?

In D11758#240679, @graesslin wrote:

Could you please backport to Plasma/5.12 branch?

Done 0ccecbc4275783e217d3c1ab1d3acd6988368757, it actually applied to Plasma/5.12 branch without modifications.