R9 Nano: Chrome HW Rasterization Probleme, kein GPU gestütztes VP9 decoding

duftle

Cadet
Mitglied seit
09.01.2008
Beiträge
46
Renomée
2
Hi,

ich bin derzeitig unter Windows 10 64bit (Version 10.0.15063 Build 15063) mit einer R9 Nano (Crimson 17.5.1) unterwegs.
Seit den letzten 4-5 Treiberversionen hab ich einige Probleme mit Chrome und wollte mal euch fragen, ob ähnliches unter Chrome(58.0.3029.110 (64-bit)) ihr beobachtne könnt.

Generell beobachte ich folgendes:

1)
Wenn die GPU-Rasterung bei Chrome aktiv ist (chrome://flags), was bei der Standardeinstellung der Fall ist, ruckelt bei mir die Videoausgabe auf Youtube extrem, wenn diese Endcards kommen und man mit einem Maus drüber fährt. Es kommt dann diese "dunkelwerden"-Animation und in dieser Situation ruckeln die Videos dann meistens.
Oft beobachte ich auch, das wähgrend einer normalen Abspielung Frames gedropped werden. Sprich es kommt ab und zu zu kleinen Ruckeln, jedoch sind diese nicht so einfach reproduzierbar wie das Youtube Endcard Problem.
Abhilfe schaffe ich, in dem ich über chrome://flags die GPU-Rasterung explizit deaktiviere, jedoch geht damit die Hardwarebeschleunigung fürs Rendern der Webseiten flöten.

2)
Youtube spielt standardmäßig alle Videos in VP9 aus. Man kann das sehr gut über chrome://media-internals/ nachprüfen ob diese dann auch GPU gestützt dekodiert wird. Und das scheint nicht der Fall zu sein. Mann kan sich über einen Registry-Eintrag behelfen, aber das führt dazu, das Videos manchmal ewig zum starten brauchen. Es sieht so aus, als wäre die VP9 Decoding Untersützung unter Chrome kaputt. Es gibt dazu einige Forenbeiträge im Netz, aber bis heute keine Lösung von AMD oder Google:
https://community.amd.com/thread/208915
https://www.reddit.com/r/Amd/comments/5jf8zq/radeon_software_crimson_relive_edition_16122/dbfxppi/

Wie sieht das bei euch aus? Hab langsam das Gefühl das bei Chrome sich einiges in die falsche Richtung entwickelt. Edge wirkt im Vergleich weit aus schneller...
 
Du könntest zum Vergleich mal andere Chromium-basierte Browser testen, z.B. Vivaldi (Standalone ohne Installation möglich), Brave (noch Alpha), Epic alias Epic Privacy, Torch, Chromium selbst, UnGoogled Chromium, Opera oder Opera Neon (Konzeptbrowser).

Das WebKit-Modul von Lunascape dürfte auch Chromium als Basis verwenden.


Browser mit anderer Basis, die du ebenfalls probieren könntest – um dich nicht von Google, Microsoft oder der siechenden Mozilla-Organisation knechten zu lassen –, sind u.a. Pale Moon (x64: mein Lieblings- und am stärksten empfohlener Browser)*, Lunascape insgesamt, Cyberfox*, Otter (spiritueller Nachfolger von Opera 12) und Firefox 52 ESR*.

Seamonkey* und K-Meleon* oder K-Meleon Pro sind zwar Optionen, fürs Gegentesten sowieso, doch in den nächsten Monaten werden diese Projekte wohl ein Ende finden. Sie lieb zu gewinnen wäre also wahrscheinlich sehr kurz gedacht.


* – auf jeden Fall portable Version (keine Installation notwendig) verfügbar
 
Also unter dem aktuellem Iron mit der Rx480 geht die VP9 Hardwarewiedergabe:

Code:
Player Properties  Copy to clipboard

Property	Value
audio_buffering_state	BUFFERING_HAVE_ENOUGH
audio_codec_name	opus
audio_dds	false
audio_decoder	FFmpegAudioDecoder
duration	988.941
event	PLAY
found_audio_stream	true
found_video_stream	true
height	1440
pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
pipeline_state	kPlaying
player_id	35
render_id	9
url	blob:https://www.youtube.com/a2abf60c-d2d9-4029-b8f4-372f5cacad36
video_buffering_state	BUFFERING_HAVE_ENOUGH
video_codec_name	vp9
video_dds	false
video_decoder	VpxVideoDecoder
width	2560
Log 
property filter

