News Doom: Vulkan-Unterstützung für mehr Leistung ist online

litros · 12. Juli 2016

Del Torres schrieb:
@litros Wie will nv zurück schlagen, wenn sie doch schon in DX11 recht gut da stehen? Mehr Rechenpower bekommen die Karten ja nicht.

Wenn Spiele mit Vulkan -Unterstützung auf AMD so gut laufen dann warum eine deutlich teuere NV-Karte kaufen? (http://www.guru3d.com/news_story/new_patch_brings_vulkan_support_to_doom.html dieses Beispiel ziegt, dass, gerade für Doom, der Erwerb einer GTX 1070 sinnlos ist).

Natürlich müssen noch mehr Spiele mit Vulkan-API kommen, ich bin mir jedoch sicher, dass dies bald der Fall sein wird.

Was kann NV machen um "zurückzuschlagen" Preis senken! werden die aber niemals tun. Die Volta-Generation wird besser mit Vulkan und Asynchronous Compute umgehen.

Sly123 · 12. Juli 2016

Schon beachtlich, was die AMD-Karten bei Vulkan leisten.
Das zeigt eigentlich das Potential der RX 480.
nVidia ist dafür insgesamt FPS-stabil und verträgt sich scheinbar schlecht mit Vulkan.

Es tut sich definitiv etwas am Grafikkartenmarkt.

Anon-525334 · 12. Juli 2016

Hubraum ist durch nichts zu ersetzen. Irgendwann muss die Rohleistung mal freigesetzt werden. Die 970 und die 980 werden immer langsamer und die die 480 wird immer schneller. Man kann halt nichts unterstützen was nicht vorhanden ist. Die FuryX wird Kreise um die 1080 fahren mit Vulkan.

Faust2011 · 12. Juli 2016

t3chn0 schrieb:
Ich verstehe wirklich nicht, warum die lowlevel APIs und MultiGPU wirklich MASSIV gepushed werden.

Soweit ich das verstanden habe, kann man damit mehr Objekte zur Grafikkarte für die Darstellung rüberschieben. Derzeit liegt das Limit in der Praxis bei ca. 10.000 (?) Drawcalls (--> ein Drawcall ist ein Zeichenbefehl für eine komplexe Geometrie, z. B. ein Auto/Mensch/Haus/...). Bei Lowlevel-APIs liegt das Limit mehrere Faktoren darüber, d.h. man Szenen in Zukunft detailreicher darstellen / mit mehr Leben füllen.

t3chn0 schrieb:
Denn, wenn ich mir Ashes of the Singularity hier bei mir auf dem Rechner angucke, dann wird einem auch der CPU-Overhead angezeigt.

Wie / wo kann man den CPU-Overhead des Treibers gezielt sehen?

Krautmaster · 12. Juli 2016

MaLow17 schrieb:
Und zum tausendsten Mal kommst Du jetzt mit Deiner Predigt (mit AMD + Directx 11 = meh!) und failst ganz gewaltig, da Doom überhaupt nichts mit DirectX zu tun hat. Doom benutzt die OpenGL-API...

Hier die Quelle zu den Screenshots:
http://www.guru3d.com/news-story/new-patch-brings-vulkan-support-to-doom,3.html

Und Deine Behauptung, dass AMD-Karten unter DirectX schlecht abschneiden stimmt nicht, es hilft Dir nicht das 1000 Mal zu wiederholen. Du verallgemeinerst mit Deiner Aussage DirectX (...DX7, DX8, DX9, DX10, DX10.1, DX11, DX12).

Bestes Beispiel:
https://www.computerbase.de/2016-06/nvidia-geforce-gtx-1070-test/4/#diagramm-hitman-2560-1440

natürlich stimmt das. Ist doch kein Geheimnis dass aktuelle Karten öfters mäßig ausgelastet werden (ja sorry bei DOOM OpenGL statt DX11). Genau deswegen push AMD ja DX12 / Vulkan usw. Genau deswegen wurde Mantle entwickelt.

Wo ist dein Problem? Ich sage ja dass der Abstand in Doom unter aktuell gängigem Renderer (sei es DX sei es OpenGL herje...) zwischen AMD und Nvidia untypisch groß ist. Ergo kann die Auslastung der AMD Karten da nicht wirklich gut sein. Und entsprechend satt sind die Gewinne bei neuer API, was ja gut ist.

Edit: Doom zeigt also eher dass OpenGL bei AMD fast noch mehr Handlungsbedarf hat / hatte als DX11. Wenn OpenGL nun fleißig auf Vulkan portiert wird ist das gut für rot. Gibt aber aktuell nicht wirklich viele OpenGL Titel oder?

Ergänzung (12. Juli 2016)

rockwell1080 schrieb:
29% sinds bei 1080p, was ein viel vernünftiger Vergleich ist als bei UHD. (Niemand kauft die 480 für 4k)

wirklich vernünftig ist ein Vergeich im GPU Limit, nicht bei 1080p. Egal welche API.

MaLow17 · 12. Juli 2016

Krautmaster schrieb:
Wo ist dein Problem? Ich sage ja dass der Abstand in Doom unter gängigem Renderer (sei es DX sei es OpenGL herje...) zwischen AMD und Nvidia untypisch groß ist. Ergo kann die Auslastung der AMD Karten da nicht wirklich gut sein. Und entsprechend satt sind die Gewinne bei neuer API, was ja gut ist.

Nix herrje, Du nutzt wieder einmal eine dieser News, um Deinen verallgemeinerten Schrott über DirectX und (alle?) AMD-Karten (in jedem Spiel?) zu verbreiten, doch leider funktioniert das jetzt nicht, da Doom keine DirectX-API benutzt. Wenn man schon Schnittstellen verwechselt bzw. gleichsetzt...

tek9 · 12. Juli 2016

litros schrieb:
Wenn Spiele mit Vulkan -Unterstützung auf AMD so gut laufen dann warum eine deutlich teuere NV-Karte kaufen? (http://www.guru3d.com/news_story/new_patch_brings_vulkan_support_to_doom.html dieses Beispiel ziegt, dass, gerade für Doom, der Erwerb einer GTX 1070 sinnlos ist).

Natürlich müssen noch mehr Spiele mit Vulkan-API kommen, ich bin mir jedoch sicher, dass dies bald der Fall sein wird.

Was kann NV machen um "zurückzuschlagen" Preis senken! werden die aber niemals tun. Die Volta-Generation wird besser mit Vulkan und Asynchronous Compute umgehen.

Was soll man dazu sagen wenn bereits jetzt die ersten Stimmen laut werden die auf die nächste Generation von nvidia warten?

Ich finde diese Async Compute Schwäche der nvidia Karten äußerst fragwürdig. Wenn nvidia jahrelang Karten verkauft die DX12 und Vulkan nur auf dem Papier beschleunigen, aber in der Realität schwächeln wird es noch ewig dauern bis diese API durchgängig eingesetzt werden.

Dieses Jahr ist nicht besonders erfrischend. Entweder man nimmt die 480 für FullHD und Async Compute oder man kauft für fast doppelt so viel Geld die 1070/80 mit ihrer rasiermesserscharf auf DX11/Ogl optimierten Architektur.

Gerade sind die neuen Karten auf dem Markt und eigentlich kann man nur auf Vega und Volta warten. Wer eine Last Gen Karte besitzt hat eigentlich keine Motivation was neues anzuschaffen.

Eine vernünftige Karte die mit allen API klar kommt und sehr hohe Auflösungen anpackt wird es dieses Jahr nicht mehr geben.

Schade.

r4yn3 · 12. Juli 2016

Pauschalisieren würde ich hier nicht, das Nvidia nicht zulegen kann. Mit dem "passenden" Unterbau, lassen sich auch hier enorme Steigerungen erzielen. Link aus der PCGH News über Vulkan in Doom: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=11098171&postcount=1084

Krautmaster · 12. Juli 2016

@MaLow17

es ging nicht um die Schnittstelle sondern Auslastung der GPU. In meinem Post habe ich nicht wirklich was anderes geschrieben als den Umstand dass der Abstand in Doom zwischen Grün und Rot ohnehin schon extrem war / ist, größer als eben im Durchschnitt.

Mit dem neuen Vulkan Renderpfad gewinnt man also satt, einfach weil mit dem gewöhnlichen Renderpfad (egal wie er heißt) was im argen ist und deswegen die Karten auch recht mau abschneiden.

Edit:

Wichtig ist die Differenz die hinten bei rauskommt. Und da siehts doch für AMD gut aus. Aus einem Titel der AMD schlechter als der Durchschnitt liegt wurde ein Titel der AMD besser als der Durchschnitt liegt. Dank Vulkan.

Hilpi · 12. Juli 2016

Vllt liegts auch einfach an der verwendeten Vulkan Version in DOOM

Bei NV steht 1.0.8, bei AMD 1.0.17

Bin eh schon lange durch

Krautmaster · 12. Juli 2016

r4yn3 schrieb:
Pauschalisieren würde ich hier nicht, das Nvidia nicht zulegen kann. Mit dem "passenden" Unterbau, lassen sich auch hier enorme Steigerungen erzielen. Link aus der PCGH News über Vulkan in Doom: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=11098171&postcount=1084

jup, viele verkennen dass Vulkan / DX12 nicht zum Ziel haben die GPU Leistung zu erhöhen, viel mehr geht es eben darum den CPU / API Flaschenhals zu reduzieren (wodurch eben die GPU Auslastung gerade auch bei AMD meist erst in Fahrt kommt). Es ist immer lächerlich wenn mit einer 4,5 Ghz GPU gebenched wurde und erwartet wird dass das Entfernen eines quasi kaum existenten Flaschenhalses mega die Verbesserungen bringt.

DX12 funktioniert in Tomb Raider auch 1a, wenn man mit schwachen CPU testet sieht man das auch. Genauso in deinem Link mit der GTX 970 und dem FX. Genauso bei Hitman.

t3chn0 · 12. Juli 2016

Faust2011 schrieb:
Soweit ich das verstanden habe, kann man damit mehr Objekte zur Grafikkarte für die Darstellung rüberschieben. Derzeit liegt das Limit in der Praxis bei ca. 10.000 (?) Drawcalls (--> ein Drawcall ist ein Zeichenbefehl für eine komplexe Geometrie, z. B. ein Auto/Mensch/Haus/...). Bei Lowlevel-APIs liegt das Limit mehrere Faktoren darüber, d.h. man Szenen in Zukunft detailreicher darstellen / mit mehr Leben füllen.

Wie / wo kann man den CPU-Overhead des Treibers gezielt sehen?

Ich habe dazu ein Video gemacht, allerdings noch mit der Founders Edition:

https://www.youtube.com/watch?v=izqbA2IjZa8

Geh mal zu 5:50 und ab da siehst du unten den CPU Overhead. Der ist bei DX11 etwas höher (hier quasi nicht vorhanden) . Ich lasse das nochmal eben mit der RX480 und DX11/12 durchlaufen.

Inxession · 12. Juli 2016

Krautmaster schrieb:
naja gut, in DX is eine GTX 1070 satte 62% schneller als eine RX 480 (in Doom). Das ist viel, untypisch viel. Deswegen sollte man nicht nur auf den Gain zb von DX11 RX 480 ->Vulkan RX 480 schauen sondern eher beachten was generell bei rauskommt. Aktuell könnte man eher meinen dass AMD direkt auf eine Optimierung bezüglich Doom verzichtet hat und direkt auf Vulkan ging. Anders kann man sich die derart schlechte DX Performance in Doom ja kaum erklären.

62% schneller und 70% teurer ..

Äpfel und Birnen .. die 1070 mit RX480 zu vergleichen..

rockwell1080 · 12. Juli 2016

Krautmaster schrieb:
wirklich vernünftig ist ein Vergeich im GPU Limit, nicht bei 1080p. Egal welche API.

Nein, ab 1080p setzt bei der 480 ein Füllratenflaschenhals ein (halb soviele ROPS die auch noch niedriger getaktet sind)
"GPU-Limit" ist unnötiges Wischi-waschi in diesem Fall
Abgesehen davon ist der traditionell niedrigere Driver-overhead bei NV eher ein Vorteil für die 1070 bei der kleinsten Auflösung.

Marco^^ · 12. Juli 2016

SpeedKill08 schrieb:
Denke ich auch, aber mal schauen, vielleicht kommt es doch anders und durch Vulkan ist Linux irgendwann vielleicht doch ne gleichwertige Spieleplattform.

Habe grade ein Spielchen OpenArena hinter mir, habe das Problem von Bildschirm-zu-Maus lag nach einer Spielzeit von ca 10Min

PC wirkt träge ^^

Hardware:

60Hz IPS Monitor / HDMI (kein Vsync, AF oder AA, com_maxfps "125" 125FPS ingame nicht stabil)

Intel i3-3250@3,5Ghz
nVidia GTX750 Treiber max Performence Profil, kein AA od. AF, 1920x1080@60Hz
https://www.asus.com/Graphics-Cards/GTX750DCSL2GD5/specifications/

Kein CPU Limiter aktiv für Prozesse

Code:

zypper info nvidia-gfxG04-kmp-default

Repository: nVidia
Name: nvidia-gfxG04-kmp-default
Version: 367.27_k4.1.12_1-24.1
Arch: x86_64
Vendor: obs://build.suse.de/home:sndirsch:drivers
Installed: Yes
Status: up-to-date

Code:

zypper info fglrx64_xpic_SUSE421

Repository: AMD-fglrx
Name: fglrx64_xpic_SUSE421
Version: 15.302.3-1
Arch: x86_64
Vendor:
Installed: No

JA, macht echt Spass ...

Die Config stimmt nicht mit dem überein was ich im Menü ausgewählt habe, ist immer noch buggy

Wenn man die config manuell in der Texdatei bearbeit, kann es sein das sie nicht automatisch geladen wird !

Linux Console AltGr & + zusammen drücken (Win ^ ?)
writeconfig autoexec

Code:

unbindall
bind TAB "weapon 1"
bind ENTER "+button2"
bind ESCAPE "togglemenu"
bind SPACE "+zoom"
bind + ""
bind - ""
bind / ""
bind 0 "say ^5GG*"
bind 1 "say ^5:)"
bind 2 ""
bind 3 ""
bind 4 ""
bind 6 ""
bind 7 "say ^5GG"
bind 8 ""
bind 9 "say ^5HF"
bind = ""
bind [ ""
bind \ ""
bind ] ""
bind _ ""
bind ` "toggleconsole"
bind a "weapon 6"
bind b "weapon 9"
bind c "weapon 4"
bind d "+back"
bind e "+forward"
bind f "+moveright"
bind g "weapon 8"
bind j "vote yes"
bind n "vote no"
bind q "weapon 2"
bind s "+moveleft"
bind t "weapon 13"
bind v "weapon 10"
bind w "weapon 3"
bind ~ "toggleconsole"
bind PAUSE ""
bind HOME ""
bind LEFTARROW ""
bind RIGHTARROW ""
bind ALT "+strafe"
bind CTRL "+speed"
bind SHIFT "+movedown"
bind DEL ""
bind PGDN ""
bind END "screenshotJPEG"
bind F1 "+scores"
bind F2 "messagemode"
bind F3 "messagemode2"
bind F4 "messagemode3"
bind F5 "callvote map_restart"
bind F6 "callvote nextmap"
bind F12 ""
bind MOUSE1 "+attack"
bind MOUSE2 "+moveup"
bind MOUSE3 "weapon 7"
bind MWHEELDOWN "weapon 5"
bind MWHEELUP "weapon 5"
bind AUX1 "+button2"
seta cg_autovertex "1"
seta cg_voipTeamOnly "0"
seta cg_crosshairHealth "0"
seta cg_crosshairColorRed "1"
seta cg_crosshairColorBlue "1"
seta cg_crosshairColorGreen "1"
seta cg_simpleItems "1"
seta cg_alwaysWeaponBar "1"
seta cg_forcemodel "1"
seta cg_drawTeamOverlay "1"
seta cg_delag "1"
seta cg_drawGun "0"
seta cg_zoomfov "80"
seta cg_fov "110"
seta cg_gibs "0"
seta cg_draw2D "1"
seta cg_drawStatus "1"
seta cg_drawTimer "0"
seta cg_drawFPS "1"
seta cg_drawSnapshot "0"
seta cg_draw3dIcons "1"
seta cg_drawIcons "1"
seta cg_drawAmmoWarning "1"
seta cg_drawAttacker "0"
seta cg_drawSpeed "0"
seta cg_drawRewards "0"
seta cg_crosshairSize "24"
seta cg_crosshairX "0"
seta cg_crosshairY "0"
seta cg_lagometer "1"
seta cg_railTrailTime "1500"
seta cg_runpitch "0.002"
seta cg_runroll "0.005"
seta cg_bobpitch "0.002"
seta cg_bobroll "0.002"
seta cg_teamChatTime "3000"
seta cg_teamChatHeight "8"
seta cg_deferPlayers "1"
seta cg_drawFriend "1"
seta cg_teamChatsOnly "0"
seta cg_noVoiceChats "1"
seta cg_noVoiceText "1"
seta cg_hitsound "0"
seta cg_cyclegrapple "1"
seta cg_cameraOrbitDelay "50"
seta cg_scorePlums "1"
seta cg_noTaunt "1"
seta cg_noProjectileTrail "1"
seta ui_smallFont "0.25"
seta ui_bigFont "0.4"
seta cg_oldRail "1"
seta cg_oldRocket "1"
seta cg_leiEnhancement "0"
seta cg_leiGoreNoise "0"
seta cg_leiBrassNoise "0"
seta cg_leiSuperGoreyAwesome "0"
seta cg_oldPlasma "1"
seta cg_cmdTimeNudge "0"
seta cg_projectileNudge "0"
seta cg_optimizePrediction "1"
seta cg_trueLightning "0.7"
seta cg_music ""
seta cg_fragmsgsize "1.0"
seta cg_crosshairPulse "0"
seta cg_differentCrosshairs "0"
seta cg_chatBeep "0"
seta cg_teamChatBeep "1"
seta cm_playerCurveClip "1"
seta cg_shadows "0"
seta cl_timeNudge "0"
seta com_hunkMegs "128"
seta com_altivec "0"
seta com_maxfps "125"
seta com_blood "0"
seta com_ansiColor "0"
seta com_maxfpsUnfocused "0"
seta com_maxfpsMinimized "0"
seta com_busyWait "1"
seta com_introplayed "1"
seta vm_cgame "2"
seta vm_game "2"
seta vm_ui "2"
seta cl_timedemoLog ""
seta cl_autoRecordDemo "0"
seta cl_aviFrameRate "25"
seta cl_aviMotionJpeg "1"
seta cl_maxpackets "30"
seta cl_packetdup "0"
seta cl_run "1"
seta sensitivity "4.0"
seta cl_mouseAccel "0"
seta cl_freelook "1"
seta cl_mouseAccelStyle "0"
seta cl_mouseAccelOffset "5"
seta cl_allowDownload "1"
seta cl_cURLLib "libcurl.so.4"
seta r_inGameVideo "1"
seta cg_autoswitch "0"
seta m_pitch "0.022000"
seta m_yaw "0.022"
seta m_forward "0.25"
seta m_side "0.25"
seta m_filter "0"
seta cl_maxPing "800"
seta cl_lanForcePackets "1"
seta cl_guidServerUniq "1"
seta cl_consoleKeys "~ ` 0x7e 0x60"
seta cl_consoleType "2"
seta cl_consoleColorRed "1"
seta cl_consoleColorGreen "1"
seta cl_consoleColorBlue "1"
seta cl_consoleColorAlpha "0.8"
seta cl_consoleHeight "0.3"
seta con_speed "99"
seta rate "25000"
seta snaps "20"
seta model "sarge/indigo"
seta headmodel "sarge/classicblue"
seta team_model "sarge/indigo"
seta team_headmodel "sarge/indigo"
seta g_redTeam ""
seta g_blueTeam ""
seta color1 "3"
seta color2 "3"
seta handicap "100"
seta sex "male"
seta cl_anonymous "0"
seta cg_predictItems "1"
seta cl_useMumble "0"
seta cl_mumbleScale "0.0254"
seta cl_voipGainDuringCapture "0.2"
seta cl_voipCaptureMult "2.0"
seta cl_voipUseVAD "0"
seta cl_voipVADThreshold "0.25"
seta cl_voipShowMeter "0"
seta cl_voip "0"
seta cg_viewsize "100"
seta r_allowExtensions "1"
seta r_ext_compressed_textures "0"
seta r_ext_multitexture "1"
seta r_ext_compiled_vertex_array "1"
seta r_ext_texture_env_add "1"
seta r_ext_texture_filter_anisotropic "0"
seta r_ext_max_anisotropy "2"
seta r_postprocess "none"
seta r_ext_vertex_shader "1"
seta r_picmip "0"
seta r_roundImagesDown "1"
seta r_detailtextures "1"
seta r_texturebits "32"
seta r_colorbits "0"
seta r_stencilbits "0"
seta r_depthbits "0"
seta r_ext_multisample "0"
seta r_brightness "1.4"
seta r_overBrightBits "1"
seta r_ignorehwgamma "0"
seta r_mode "-1"
seta r_fullscreen "1"
seta r_noborder "0"
seta r_customwidth "1920"
seta r_customheight "1080"
seta r_customPixelAspect "1"
seta r_simpleMipMaps "1"
seta r_subdivisions "4"
seta r_smp "1"
seta r_stereoEnabled "0"
seta r_ignoreFastPath "1"
seta r_greyscale "0"
seta r_monolightmaps "0"
seta r_lodCurveError "250"
seta r_lodbias "0"
seta r_flares "1"
seta r_zproj "64"
seta r_stereoSeparation "64"
seta r_ignoreGLErrors "1"
seta r_fastsky "1"
seta r_drawSun "0"
seta r_dynamiclight "0"
seta r_dlightBacks "1"
seta r_finish "0"
seta r_textureMode "GL_LINEAR_MIPMAP_NEAREST"
seta r_swapInterval "0"
seta r_gamma "0.9"
seta r_facePlaneCull "1"
seta r_railWidth "16"
seta r_railCoreWidth "6"
seta r_railSegmentLength "32"
seta r_primitives "0"
seta r_anaglyphMode "0"
seta r_marksOnTriangleMeshes "0"
seta r_aviMotionJpegQuality "90"
seta r_screenshotJpegQuality "90"
seta r_flaresDlight "0"
seta r_envMode "1"
seta r_specMode "1"
seta r_lensReflection1 "1"
seta r_lensReflection2 "0"
seta r_lensReflectionBrightness "0.5"
seta r_bloom "0"
seta r_allowResize "0"
seta r_centerWindow "0"
seta in_keyboardDebug "0"
seta in_mouse "1"
seta in_nograb "0"
seta in_joystick "0"
seta in_joystickThreshold "0.15"
seta s_volume "0.4"
seta s_musicvolume "0"
seta s_doppler "1"
seta s_muteWhenMinimized "0"
seta s_muteWhenUnfocused "0"
seta s_useOpenAL "1"
seta s_alPrecache "1"
seta s_alGain "1.0"
seta s_alSources "96"
seta s_alDopplerFactor "1.0"
seta s_alDopplerSpeed "2200"
seta s_alDriver "libopenal.so.1"
seta s_alDevice ""
seta s_alCapture "1"
seta ui_ffa_fraglimit "20"
seta ui_ffa_timelimit "0"
seta ui_tourney_fraglimit "0"
seta ui_tourney_timelimit "15"
seta ui_team_fraglimit "0"
seta ui_team_timelimit "20"
seta ui_team_friendly "1"
seta ui_ctf_capturelimit "8"
seta ui_ctf_timelimit "30"
seta ui_ctf_friendly "0"
seta ui_1fctf_capturelimit "8"
seta ui_1fctf_timelimit "30"
seta ui_1fctf_friendly "0"
seta ui_overload_capturelimit "8"
seta ui_overload_timelimit "30"
seta ui_overload_friendly "0"
seta ui_harvester_capturelimit "20"
seta ui_harvester_timelimit "30"
seta ui_harvester_friendly "0"
seta ui_elimination_capturelimit "8"
seta ui_elimination_timelimit "20"
seta ui_ctf_elimination_capturelimit "8"
seta ui_ctf_elimination_timelimit "30"
seta ui_lms_fraglimit "20"
seta ui_lms_timelimit "0"
seta ui_dd_capturelimit "8"
seta ui_dd_timelimit "30"
seta ui_dd_friendly "0"
seta ui_dom_capturelimit "500"
seta ui_dom_timelimit "30"
seta ui_dom_friendly "0"
seta ui_browserMaster "1"
seta ui_browserGameType "1"
seta ui_browserSortKey "4"
seta ui_browserShowFull "1"
seta ui_browserShowEmpty "1"
seta cg_brassTime "0"
seta cg_drawCrosshair "4"
seta cg_drawCrosshairNames "0"
seta cg_marks "0"
seta server1 "144.76.100.87:27993"
seta ui_browserOnlyHumans "1"
seta ui_setupchecked "1"
seta r_vertexLight "1"
seta com_zoneMegs "24"
echo "<<< AUTOEXEC >>>"

DocWindows · 12. Juli 2016

Del Torres schrieb:
Wie will nv zurück schlagen, wenn sie doch schon in DX11 recht gut da stehen? Mehr Rechenpower bekommen die Karten ja nicht.

nVidia könnte es einfach so machen wie AMD.
Massig mehr Shader verbauen, dafür bei niedrigerem Takt betreiben und diese dann versuchen auszulasten. Dann würden sie natrlich auch genauso wie AMD von DX12 und Async Compute profitieren, weil diese Techniken ja genau dafür da sind.

t3chn0 · 12. Juli 2016

So, gerade mal Ashes nochmal mit der RX480 getestet. Der Unterschied zwischen DX11 und DX12 ist relativ gewaltig.

Denn, auch wenn es unterm Strich nur 4FPS mehr sind, so merkt man direkt, dass alles deutlich direkter und flüssiger ist.

Bei Nvidia liegen die Werte bei AoS für den Overhead bei DX11 und 12 relativ beisammen. Deshalb wirkt AoS auf einer Nvidia Karte auch deutlich flüssiger unter DX11 als bei einer AMD Karte.

Bei DX12 liegen AMD und Nvidia sehr dicht beisammen.

Was wundervoll zu sehen ist, der Overhead wird MASSIV reduziert und die Limitierung durch die GPU geht auf 100% in jedem Szenario, also perfekte Auslastung der GPU. Ich gucke mal was ein massives OC hier an Vorteilen bringt. Denn, wenn ein GPU Limit von 100% vorherrscht, sollte jeder Ticken Frequenz, Bandbreite an der GPU für Verbesserung sorgen.

Genau hier setze ich mit meiner Forderung an! Wenn man jetzt eine 2. 480 für Crossfire mit mind. 80% Skalierung einsetzen würde, so wäre das ein Traum!

So könnte man wirklich aus jedem Spiel wirklich etwas machen. Ich finde, dass DX11 Titel unter AMD einfach nicht schön laufen, kann man drehen und wenden wie man will. Ich hatte das auch schon bei meiner FuryX damals bemängelt.

Man sieht doch was die Karten unter einer lowlevel API leisten können.

DX11

DX12

Del Torres · 12. Juli 2016

tek9 schrieb:
Eine vernünftige Karte die mit allen API klar kommt und sehr hohe Auflösungen anpackt wird es dieses Jahr nicht mehr geben.

Also meine GTX 1080 kommt mit allen APIs, sowohl mit OpenGL, DirectX11, Vulkan und DirectX12 ganz gut zurecht^^ Das zeigen alle Benchmarks

Es ist echt erschreckend wieviele Leute den Sachverhalt von den Unterschieden bei AMD vs. kaum Unterschieden bei Nv einfach nicht verstehen. Dabei ist der Rohleistung auf die Straße Vergleich super einfach zu verstehen.

NV Karten sind halt überall gut, AMD Karten nur wenn die API darauf optimiert ist. Die AMD Karten holen mit DirectX12/Vulkan zu Nvidia auf und beide sind am optimalen FPS/gflop Wert der Architekturunabhängig möglich ist. AMD zaubert ja unter DX12/Vulkan doch keine Leistung aus nichts hervor. Das deren Karten einen hohen gflop Wert haben, ist ja bekannt und leicht nachzurechnen.
Was ist Zukunftssicherer? Beides!

Man kann doch einem Auto mit Traktionskontrolle nicht vorwerfen, wenn ein Auto ohne Traktionskontrolle auf einmal mit Traktionskontrolle gegen einen Antritt und gleich schnell wird.

-Hardy- · 12. Juli 2016

Ich habe mit meiner GTX 780 AMP und einem I7 6700K auch keinen nennenswerten Zuwachs an Leistung.

BookerDeWitt · 12. Juli 2016

Krautmaster schrieb:
jup, viele verkennen dass Vulkan / DX12 nicht zum Ziel haben die GPU Leistung zu erhöhen, viel mehr geht es eben darum den CPU / API Flaschenhals zu reduzieren

Wie wäre es, wenn man wahrheitsgetreu anerkennt, dass Vulkan als auch DX12 beides, also sowohl CPU-Overhead-Senkung, als auch moderne Techniken zur besseren/effizienteren GPU-Auslastung mitbringen?

Natürlich haben Techniken, wie Async Compute oder Shader Intrinsics das Ziel die GPU besser zu belasten!

Fragwürdig finde ich auf jeden Fall, dass nVidia diese Techniken nicht nutzt, selbst wenn sie schon eine gute Auslastung mit sich bringen, könnte diese -wie in Benchmarks zu sehen- noch besser sein, würde man sie unterstützen. Denn wie bereits angemerkt sind deine GamersNexus-Werte für die Tonne, da weder ohne AA oder PPAA, ergo ohne Asynchronous Compute, das den Radeons noch einen guten Schub beschert.

Faszinierend ist auch, wie lapidar nVidias fehlender Async-Support bei allen Generationen, also auch bei dem angeblich dazu fähigem Pascal von den Fans hingenommen wird. Mir geht es nicht darum, ob dies nun nVidia wirklich merklich Performance bringen würde oder nicht, es zeigt nur, dass für deren Karten eine Extrawurst gemacht werden muss, da die Architektur einfach immer noch nicht darauf ausgelegt wurde. Das wars also wieder mit Pascal-Lobhudeleien bei DX12/Vulkan...

News Doom: Vulkan-Unterstützung für mehr Leistung ist online

Cadet 3rd Year

Lt. Commander

Banned

HTTP 418 - I'm a teapot

Fleet Admiral

Lt. Commander

tek9

Gast

Admiral

Fleet Admiral

Lieutenant

Fleet Admiral

Admiral

Captain

Lieutenant

Lt. Commander

Vice Admiral

Admiral

Del Torres

Gast

Cadet 1st Year

Lieutenant

Ähnliche Themen

Passend zum Thema