So, I just tried it and it's what I see:

name@name-SVE1511W1ESI:~$ steam
Running Steam on ubuntu 18.04 64-bit
STEAM_RUNTIME is enabled automatically
Installing breakpad exception handler for appid(steam)/version(0)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

Does any 32 bit opengl application work like glxinfo from mesa-utils:i386?

I'm pretty much new into Linux, what should I do to verify it exactly?
The system is pretty much old but still usable, it's an i5 2450m with an AMD HD7000m serie.

So, this is the result:

name@name-SVE1511W1ESI:~$ glxinfo | grep Device
Device: llvmpipe (LLVM 6.0, 256 bits) (0xffffffff)

@Liger0 could you provide outputs for:

• cat /proc/cmdline
• dpkg -l | grep -E 'nvidia|fglrx|xorg-video'
• lsmod | grep -E 'radeon|fglrx' ?

1.txt
2.txt
3.txt
Here you go. :)

Hmm, so it's falling back to the old crappy open-source radeon driver, what was your card, ah it's listed above, a AMD HD7000m, which is indeed not supported on AMDGPU due to its age, and the open source RADEON driver never supported it because of the mobile interfaces, so you will have to use the old closed-source fglrx driver (which you do not currently have installed), but I'm not sure it is new enough to support that card either (plus fglrx just flat-out isn't supported on your kernel version, you'd need to downgrade, or backup first, well backup anyway).

Regardless, this does not appear to even remotely be a steam issue, you need to get full 3d acceleration setup and working on your system first, in whatever form that takes, maybe check http://wiki.cchtml.com/index.php?title=Main_Page or https://www.youtube.com/watch?v=EDTLvJ9QK8w if you don't mind downgrading your system first. That video card seems to be in that wiffly era before AMD open sourced their drivers but were also shutting down the old drivers (my video card, an HD5790, is also in that era, I have to keep my kernel (4.4.0) pretty old because of it, though I'll finally be updating in a month or so).

As I side note to the valve people, Steam really really should run fine on a modern MESA software pipeline (if a bit slow), if it doesn't then steam probably isn't following the OpenGL spec properly as the software pipeline requires it to be used very properly, though that still wouldn't cause libGL error: unable to load driver: swrast_dri.so to happen I would think...

The radeon driver is currently on-par performance-wise (if not faster) with what used to be fglrx and works fine on 7670M, 7660G and 7520G that I happen to own (and due to 7670M being the same chip as the 7650M, it should work just as well), the only part missing is that the former drivers supports only up to GL4.2 core (check https://www.x.org/wiki/RadeonFeature/ "N. Islands" column and annotations for details). Therefore everything stated afterward is simply misinformed and ill advice for a beginning user.

With that said, none of the provided outputs has obvious indications of breakage and I'm unable to reproduce on the same distribution, which would suggest some instance-specific problems.

One more thing, @Liger0 , could you provide outputs for these, please?:

• dpkg -l | grep mesa
• xrandr --listproviders | sed -n '/^Provider /{s/^Provider \([0-9]\+\): .*/\1/p}' | xargs -n1 -I'{}' -- /bin/sh -c 'DRI_PRIME={} glxinfo | grep Device'

I'm getting a stinky feeling the CPU's integrated graphics is getting in the way of your discrete GPU.

@zer0def thank you for the interest.

• https://github.com/ValveSoftware/steam-for-linux/files/2174218/1.grep.mesa.txt

name@name-SVE1511W1ESI:~$ xrandr --listproviders | sed -n '/^Provider /{s/^Provider \([0-9]\+\): .*/\1/p}' | xargs -n1 -I'{}' -- /bin/sh -c 'DRI_PRIME={} glxinfo | grep Device'
    Device: llvmpipe (LLVM 6.0, 256 bits) (0xffffffff)

I am fine to completely disable the AMD discrete GPU if needed, though I must say if I create an AMD configuration file like I read on the net, writing in
/usr/share/X11/xorg.conf.d/20-radeon.conf
Section "Device" Identifier "Radeon" Driver "radeon" Option "TripleBuffer" "true" EndSection
or any other code over triplebuffer (which I tried to solve tearing), the PC does not even start locking on a black screen.
The AMD GPU is causing only problems (it may be damaged in some way maybe), that's why maybe it would help completely disabling it.

Based on the last output, the system only sees one GPU and defaults to the software rendering pipeline, the former of which is unexpected, as it doesn't provide any additional information.

If the integrated GPU is in fact driving the display (and apparently there's a driver missing for it), it could mean the dGPU is already disabled (either in BIOS/UEFI or through ACPI using acpi-call). For the record, fglrx used to implicitly make the disabling ACPI call whenever the discrete GPU was switched off in options, but this isn't the case with radeon.

There's also the case of iGPU not being used at all, which would be even more puzzling.

At this point, there's too much guesswork, so I hope these pointers will help you (or whoever ends up following up to help) in resolving this issue.

(steam:7360): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita", /usr/share/themes/Mint-Y-Dark/gtk-2.0/main.rc:1085: error: unexpected identifier direction', expected character }' libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast crash_20180710113817_1.dmp[7375]: Uploading dump (out-of-process) /tmp/dumps/crash_20180710113817_1.dmp ./steam.sh: line 876: 7360 Segmentation fault (core dumped) $STEAM_DEBUGGER "$STEAMROOT/$STEAMEXEPATH" "$@"

Same sticky situation here with LinuxMint 19 and NVIDIA 390.67 drivers (GTX760).

That hardware is dead, so not an issue anymore.