Timestamp	Property	Value
00:00:00 00	pipeline_state	kCreated
00:00:00 00	event	WEBMEDIAPLAYER_CREATED
00:00:00 01	url	blob:https://www.youtube.com/a2abf60c-d2d9-4029-b8f4-372f5cacad36
00:00:00 35	pipeline_state	kStarting
00:00:00 227	found_video_stream	true
00:00:00 227	video_codec_name	vp9
00:00:00 228	found_audio_stream	true
00:00:00 228	audio_codec_name	opus
00:00:00 270	audio_dds	false
00:00:00 270	audio_decoder	FFmpegAudioDecoder
00:00:00 844	video_dds	false
00:00:00 844	video_decoder	VpxVideoDecoder
00:00:00 875	pipeline_state	kPlaying
00:00:00 940	audio_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:00 186	duration	988.941
00:00:01 176	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01 351	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:01 351	event	PLAY
00:00:02 190	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:02 265	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:10 06	pipeline_state	kSeeking
00:00:10 06	audio_buffering_state	BUFFERING_HAVE_NOTHING
00:00:10 06	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:10 23	pipeline_state	kPlaying
00:00:10 28	pipeline_state	kSeeking
00:00:10 725	pipeline_state	kPlaying
00:00:10 767	audio_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:12 163	height	1440
00:00:12 163	width	2560
00:00:12 201	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:12 201	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:00:14 605	video_buffering_state	BUFFERING_HAVE_NOTHING
00:00:14 659	video_buffering_state	BUFFERING_HAVE_ENOUGH
 
Zuletzt bearbeitet:
Danke fürs testen. Laut deinem Posting nutzt Iron bei dir den VpxVideoDecoder, damit ist es nicht GPU gestützt. Dort müsste GpuVideoDecoder stehen.

Ich werde mal andere Browser durchprobieren, hab aber die Vermutung das alle die auf Chromium basieren, das gleiche Problem haben werden.
 
Mir ist noch keine AMD-Grafikkarte untergekommen, bei der die VP9-Hardwarebeschleunigung unter Chrome wirklich funktioniert hätte. Bei den schnellen Desktop-Systemen (Vishera, Kaveri, etc.) spielt das keine Rolle, da die CPU das in der Regel wuppt. Bei den kleinen Katzen-Kernen jedoch installiere ich unter Chrome schon seit geraumer Zeit die Erweiterung h264ify. Damit wird YouTube dazu veranlasst, auch mit Chrome als Browser statt VP9-Material H.264-Streams auszuliefern; und dafür gibt es ja funktionierende Hardware-Beschleunigung auch mit AMD-Grafikkarten.

Leicht herauszufinden mit Rechtsklick auf das Video, Statistiken für Nerds. Steht dort bei Mime-Type irgendwas von VP9 läuft YouTube mit Standard-Einstellungen für Chrome. Steht dort jedoch irgendwas mit avc, ist das Addon wirksam :D Hat unter Kabini die CPU-Last mehr als halbiert :D
 
Zuletzt bearbeitet:
Mir ist noch keine AMD-Grafikkarte untergekommen, bei der die VP9-Hardwarebeschleunigung unter Chrome wirklich funktioniert hätte. Bei den schnellen Desktop-Systemen (Vishera, Kaveri, etc.) spielt das keine Rolle, da die CPU das in der Regel wuppt. Bei den kleinen Katzen-Kernen jedoch installiere ich unter Chrome schon seit geraumer Zeit die Erweiterung h264ify. Damit wird YouTube dazu veranlasst, auch mit Chrome als Browser statt VP9-Material H.264-Streams auszuliefern; und dafür gibt es ja funktionierende Hardware-Beschleunigung auch mit AMD-Grafikkarten.

Leicht herauszufinden mit Rechtsklick auf das Video, Statistiken für Nerds. Steht dort bei Mime-Type irgendwas von VP9 läuft YouTube mit Standard-Einstellungen für Chrome. Steht dort jedoch irgendwas mit avc, ist das Addon wirksam :D
Naja, die 60FPS laufen bei mir besser mit Chrome als mit allen anderen Browsern, da kommt einfach keiner an die nativen 60FPS ran.
Aber gut zu wissen das es ein Erweiterung gibt die h264 nutzt, das kannte ich noch nicht. :)

Hier mal noch mit 1440p, CPU Auslastung ist höher, aber läuft sauber: http://abload.de/img/chrom_youtube_vp9_144utskj.jpg
P.S. in GPUz bei den Einstellungen unter Sensors den Abfrage-intervall auf 0,1 Sekunden stellen.
Dann sieht man wie die GPU Auslastung sehr schnell wechselt und 100% Peaks erreicht.
 
Also ich hab mal das SDK installiert, hat aber keine Auswirkung. Es wird unter chrome://media-internals/ weiterhin "VpxVideoDecoder" statt "GpuVideoDecoder" gezeigt. Durch den Forenposts, die ich oben verlinkt hab, kann ich ja das VP9 über Registry erzwingen, dann läuft es über die GPU, aber auch mit starken Macken, wie z.B. das es lange dauert, bis das Video überhaupt startet:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000\UMD\DXVA]
"VForceOCLVP9"="1"
Dann gibt es in Chrome einen Parameter, der es auch aktiv macht, dort hüpft das Videobild aber...

Ich denke dass die fehlende VP9 Untersützung wohl am Ende mehr ein Treiberproblem darstellt, was aber schon seit längerer Zeit ungelöst ist und einfach von AMD deaktiviert wurde.

