Mesa 17.0-RC2 Released, Final Coming Next Month

[phoronix]

Phoronix: Mesa 17.0-RC2 Released, Final Coming Next Month

The second release candidate is now available for the upcoming Mesa 17.0...

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-17.0-RC2-Released

[oooverclocker]

I'm extremely happy! The current version on my system from the PPA, Mesa 17.1.0-devel - padoka PPA, seems to have fixed nearly all driver dependent issues and my RX 480 even produces >31 FPS AVG with 1440p and everything maxed out except Motion Blur and Sharpen in Deus Ex: Mankind Divided!


MadMax also runs smoothly now with ~50 FPS. All games on my steam list that most likely had driver issues seem to work now. I really love what they did, also thanks to Valve devs! When minor details have been fixed and the shader cache is implemented there is a real open source gaming platform and I'm extremely curious how the new version will perform towards the proprietary drivers

RADV is also improving more and more, but there are of course still enough features to add.

[M@GOid]

Well, looks like 2017 will be the year were you get full support for your GPU (well, in most cases), out of the box in a new distro install.

Kudos to all that made that possible.

[BangoMopar]

Well, looks like 2017 will be the year were you get full support for your GPU (well, in most cases), out of the box in a new distro install.

Kudos to all that made that possible.

Well said and, yes, that's what we love in Linux-land. And also gaming
(Who would have thought you could put those two things together in a coherent sentence?

[Azrael5]

I report the problems detected by chrome gpu page concerning MESA in some ways:
Problems Detected

• Accelerated video decode is unavailable on Linux: 137247
  Disabled Features: accelerated_video_decode
• Clear uniforms before first program use on all platforms: 124764, 349137
  Applied Workarounds: clear_uniforms_before_first_program_use
• Mesa drivers in Linux handle varyings without static use incorrectly: 333885
  Applied Workarounds: count_all_in_varyings_packing
• Linux AMD drivers incorrectly return initial value of 1 for TEXTURE_MAX_ANISOTROPY: 348237
  Applied Workarounds: init_texture_max_anisotropy
• Always rewrite vec/mat constructors to be consistent: 398694
  Applied Workarounds: scalarize_vec_and_mat_constructor_args
• Linux AMD drivers handle struct scopes incorrectly: 403957
  Applied Workarounds: regenerate_struct_names
• Linux ATI drivers crash on binding incomplete cube map texture to FBO: 518889
  Applied Workarounds: force_cube_map_positive_x_allocation
• Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
  Applied Workarounds: disable_framebuffer_cmaa
• Disable partial swaps on Mesa drivers (detected with GL_VERSION): 339493
  Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
• Decode and encode before generateMipmap for srgb format textures on os except macosx: 634519
  Applied Workarounds: decode_encode_srgb_for_generatemipmap
• adjust src/dst region if blitting pixels outside read framebuffer on Linux AMD: 664740
  Applied Workarounds: adjust_src_dst_region_for_blitframebuffer
• AMD drivers in Linux require invariant qualifier to match between vertex and fragment shaders: 659326, 639760
  Applied Workarounds: remove_invariant_and_centroid_for_essl3, dont_remove_invariant_for_fragment_input
• Mesa driver GL 3.3 requires invariant and centroid to match between shaders: 639760, 641129
  Applied Workarounds: remove_invariant_and_centroid_for_essl3
• Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
• Decode and Encode before generateMipmap for srgb format textures on Linux AMD: 634519
  Applied Workarounds: decode_encode_srgb_for_generatemipmap
• Accelerated rasterization has been disabled, either via blacklist, about:flags or the command line.
  Disabled Features: rasterization
• Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
  Disabled Features: native_gpu_memory_buffers
  
  Is it possible to solve them?

[mitch074]

The recent versions of Mesa do indeed bring up performance and support : Deus Ex: MD is arguably one (if not the) most graphics intensive game out currently, and it can actually render (I didn't say "run") on an Haswell IGP while rendering quality on radeonsi is perfect. I have a 8GB RX480 and it can handle the game in Ultra @1440p... In some maps, including the benchmark.

So yes, performance also got up, however in DE:MD, Pragues is pretty much unplayable even with details and textures reduced to the max: frame rate goes progressively lower and lower, until the game pretty much freezes then the frame rate goes way up for a few moments - and then starts dipping again, even when there's nothing particularly hard to render (looking at a wall). Other maps will render 25-50 fps on the very same settings.

It doesn't seem to be a CPU problem (I monitored my OC'ed i5 during these problems) nor a VRAM problem (Ultra textures use all 8GB of VRAM with an occasional dip higher, reducing to Very High stays at 6GB of VRAM), so there must be something, somewhere that causes some overallocation in a buffer or whatever that causes to game to crawl to a stop if too many resources are handled at once. I have 16 GB of RAM an a SSD.