linuxgaming.de

Emil Velikov <emil.l.velikov@gmail.com> hat geschrieben:Hi all,

Here is the current tentative 11.3.0/12.0.0 release schedule.

May 20th 2016 - Feature freeze/Release candidate 1
May 27th 2016 - Release candidate 2
June 03rd 2016 - Release candidate 3
June 10th 2016 - Release candidate 4/final release

With the above in mind we have three weeks to get new features.

Do we have some serious work that we want to squeeze in and the time
is not enough. Does the proposed dates align with distributions
needs/expectations ?

Kindly let me know.

Thanks
Emil

Bas Nieuwenhuizen | 10 May 12:52 2016 hat geschrieben:This patchset implements offchip tessellation after which we can finally process
more than one patch per wave without decreasing tessmark scores.

For tessmark this improves performance by ~20% for the x32 case and ~80% for the
x64 case. x8 and x16 have roughly the same performance as before. Unigine heaven
gets 43 fps compared to 28 before (roughly +50%). Amdgpu-pro gets 44 fps for
heaven. For Shadow of Mordor the performance changes from 28 fps to 40 fps
(roughly +40%)

Marek Olšák <marek.olsak@amd.com> hat geschrieben:This implements:

• Linear-to-linear partial copies. (unaligned)
• Tiled-to-linear and linear-to-tiled partial copies. (unaligned except 1-2 Bpp)
• Tiled-to-tiled partial copies aligned to 8x8.

v2: Extend the SDMA L2T VM fault workaround to T2L.

• Same algorithm, just applied to T2L. (and using a 0-based address and surface.bo_size instead of buf->size)

Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

Marek Olšák <marek.olsak@amd.com> hat geschrieben:Hi,

This patch series completely rewrites texture copying with SDMA for CIK & VI. It only uses the "partial" copy packets, which makes it a lot simpler (one packet per layered/3D copy). Most of the complexity is in handling hw limitations, but luckily the SDMA path can be used in the majority of cases.

On top of that, the DMA IB support is improved thanks to extensive testing and benchmarking.

This is only enabled on VI for now. It can be enabled on CIK after enough testing is done.

There is one more hardware limitation that can cause VM faults with T2L copies and needs a workaround. The exact workaround is still under discussion, but I think this is good enough for review already.

On Tonga, it beats the 3D engine in texture upload performance by 0-80%. On APUs, the performance is mixed or slightly worse. The reason may be that the 3D engine uses less bandwidth thanks to DCC.

The fact that SDMA can't do DCC compression can be detrimental to texturing performance on VI. The impact hasn't been measured yet.

Texture uploads still use 2 copies (user memory -> linear, linear -> tiled). Merging those 2 copies into 1 is not done in this series.

Please review and opinions on the DCC issue are welcome,

Marek

LinuxDonald hat geschrieben:Jetzt soll ja vielleicht das Mesa Release verschoben werden um mesa 12.0 releasen zu können mit OpenGL 4.5

https://lists.freedesktop.org/archives/ ... rce=anzwix

Marek Olšák <maraeo@gmail.com> hat geschrieben:If we delay the release now, the release after that should be sooner,
so that it's aligned with fall distribution releases.

Nicolai Hähnle <nhaehnle@gmail.com> hat geschrieben:Hi,

this series makes the existing PBO texture upload code symmetric, adding a
download path that uses shader images a no-attachment framebuffers. This
should help performance by reducing stalls in several games, including
GRID: Autosport (verified with an apitrace), Metro 2033 Redux, and likely
others.

It should be possible to extend the framework to glGetTexImage without much
effort, but I wanted to get out what I have so far. Tested with Piglit on
radeonsi, including some more extensive local tests that I have yet to clean
up.

Please review!

Thanks,
Nicolai

ChemicalBrother hat geschrieben:Ohne Humble, Valve, Feral, etc. hätten wir gar nicht die Spiele, mit denen man überhaupt erst sieht, wo Verbesserungen nötig sind. Die open-source-Treiber gehen jetzt erst richtig ab!

Bin mal gespannt, wie sehr sich das auf GRID und Co wirklich auswirkt.

crt0mega hat geschrieben:Ach btw.. mich wundert es schon ewig, dass Intels Treiber nicht über Gallium3D implementiert wurde. Es gibt wohl nur einen experimentellen (ILO), der das nutzt. Woran liegt das eigentlich?

ChemicalBrother hat geschrieben:Das müsste man mal Intel-Devs fragen, wenn man einen kennt... Vielleicht wollen sie nicht Gallium3D nutzen?