Habt ihr eigtl in Chrome den GPU Rasterizer aktiv? Kann man über chrome://gpu prüfen. "Rasterization: Hardware accelerated"
Wenn es bei euch aktiv ist, könnt ihr mal nachprüfen, ob bei euch die Youtube Endcards auch so extrem Ruckeln im Vollbild?
 
Hast du schon andere Browser probiert? Welche?
 
Also ich hab mal das SDK installiert, hat aber keine Auswirkung. Es wird unter chrome://media-internals/ weiterhin "VpxVideoDecoder" statt "GpuVideoDecoder" gezeigt. Durch den Forenposts, die ich oben verlinkt hab, kann ich ja das VP9 über Registry erzwingen, dann läuft es über die GPU, aber auch mit starken Macken, wie z.B. das es lange dauert, bis das Video überhaupt startet:

Dann gibt es in Chrome einen Parameter, der es auch aktiv macht, dort hüpft das Videobild aber...

Ich denke dass die fehlende VP9 Untersützung wohl am Ende mehr ein Treiberproblem darstellt, was aber schon seit längerer Zeit ungelöst ist und einfach von AMD deaktiviert wurde.

Habt ihr eigtl in Chrome den GPU Rasterizer aktiv? Kann man über chrome://gpu prüfen. "Rasterization: Hardware accelerated"
Wenn es bei euch aktiv ist, könnt ihr mal nachprüfen, ob bei euch die Youtube Endcards auch so extrem Ruckeln im Vollbild?
Danke für den Reg-key! :)
Ich probier es mal aus, was meinst du mit Youtube Endcards ?

GPU Rasterizer (R7970 3GByte):
Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only, hardware acceleration unavailable
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
VPx Video Decode: Hardware accelerated
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
clear_uniforms_before_first_program_use
decode_encode_srgb_for_generatemipmap
disable_discard_framebuffer
disable_dxgi_zero_copy_video
disable_framebuffer_cmaa
disable_nv12_dxgi_video
exit_on_context_lost
force_cube_complete
scalarize_vec_and_mat_constructor_args
texsubimage_faster_than_teximage
Problems Detected
GPU rasterization should only be enabled on NVIDIA and Intel DX11+, and AMD RX-R2 GPUs for now.: 643850
Disabled Features: gpu_rasterization

Some drivers are unable to reset the D3D device in the GPU process sandbox
Applied Workarounds: exit_on_context_lost
TexSubImage is faster for full uploads on ANGLE
Applied Workarounds: texsubimage_faster_than_teximage
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
ANGLE crash on glReadPixels from incomplete cube map texture: 518889
Applied Workarounds: force_cube_complete
Framebuffer discarding can hurt performance on non-tilers: 570897
Applied Workarounds: disable_discard_framebuffer
NV12 DXGI video hangs or displays incorrect colors on AMD drivers: 623029, 644293
Applied Workarounds: disable_dxgi_zero_copy_video, disable_nv12_dxgi_video
Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
Applied Workarounds: disable_framebuffer_cmaa
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Decode and Encode before generateMipmap for srgb format textures on Windows: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
Disabled Features: native_gpu_memory_buffers
Version Information
Data exported 18.5.2017, 21:28:30
Chrome version Chrome/58.0.3029.110
Operating system Windows NT 10.0.14393
Software rendering list version 12.20
Driver bug list version 9.36
ANGLE commit id 461d9a3060e3
2D graphics backend Skia/58 4c81ba6ba3a3270db809bf7d4c3bc782694a56a4
Command Line Args Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
 
Code:
Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Hardware accelerated
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
VPx Video Decode: Hardware accelerated
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
 
Hast du schon andere Browser probiert? Welche?

Derzeitig erstmal Iron Portable. Gleiches Problem, aber auch logisch, weil gleiche Browser Engine.
Weitere wollte ich die Tage noch testen.

@WindHund: z.B. schau mal hier: https://www.youtube.com/watch?v=Uh0bYafIgy8&t=32m59s
Sobald GPU Rasterization aktiv ist, ruckelt die Animation und das Video im Vollbild, sobald man mit der Maus über diese anderen Videos unten fährt.

@Gozu: Könntest du mal probieren, ob du das Ruckeln bei den Youtube Endcards auch hast im Vollbild? Wäre interessant. Danke :)
 
@WindHund: z.B. schau mal hier: https://www.youtube.com/watch?v=Uh0bYafIgy8&t=32m59s
Sobald GPU Rasterization aktiv ist, ruckelt die Animation und das Video im Vollbild, sobald man mit der Maus über diese anderen Videos unten fährt.
Alles klar, du meinst die BildINBild Overlays (Einblendungen) am Ende des Video so lange es noch läuft?
Ich hab GPU Rasterization nicht aktiv, wenn ich über die "Endcards" mit der Maus gehe, dann wird das Video abgedunkelt, aber die Endcards bleiben gleich hell.
Aber es ruckelt nichts in dem Moment (Athlon 5350)
Chrome/GPU meldet man soll die Rasterization nur bei den genannten Archs nutzen, welchen Hintergrund könnte das haben?
 
Zurück
Oben Unten