RadeonSI Gallium3D Now Exposes GLSL 4.50

[Mystro256]

I would say the important bits to finish would be the on disk shader cache, GL_ARB_bindless_texture and the parallelization work. Of course random performance patches are always great.

[Gusar]

Geode only counts as i586, what distro/distros are you running that still support it? I thought most of them called their 32-bit x86 i386 but actually only supported down to i686 now.

Geode is missing one instruction to qualify for i686. While that used to be a problem (required specifically compiled binutils and glibc), it's not anymore for quite some time now, so any i686 distro that's not ancient will work.

[haagch]

My vote for the next thing is on making csgo playable without huge stutters and fps drops.

[smitty3268]

compatibility profiles to implement (I hope to be able to play Dying Light with Mesa one day),

I don't think compat profiles are ever going to happen. It's not just a matter of finding time, some devs are actively opposed to supporting them.

A better path forward would be to create a game-specific profile for Dying Light that overrides whatever it needs to do in order to get it playing.

[treba]

I would say the important bits to finish would be the on disk shader cache, GL_ARB_bindless_texture and the parallelization work. Of course random performance patches are always great.

This.

As always, the next mesa version will finally make everything great
I for one am really looking forward for the shader caches. It will effectively have the biggest impact on my gaming experience I think.

[geearf]

I would say the important bits to finish would be the on disk shader cache, GL_ARB_bindless_texture and the parallelization work. Of course random performance patches are always great.

I view the on disk cache as far less important, as it's just about loading time.
I'd rather have faster shader compilation or other performance improvements in game.

[Adarion]

Nice work! Backport would of course be nicer than waiting a quarter of a year, but then, if this needs any maturing I'll be fine with it. And yes, shader caches and all sorts of stuff might turn out nicely.

semi-OT Geode (LX)
By the way: Geode KMS would be nice! These lovely little machines are still good for a couple of purposes.
And: To my knowledge the Geode LX is basically i686 compatible. Code compiled with -Os -march=i486 is said to run more performant, though. (Geode GX (from various vendors) might be different. Geode NX/2001 is more an Athlon CPU and fits in the same socket A.) It was the VIA Cyrix III (Cyrix based) and iirc. most of the VIA C3 (Centaur based) ones that are not fully i686 but rather i586 (iirc. cmov missing).
Luckily I do run Gentoo anyway, so I don't have the worries if my distribution will run on my machines, even if they don't have PAE or cmov flags advertised. (However, I do understand that precompiled distributions struggle with backwards compatibility on one hand and being peformant and supporting modern hardware on the other.)

Taken from a Geode LX 800 specimen minutes ago

cat /proc/cpuinfo

 processor : 0
 vendor_id : AuthenticAMD
 cpu family : 5
 model : 10
 model name : Geode(TM) Integrated Processor by AMD PCS
 stepping : 2
 microcode : 0x8b
 cpu MHz : 498.045
 cache size : 128 KB
 fdiv_bug : no
 f00f_bug : no
 coma_bug : no
 fpu : yes
 fpu_exception : yes
 cpuid level : 1
 wp : yes
 flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow eagerfpu 3dnowprefetch vmmcall
 bugs : sysret_ss_attrs
 bogomips : 996.09
 clflush size : 32
 cache_alignment : 32
 address sizes : 32 bits physical, 32 bits virtual
 power management:

[bridgman]

IIRC someone (Marek maybe ?) mentioned that using the new memory allocator cut compile time down by maybe 25% on the new Deus Ex.

[leio]

semi-OT Geode (LX)
By the way: Geode KMS would be nice! These lovely little machines are still good for a couple of purposes.
And: To my knowledge the Geode LX is basically i686 compatible. Code compiled with -Os -march=i486 is said to run more performant, though. (Geode GX (from various vendors) might be different. Geode NX/2001 is more an Athlon CPU and fits in the same socket A.) It was the VIA Cyrix III (Cyrix based) and iirc. most of the VIA C3 (Centaur based) ones that are not fully i686 but rather i586 (iirc. cmov missing).
Luckily I do run Gentoo anyway, so I don't have the worries if my distribution will run on my machines, even if they don't have PAE or cmov flags advertised. (However, I do understand that precompiled distributions struggle with backwards compatibility on one hand and being peformant and supporting modern hardware on the other.)

Yeah, LX is a i686. The missing instruction (NOPL) isn't exactly a standard i686. Intel didn't document this instruction as part of i686, but all it's CPU happened to have it. So Geode didn't implement this per doc, presumably. Back then this saw most action at https://bugzilla.redhat.com/show_bug.cgi?id=579838 - basically glibc when built with -mtune=i686 passed -march=i686 to gas, and that considered NOPL to be available then (as opposed to tuning to i686 and not using i686 specific instructions). Comment 46 has a nice list of what supports what wrt VIA, Geode, Cyrix, etc. NOPL is like NOP, just more bytecodes.

That said, CMOV seems rather expensive on Geode, so in my experience it's better to avoid these instructions and optimize for i586 instead (or i486 is also better than i686 iirc). I've suggested i586 for CHOST mostly because glibc picks what routines it uses from there (well, back then at least), and it using all the strlen, memcpy and so on optimized routines with CMOV stuff with i686 CHOST is just much slower than those it has for i586. AMD (or maybe OLPC) once upon a time also wrote dedicated geode glibc optimizations, but these never reached upstream. Other than the CHOST for glibc benefits, -march=geode should do good, regardless of CHOST then; I think it knows CMOV is expensive and knows to mostly avoid them then. -mtune mostly instructs for which architectures instruction costs to optimize for; glibc has cost tables for each of them and then (put very simplified) decides how to optimize to reach lowest cost. -march implies -mtune on x86 (arm has its -mcpu fun too and things work a bit different).

AMD actively contributed to xf86-video-geode (EXA providing DDX driver) back in 2010 with two engineers from China offices. I suspect OLPC had something to do with that. I helped those AMD guys with the X11 stuff and git and so on.
Nowadays there is no AMD help there, and I really can not blame them.
I also don't have any professional or personal need for these anymore, so it's just on life support right now, more or less.
I have toyed with the idea of doing KMS for it, but it's only an idea and likely to stay that way from my end without some sort of motivation appearing

Back in 2010 KoH also wrote a rudimentary KMS kernel driver - http://karlchenofhell.org/kram.php?part=lx
I believe it was just getting some basic picture at the time; no work on Xorg DDX to work together with it or anything (but nowadays we have modesetting driver). The git repo was on gitourious, so it's kind of dead, but I believe it was also available from somewhere else too, and I might have a clone on some disk (and q-funk has it for sure - http://q-funk.blogspot.com/2015/10/x...l-dernier.html). However I doubt that code is too useful in year 2016 anymore, though I'm not familiar how KMS has evolved. I just suspect that at least we could leverage all the new KMS helper stuff to simplify the kernel code when we only have one output, etc.
I do not agree that KMS + modesetting will be acceptable though, as it really needs the EXA accelerations to be anywhere near fast. There's no 3D silicon, so there will be no glamor to get acceptable 2D performance with modesetting. But kernel level KMS would be a step in the right direction for it.

For more OT chat on this if anyone is interested, we still have #geode IRC channel around on FreeNode, where I also idle around.