Virallinen: NVIDIA vs AMD (vs Intel) keskustelu- ja väittelyketju

[neksva]

Itsellä ei ole ongelmia watmanin kanssa Vega 64 kanssa itsellä ainosastaan nollaa asetukset jos kellot eivät ole vakaat ja ajurit kaatuu muuten kaikki asetukset pysyy mukaanlukien kellotukset

 

[akse]

Voihan sen noinkin ajatella, mutta miksen kuluttajana ostaisi mieluumin korttia, joka vain toimii kaiken kanssa mitä haluan käyttää? Valitsen mieluumin itse koneellani olevat softat, kuin annan näyttiksen määrätä mitä saa tai ei saa käyttää.

Mulla on kyllä PC toiminu huonosti AMD:n kortilla. Avasin jonkun exe tiedoston ja nyt ei kone toimi.. tai toimii mutta pitäisi antaa rahaa jollekin että se avaa mun levyt.
Vituttaa tällaset kun tehdään jotain komponentteja ja softaa ja sitten ei toimi kaikkien mahdollisten juttujen kanssa, mitä tietokoneella availee.

 

[P c L A Y E R]

Jos koodaan nopeesti jonkun afterburnerin tavoin kelvottoman softan joka saa koneen kippaamaan nvAPI käskyillä, niin otetaan tasapeli tästä ajurien paskuudesta? Vai riittääkö että etin jonkun vanhan version ’burnerista jolla jotkut nvidian käyttäjät on saanu koneensa kippaamaan?

Jotain outohan tuossa kuitenkin on, kun aiemmat AMD:n kortit ovat toimineet "ongelmitta" Afterburnerin kanssa... Ei ole mitenkään todennäköistä, että AB:n kehittäjät olisivat vaan päättäneet olla tukematta Naveja. Ja jokuhan tuolla edellisellä sivulla kirjoitteli, että vanhemmilla ajureilla toimii AB Navissa, eli uudemmissa ajureissa todennäköisesti jotain on, mikä sen kippaa.

Mutta se nyt on selvä homma, että AMD:llä ei ole mitään intressejä tukea näitä 3rd party softia, kun itse kehittävät omaa softaansa.

 

[Muumi75]

Millä tavalla tämä sinun asiasi liittyy näytönohjaimiin tai amd:n? Voisitko tarkentaa mikä .exe edes kyseessä.

Oliskohan kyseessä sarkasmifiltterin kalibrointisofta?

 

[hkultala]

Eikös näytönohjainten säätösoftien pitäisi olla tehty näytönohjaimia varten eikä näytönohjainten niiden säätösoftia varten?

Vai pelaako porukka nykyään pelien sijasta näytönohjainten säätösoftia?

Hirveä valitus siitä, että joku kolmannen osapuolen purkkasofta jonka ainoa tehtävä on sen näyttiksen säätäminen bugaa vaan kuulostaa todella typerältä, kun siihen näyttiksen säätämiseen kuitenkin on muitakin softia.

 

[Cirrus]

Eikös näytönohjainten säätösoftien pitäisi olla tehty näytönohjaimia varten eikä näytönohjainten niiden säätösoftia varten?

Vai pelaako porukka nykyään pelien sijasta näytönohjainten säätösoftia?

Hirveä valitus siitä, että joku kolmannen osapuolen purkkasofta jonka ainoa tehtävä on sen näyttiksen säätäminen bugaa vaan kuulostaa todella typerältä, kun siihen näyttiksen säätämiseen kuitenkin on muitakin softia.

Ongelma taitaa olla se että et ole vähääkään tajunnut mistä on valitettu.

 

[hkultala]

Ongelma taitaa olla se että et ole vähääkään tajunnut mistä on valitettu.

Tajuan oikein hyvin. Siitä, että bugiselle purkkasoftalle annetaan koneelle admin-oikat ja sitten syytetään AMDn ajureita, kun se kaataa koneen.

Ei kannattaisi antaa niitä admin-oikkia niille purkkasoftille niin ne ei kaataisi sitä konetta.

 

[Cirrus]

Tajuan oikein hyvin. Siitä, että bugiselle purkkasoftalle annetaan koneelle admin-oikat ja sitten syytetään AMDn ajureita, kun se kaataa koneen.

Ei kannattaisi antaa niitä admin-oikkia niille purkkasoftille niin ne ei kaataisi sitä konetta.

Onko sinulla parempaa tietoa että bugi on afterburnerissa? Vai spekuloitko omiasi?

 

[hkultala]

Onko sinulla parempaa tietoa että bugi on afterburnerissa? Vai spekuloitko omiasi?

En spekuloi ainakaan yhtään sen enempää omiani kun mitä sinä spekuloit omiasi syyttäessäsi AMDn ajureita.

 

[Cirrus]

En spekuloi ainakaan yhtään sen enempää omiani kun mitä sinä spekuloit omiasi syyttäessäsi AMDn ajureita.

Aivan. No tämähän on täysin selvä. Höpötät omaa juttuasi siinä missä kaikki muutkin. Ja kommentit osoittavat että pointti pölisi kilometrin ohi, kun siihen piti vastata olkiukolla.

 

[hkultala]

Aivan. No tämähän on täysin selvä. Höpötät omaa juttuasi siinä missä kaikki muutkin. Ja kommentit osoittavat että pointti pölisi kilometrin ohi, kun siihen piti vastata olkiukolla.

Ensinnäkään, en vastannut millään olkiukolla.

Toisekseen: Täällä muutama muu kuin sinä(pomk, tomnav) on esittänyt ihan oikeita päteviä teknisiä perusteluja asialle.

Sinä olet täällä se, joka täällä höpöttää ihan omiansa. Mutta jälleen toteutuu tämä perinteinen, että muita syytetään ensimmäisenä siitä, mihin itse syyllistytään.

ja sitten niitä teknisiä perusteluja:

Mikäli monitoriointi-API on sellainen, että monitorointisofta pääsee sorkkimaan vapaasti I2C-väylää, niin tasan ainoa keino miten ajuri voi puolustautua bugista softaa vastaan on, ettei anna bugiselle softalle alunperinkään pääsyä siihen monitorointi-APIiin.

Se, että syytetään ajuria kun tällaista APIa käyttäävä softa buginsa takia ronkkii I2C-väylän solmuun on ihan väärän puun haukkumista.

 

[Cirrus]

Ensinnäkään, en vastannut millään olkiukolla.

Toisekseen: Täällä muutama muu kuin sinä on esittänyt ihan oikeita päteviä teknisiä perusteluja asialle, esitetäänpä niitä vielä:


Mikäli monitoriointi-API on sellainen, että monitorointisofta pääsee sorkkimaan vapaasti I2C-väylää, niin tasan ainoa keino miten ajuri voi puolustautua bugista softaa vastaan on, ettei anna bugiselle softalle alunperinkään pääsyä siihen monitorointi-APIiin.

Se, että syytetään ajuria kun tällaista APIa käyttäävä sofra ronkkii I2C-väylän solmuun on ihan värään puun haukkumista.

Tiedätkö että ongelma on I2C-väylässä ja sen "vapaassa sorkinnassa"? Koko keskustelu on täysin turhaa aivotonta lätinää jos et tiedä. Se on taas yhden mielikuvituskenaarion läpi käyntiä.

Ja muutenkin koko homma on täyttä huuhata yleistettynä. I2C:lle siinä missä kaikelle muullekin voi koodata apeja ja toimivia sellaisia.

 

[hkultala]

Tiedätkö että ongelma on I2C-väylässä ja sen "vapaassa sorkinnassa"? Koko keskustelu on täysin turhaa aivotonta lätinää jos et tiedä. Se on taas yhden mielikuvituskenaarion läpi käyntiä.

Koko ajan yrität kääntää asiaa väärinpäin.

Syytteen esittäjällä on todistustaakka. Sinä olet syyttänyt AMDtä bugisista ajureista, vaikka bugi on hyvin todennäköisesti muualla.

Ja sitten vaadit "aukotonta todistusta" siihen että bugi on muualla.

Ei, jos vaaditaan "aukotonta todistusta" niin se on SINÄ kenen se pitää esittää.

Ja tiedän, että tuo AMDn monitorointi-API antaa accessin siihen I2C-väylään:

display-library/adl_defines.h at master · GPUOpen-LibrariesAndSDKs/display-library

AMD Display Library SDK. Contribute to GPUOpen-LibrariesAndSDKs/display-library development by creating an account on GitHub.

github.com

Kaikki viittaa siihen, että se Afterburner sorkkii sitä I2C-väylää tavalla, jolta ajuri ei voisi mitenkään puolustautua, sen jälkeen kun on antanut sille afterburnerille pääsyn siihen. Mutta ilman afterburnerin lähdekoodia tästä ei ole varmaa tietoa.

 

[Cirrus]

Koko ajan yrität kääntää asiaa väärinpäin.

Syytteen esittäjällä on todistustaakka. Sinä olet syyttänyt AMDtä bugisita ajureista, vaikka bugi on hvyin todennäköisesti muualla.

Tiedän, että tuo AMDn monitorointi-API antaa accessin siihen I2C-vyäylään:

display-library/adl_defines.h at master · GPUOpen-LibrariesAndSDKs/display-library

AMD Display Library SDK. Contribute to GPUOpen-LibrariesAndSDKs/display-library development by creating an account on GitHub.

github.com

Jos sinä syytät i2c:tä niin sinä todistat i2c:n vian. En minä. ihme hommaa. Sinä veit keskustelun tekniselle detailitasolle. Joten parempi olla silloin jotain tietoa aiheesta.

Ja Jos voisin todistaa ajurivian, niin toki todistaisin. Ja olisin jo tehnyt ajat sitten. Mielipiteistähän tässä on keskusteltu ja hyvin hyvin yleisellä korkealla tasolla kun kellään ei ole oikeaa tietoa viedä keskustelua sinne tasan oikeaan tekniseen syyhyn.

Tiedätkö suoraan onko tuo i2c ajuri suoraan vai kätkeekö se i2c-liikenteen täysin allensa? Toki se voisi tutkimalla selvitä helpostikin.

editti: vastataan itse. Suoran kontrollin joihin tiettyihin väyliin. Mutta minulla ei ole hajuakaan mitä niillä tietyillä voi tehdä. Tämä spekulointiskenaario ei kanna hedelmää minun toimesta ainakaan.

 

[Kaotik]

Nyt alkaa @Cirrus riittämään ton sun vänkäämisen kanssa, et ole tuonut pöytään yhtään mitään tukea väitteillesi, muut ovat.

Afterburner sörkkii AMD:lla I2C-väylää sekä suoraan siruilla olevia jänniteregulaattoreita (SMC) ja tietää että sen sörkkimisestä tulee helposti ongelmia.
Jos mahdollista yrittävät myös välttää AMD:n rajapinnan käyttöä ja sörkkiä suoraan sitä korttia ihan omin nokkineen.
Keksivät myös omia "standardejaan" joita odottavat muiden noudattavan.

Kyllä, se on AMD ajureiden vika ettei Afterburner toimi
Asiaan liittyviä otteita ihan suoraan Afterburnerin vanhoista muutoslogeista

Hardware abstraction layer architecture has been revamped to allow implementation of voltage control via direct access to GPU ondie voltage controllers (e.g. AMD Fiji SMC) in addition to previously supported external voltage controllers connected to GPU via I2C bus. Please take a note that direct access to AMD SMC from multiple simultaneously running hardware monitoring applications can be unsafe and result in collisions, so similar to I2C access synchronization we introduce global namespace synchronization mutex "Access_ATI_SMC" as SMC access synchronization standard. Other developers are strongly suggested to use it during accessing AMD GPU SMC in order to provide collision free hardware monitoring.

Added low-level I2C access driver for AMD Bonaire, Curacao and Hawaii graphics processors. Low-level I2C access driver provides much faster access to I2C bus than ineffective native AMD ADL I2C access interface and addresses issues with GPU clock throttling when enabling voltage monitoring on AMD RADEON R9 290 series graphics cards

 

[Cirrus]

Nyt alkaa @Cirrus riittämään ton sun vänkäämisen kanssa, et ole tuonut pöytään yhtään mitään tukea väitteillesi, muut ovat.

Afterburner sörkkii AMD:lla I2C-väylää sekä suoraan siruilla olevia jänniteregulaattoreita (SMC) ja tietää että sen sörkkimisestä tulee helposti ongelmia.
Jos mahdollista yrittävät myös välttää AMD:n rajapinnan käyttöä ja sörkkiä suoraan sitä korttia ihan omin nokkineen.
Keksivät myös omia "standardejaan" joita odottavat muiden noudattavan.

Kyllä, se on AMD ajureiden vika ettei Afterburner toimi
Asiaan liittyviä otteita ihan suoraan Afterburnerin vanhoista muutoslogeista

Tiedätkö sinä varmaksi että ongelmakohta on joku noista? Tähän asti kukaan ei ole tuonut pöytään faktuaalista syytä kaatumisista. Toitko sinä sen nyt vai skenaarioitko tasan samalla tapaa kuin muutkin? Entäs nuo muut väitteet esim omista standardeista?

Tänne on tuotu ihan täysin puhtaita arvauksia pöytään, joilla ei ole mitään painoarvoa sen enempää kuin toisilla. Aivan täysin typerää valittaa minulle kun en keksi täällä huvikseen omassa päässäni sitä että mikähän palikka se tarkalleen ottaen syyllinen ja sen perusteella hyökkää jotakin vastaan.

Afterburner ei aivan tastusti sorki mitään jännitteitä sillä että se laitetaan päälle. Edelleenkin koita tajuta se että missään välissä ei ole väitetty että AMD on huono, koska jännitteitä ei voi sorkkia afterburnerilla. Mistään sellaisesta tämä ei ole lähtenyt tämä keskustelu.

Toki henkilökohtaisesti olen esittänyt myös mielipiteen että pidän täysin typeränä AMD:ltä jos he aktiivisesti toimivat suuntaan jossa halutaan estää/haitata/huonontaa pitkäaikaisen industry standard softan toimintaa, koska nyt on oma. Mutta samalla olen sanonut että en usko näin tapahtuneen. Lisätään vielä että etunenässä kiinostaa monitorointipuoli. Mutta ei kellotustskaan tarvisi unohtaa. Tämä on silti aivan eri keskustelu.

Ja silti tilanne on se että nvidia toimii. Se toimii suositulla softalla. AMD ei toimi. Ja AMD:kin toimi hyvin rx480 aikaan. Ja toimi se vegan aikanakin, kellotuksesta en tiedä kun en edes koittanut (Kellotus amd:n omalla). Tätä samaa toimivuutta saan kyllä aivan varmasti vaatia. Ja olen edelleen mielipiteessä että syy on AMD:n ettei se toimi. Niin kauan kun keskustelu jatkuu aiheen ympärillä ja minua sattuu kiinnostamaan, niin keskustelen siitä. Omasta mielestäni en riko tasan mitään sääntöjä. Se riittää minulle.

 

[Kaotik]

Tiedätkö sinä varmaksi että ongelmakohta on joku noista? Tähän asti kukaan ei ole tuonut pöytään faktuaalista syytä kaatumisista. Toitko sinä sen nyt vai skenaarioitko tasan samalla tapaa kuin muutkin? Entäs nuo muut väitteet esim omista standardeista?

Tänne on tuotu ihan täysin puhtaita arvauksia pöytään, joilla ei ole mitään painoarvoa sen enempää kuin toisilla. Aivan täysin typerää valittaa minulle kun en keksi täällä huvikseen omassa päässäni sitä että mikähän palikka se tarkalleen ottaen syyllinen ja sen perusteella hyökkää jotakin vastaan.

Afterburner ei aivan tastusti sorki mitään jännitteitä sillä että se laitetaan päälle. Edelleenkin koita tajuta se että missään välissä ei ole väitetty että AMD on huono, koska jännitteitä ei voi sorkkia afterburnerilla. Mistään sellaisesta tämä ei ole lähtenyt tämä keskustelu.

Toki henkilökohtaisesti olen esittänyt myös mielipiteen että pidän täysin typeränä AMD:ltä jos he aktiivisesti toimivat suuntaan jossa halutaan estää/haitata/huonontaa pitkäaikaisen industry standard softan toimintaa, koska nyt on oma. Mutta samalla olen sanonut että en usko näin tapahtuneen. Lisätään vielä että etunenässä kiinostaa monitorointipuoli. Mutta ei kellotustskaan tarvisi unohtaa. Tämä on silti aivan eri keskustelu.

Ja silti tilanne on se että nvidia toimii. Se toimii suositulla softalla. AMD ei toimi. Ja AMD:kin toimi hyvin rx480 aikaan. Ja toimi se vegan aikanakin, kellotuksesta en tiedä kun en edes koittanut (Kellotus amd:n omalla). Tätä samaa toimivuutta saan kyllä aivan varmasti vaatia. Ja olen edelleen mielipiteessä että syy on AMD:n ettei se toimi. Niin kauan kun keskustelu jatkuu aiheen ympärillä ja minua sattuu kiinnostamaan, niin keskustelen siitä. Omasta mielestäni en riko tasan mitään sääntöjä. Se riittää minulle.

Ei, tähän ketjuun ei ole tuotu vain "puhtaita arvauksia", vaan ihan oikeita perusteltuja arvauksia (koska ilman sitä lähdekoodia tai täyttä dokumentaatiota mitään muuta ei voi olla).

Afterburner sörkkii niitä sensoreita niiden väylien takana ihan pelkällä päälläolollaan lukiessaan niitä.

Afterburner ei ole mikään "Industry standard" vaan RivaTunerin päälle/pohjalta rakennettu verrattain suosittu säätösofta.

Yhden asian jankkaaminen voidaan tulkita sääntörikkeeksi (keskustelun häirintä), kun muut tuovat pöytään perusteita ja todisteita väitteidensä tueksi ja yksi ei, mutta jatkaa silti jankkaamista, se voidaan katsoa myös trollaamiseksi.

 

[Jahve3]

Kumma juttu, kun edellisillä ajuriversioilla ei ollut edes afterburneria asennettuna ja silti mustaa ruutua yms. pukkasi mukavasti. Vasta uusimmilla ajureilla on saanut nauttia toimivista kuvan näyttäjän ajureista. Ainu vika tällä hetkellä on, että Reliven instant replay ei aina toimi, mutta luulen sen johtuvan tietystä pelistä, eikä näyttäjän ajureista.

 

[bahis]

Kumma juttu, kun edellisillä ajuriversioilla ei ollut edes afterburneria asennettuna ja silti mustaa ruutua yms. pukkasi mukavasti. Vasta uusimmilla ajureilla on saanut nauttia toimivista kuvan näyttäjän ajureista. Ainu vika tällä hetkellä on, että Reliven instant replay ei aina toimi, mutta luulen sen johtuvan tietystä pelistä, eikä näyttäjän ajureista.

Folding @ home + HW acceleration bugi Vega pohjaisilla korteilla oli tiedossa oleva ongelma edellisissä ajureissa. Ei liity mitenkään Afterburner keskusteluun.

 

[t3rska]

Afterburrrrrrner onkin vain jäävuoren huippu

 

[pomk]

Tiedätkö sinä varmaksi että ongelmakohta on joku noista? Tähän asti kukaan ei ole tuonut pöytään faktuaalista syytä kaatumisista. Toitko sinä sen nyt vai skenaarioitko tasan samalla tapaa kuin muutkin? Entäs nuo muut väitteet esim omista standardeista?

Tänne on tuotu ihan täysin puhtaita arvauksia pöytään, joilla ei ole mitään painoarvoa sen enempää kuin toisilla. Aivan täysin typerää valittaa minulle kun en keksi täällä huvikseen omassa päässäni sitä että mikähän palikka se tarkalleen ottaen syyllinen ja sen perusteella hyökkää jotakin vastaan.

Afterburner ei aivan tastusti sorki mitään jännitteitä sillä että se laitetaan päälle. Edelleenkin koita tajuta se että missään välissä ei ole väitetty että AMD on huono, koska jännitteitä ei voi sorkkia afterburnerilla. Mistään sellaisesta tämä ei ole lähtenyt tämä keskustelu.

Toki henkilökohtaisesti olen esittänyt myös mielipiteen että pidän täysin typeränä AMD:ltä jos he aktiivisesti toimivat suuntaan jossa halutaan estää/haitata/huonontaa pitkäaikaisen industry standard softan toimintaa, koska nyt on oma. Mutta samalla olen sanonut että en usko näin tapahtuneen. Lisätään vielä että etunenässä kiinostaa monitorointipuoli. Mutta ei kellotustskaan tarvisi unohtaa. Tämä on silti aivan eri keskustelu.

Ja silti tilanne on se että nvidia toimii. Se toimii suositulla softalla. AMD ei toimi. Ja AMD:kin toimi hyvin rx480 aikaan. Ja toimi se vegan aikanakin, kellotuksesta en tiedä kun en edes koittanut (Kellotus amd:n omalla). Tätä samaa toimivuutta saan kyllä aivan varmasti vaatia. Ja olen edelleen mielipiteessä että syy on AMD:n ettei se toimi. Niin kauan kun keskustelu jatkuu aiheen ympärillä ja minua sattuu kiinnostamaan, niin keskustelen siitä. Omasta mielestäni en riko tasan mitään sääntöjä. Se riittää minulle.

Uusi arkkitehtuuri ja uudet ajurit, luultavasti samalla uusi i2c VHDL ja siten vanhat viritykset ei välttämättä toimi halutulla tavalla. Afterburnerin koodanneet hakkerit ei ole saaneet softaansa vakaaksi ja samaan aikaan AMD:ta ei kiinnosta penan häkkäyssoftien debuggaaminen niin lopputulos on tämä. Afterburnerin change logista löytyy vaikka mitä mainintoja siitä kun otetaan käyttöön jotain suoria kanavia komentaa grafiikkakortin i2c väyliä sen sijaan että niitä käytettäisiin AMD:n grafiikkakorttiajurien läpi, ja susta syyttää pitäis niitä ajureita jotka on mitä ilmeisimmin jo ohitettu kokonaan...

Mitään täysin varmaa syytä noihin kaatumisiin ei tietenkään ole, mutta i2c väylään liittyvät ajoitusongelmat on todella valistunut veikkaus ongelman luonteen ja afterburnerin change login perusteella ja se selittäisi myös miksi vaikkapa se HWINFO ei samalla tavalla kaada konetta. Sitä ylläpitävät tahot mm. kommunikoivat valmistajien kanssa (helppoa perustella tuen saaminen, sillä ohjelma on tunnettu ja tarkoituksena on pelkästään kerätä diagnostiikkaa grafiikkakorttien rikkomisen sijaan) ja käyttävät valmistajan suosittelemia tapoja saada halutut tiedot ajureilta. Afterburnertiimi voisi ihan hyvin ottaa HWINFO:n SDK:n käyttöön ja korjata siten koneita kaatavan softansa, mutta ilmeisesti he haluavat pitää kiinni omista virityksistään.

 

[Keketin]

Näköjään Radeon VII harrastaa flickeröintiä uusimmillakin ajureilla vielä jos on kaksi näyttöä kiinni ja yrittää katsoa vaikka videota youtubesta. RVII:n flicker-ongelma "korjattiin" toukokuussa 2019 julkaistuissa 19.5.2 ajureissa. Hienoa suorittamista!

 

[Timo 2]

Näköjään Radeon VII harrastaa flickeröintiä uusimmillakin ajureilla vielä jos on kaksi näyttöä kiinni ja yrittää katsoa vaikka videota youtubesta. RVII:n flicker-ongelma "korjattiin" toukokuussa 2019 julkaistuissa 19.5.2 ajureissa. Hienoa suorittamista!

Ihan vain kysyn jos kokeilet tuota19.5.2 ajuria, onko vielä flicker-ongelmia? On mahdollista että ne silloin korjattiin ja jokin rikkoi tuon korjauksen.

 

[Keketin]

Ihan vain kysyn jos kokeilet tuota19.5.2 ajuria, onko vielä flicker-ongelmia? On mahdollista että ne silloin korjattiin ja jokin rikkoi tuon korjauksen.

Täytyy varmaan kokeilla. Vaihtoehtona siellä on kuitenkin tarjolla:
-Rikkinäinen monitorointi
-Rikkinäinen kellotus
-Blackscreenit
-Lukuisia puuttuvia ominaisuuksia

En pidä mitenkään erityisen mielekkäänä vaihtoehtona asennella ajureita ristiin rastiin sen mukaan sattuuko tekemään mieli katsella videoita tykillä tai pelailla pelejä vain yhdellä näytöllä. Sen kuitenkin tiedän että tämä sama ongelma on myös viimeisimmillä sekä niitä edeltäneillä radeon pro ajureilla.

 

[bahis]

Näköjään Radeon VII harrastaa flickeröintiä uusimmillakin ajureilla vielä jos on kaksi näyttöä kiinni ja yrittää katsoa vaikka videota youtubesta. RVII:n flicker-ongelma "korjattiin" toukokuussa 2019 julkaistuissa 19.5.2 ajureissa. Hienoa suorittamista!

Minulla on 3 näyttöä + tykki ja ei ole koskaan millään ajurilla ollut yhtään flickeröintiä. Onko keskenään erilaiset näytöt sinulla?

Eikös joku maininnut että nykyisessä Windows versiossa on ongelmia jos on keskenään eri virkistystaajuudella olevia näyttöjä? Pitäisi korjaantua seuraavassa Windows versiopäivityksessä.

 

[t3rska]

Minulla on 3 näyttöä + tykki ja ei ole koskaan millään ajurilla ollut yhtään flickeröintiä. Onko keskenään erilaiset näytöt sinulla?

Eikös joku maininnut että nykyisessä Windows versiossa on ongelmia jos on keskenään eri virkistystaajuudella olevia näyttöjä? Pitäisi korjaantua seuraavassa Windows versiopäivityksessä.

yli 60 hertsiä ja päivitetty windows on käyttäjävika

 

[bahis]

yli 60 hertsiä ja päivitetty windows on käyttäjävika

Niin että mitenkä oli?

 

[hese_e]

yli 60 hertsiä ja päivitetty windows on käyttäjävika

Windows 10 2004 20H1 finally gets multi-monitor refresh rates right

Nähtävästi windows 10 2004 toisi tuohon korjausta.

"If you have ever used multi-monitor setups with differing refresh rates, say 144 Hz and 60 Hz, any window movement in the 60 Hz monitor meant that stuttering would be observed even in the 144 Hz display as well until the window movement is stopped. This is because the Desktop Window Manager (DWM) — the display compositing component of Windows — draws on both monitors together instead of individually compositing each display. Therefore, the monitor with the higher refresh rate gets pulled down to match the lower refresh rate monitor causing micro-stuttering and frame-skipping. "

 

[Keketin]

Onko keskenään erilaiset näytöt sinulla?

Jep. Ei ole 1440p 144hz tykkiä.

Aiheesta löytyy melko runsaasti keskustelua ympäri internettiä, mutta ei ratkaisua.

 

[bahis]

Jep. Ei ole 1440p 144hz tykkiä.

Aiheesta löytyy melko runsaasti keskustelua ympäri internettiä, mutta ei ratkaisua.

Joo hyvin taas luin sen sinun viestin

Lie ongelma sitten tuon 144hz kanssa? Minulla on 3x1440p 75hz näyttöjä + 1080p 60hz tykki.

 

[Keketin]

Joo hyvin taas luin sen sinun viestin

Lie ongelma sitten tuon 144hz kanssa? Minulla on 3x1440p 75hz näyttöjä + 1080p 60hz tykki.

En tiedä onko näissäkin osassa jotain ihan rautatasolla rikki, mutta tuntuu siltä että osalla ei auta mitkään poppaskonstit tai ajuriversiot.

r/Amd - Is anyone at AMD aware that the Radeon VII is still broken on dual monitor setups?

4,597 votes and 557 comments so far on Reddit

www.reddit.com

Radeon VII - AMD Please Fix Driver Bug - Only Working Driver 19.5.2 - Monitor Flicker/Artifacts

UPDATE: A fix that seems to work for most people is increasing core voltage or removing undervolts, especially at lower clocks. I changed to a...

old.reddit.com

 

[Osjur]

Vanhoilla ratukoilla (7970, 290x, etc) blackscreenit tuli kun korttia kellotti oikeen kunnolla. Benchit meni silti läpi vaikka mitään ei näkynyt. Paras tapa noilla oli kellotella DVI -> VGA -> näyttö kun DP oli jostain syystä aika herkkä. Kuva tuli takas kun liitti näytön korttiin uudestaan.

Aivan samanlaista blackscreen ongelmaa on myös tällä 1080ti:llä kun ei aina herää sleepistä tai voi heittää sen ihan randomisti jos taustalla rautakiihdytetty ohjelma tekemässä jotain (esim. psnow peli pyörimässä taustalla kun itse pelaan muutakin samalla). Tästäkin on päässyt eroon kytkemällä näytön uudestaan. Vanhalla Furyllä ei tätä ilmenny koskaan. DP vaan on herkempi epävakauksille vs vanhat standardit.

 

[Cirrus]

Ei, tähän ketjuun ei ole tuotu vain "puhtaita arvauksia", vaan ihan oikeita perusteltuja arvauksia (koska ilman sitä lähdekoodia tai täyttä dokumentaatiota mitään muuta ei voi olla).

Afterburner sörkkii niitä sensoreita niiden väylien takana ihan pelkällä päälläolollaan lukiessaan niitä.

Afterburner ei ole mikään "Industry standard" vaan RivaTunerin päälle/pohjalta rakennettu verrattain suosittu säätösofta.

Yhden asian jankkaaminen voidaan tulkita sääntörikkeeksi (keskustelun häirintä), kun muut tuovat pöytään perusteita ja todisteita väitteidensä tueksi ja yksi ei, mutta jatkaa silti jankkaamista, se voidaan katsoa myös trollaamiseksi.

Tulkitse aivan vapaasti miten haluat. Kun naputtelen täällä näitä, niin joudun luottamaan ihan omaan tulkintaani. Aivan puhtaita arvauksia syystä on kuitenkin tullut. Yhtään lähempänä sitä ei olla faktuaalisesti mikä kaatumista tekee oikeasti. Jos minun viestejä lainataan, niin voin suoraan kyllä luvata että jaksan vielä vastata ainakin 10 kertaa.

Kyllä minä tiedän mistä afterburner tulee ja se on juuri ”industry standard” sen takia kun se on suosittu ollut molempien valmistajien korteilla jo vuosia.

Ja olet täysin oikeassa että monitorointia menee varmasti päälle heti. Ja toki sen ymmärrän, mutta mitä sitten? Olen täysin vakuuttunut että afterburnerin koodaajat ei ole tyhmentyneet. Noiden ominasuuksien tekeminen on kuitenkin se heidän päähommansa tuossa softassa. Että nyt he ei enää tänäpäivänä osaa laittaa monitorointia pelamaan uusien amd:n kanssa. Ja vaikka ei osaisikaan, niin se että seurauksena on koneen kaatumisia on kyllä...No eipä toistella sitten.

Ja pohditaanpa vielä hetki mikä on tämä mystinen "suora i2c" josta @pomk myös juttelu mielestäni aivan mitä sattuu taas? Linkattun SDK-koodeja esimerkkinä käyttäen i2c-luvut tapahtui AMD:n, huom AMD:n, tekemien apien läpi. Näitä AMD:n koodaamia apeja hyväksi käyttäen lukuoperaatioiden ei tarvi IKINÄ kaataa konetta. AMD:llä on apien koodauksessa erittäin hyvä mahdollisuus pitää kone pystyssä vaikka mitä luettaisiin mistä tahansa osoitteesta. Tällaisten luku-apien käyttäminen EI ole missään nimessä hakkerointia. Ei sitten vähääkään. Se oli AMD:n speksaama AMD:n toimittama i2c:n käyttämiseen tarkoitettu api.

 

[tomnav]

...
Ja pohditaanpa vielä hetki mikä on tämä mystinen "suora i2c" josta @pomk myös juttelu mielestäni aivan mitä sattuu taas? Linkattun SDK-koodeja esimerkkinä käyttäen i2c-luvut tapahtui AMD:n, huom AMD:n, tekemien apien läpi. Näitä AMD:n koodaamia apeja hyväksi käyttäen lukuoperaatioiden ei tarvi IKINÄ kaataa konetta. AMD:llä on apien koodauksessa erittäin hyvä mahdollisuus pitää kone pystyssä vaikka mitä luettaisiin mistä tahansa osoitteesta. Tällaisten luku-apien käyttäminen EI ole missään nimessä hakkerointia. Ei sitten vähääkään. Se oli AMD:n speksaama AMD:n toimittama i2c:n käyttämiseen tarkoitettu api.

Hardware abstraction layer architecture has been revamped to allow implementation of voltage control via direct access to GPU ondie voltage controllers (e.g. AMD Fiji SMC) in addition to previously supported external voltage controllers connected to GPU via I2C bus. Please take a note that direct access to AMD SMC from multiple simultaneously running hardware monitoring applications can be unsafe and result in collisions, so similar to I2C access synchronization we introduce global namespace synchronization mutex "Access_ATI_SMC" as SMC access synchronization standard. Other developers are strongly suggested to use it during accessing AMD GPU SMC in order to provide collision free hardware monitoring.

Added low-level I2C access driver for AMD Bonaire, Curacao and Hawaii graphics processors. Low-level I2C access driver provides much faster access to I2C bus than ineffective native AMD ADL I2C access interface and addresses issues with GPU clock throttling when enabling voltage monitoring on AMD RADEON R9 290 series graphics cards

Kyllä tässä sun juttelu taitaa olla mitä sattuu sillä välin ku me muut "olkiukkoillaan". Aika äkkiä näköjään unohtui nuokin kaotikin lainaamat AB:n muutoslokit missä mainitaan I2C väylän käpistelystä. Ja jos AB tätä aiemmin on tehnyt, on vaieka uskoa että he navin kohdalla tyytyisi AMD:n tarjoamaan SDK:hon.

 

[Kaotik]

Tulkitse aivan vapaasti miten haluat. Kun naputtelen täällä näitä, niin joudun luottamaan ihan omaan tulkintaani. Aivan puhtaita arvauksia syystä on kuitenkin tullut. Yhtään lähempänä sitä ei olla faktuaalisesti mikä kaatumista tekee oikeasti. Jos minun viestejä lainataan, niin voin suoraan kyllä luvata että jaksan vielä vastata ainakin 10 kertaa.

Kyllä minä tiedän mistä afterburner tulee ja se on juuri ”industry standard” sen takia kun se on suosittu ollut molempien valmistajien korteilla jo vuosia.

Ja olet täysin oikeassa että monitorointia menee varmasti päälle heti. Ja toki sen ymmärrän, mutta mitä sitten? Olen täysin vakuuttunut että afterburnerin koodaajat ei ole tyhmentyneet. Noiden ominasuuksien tekeminen on kuitenkin se heidän päähommansa tuossa softassa. Että nyt he ei enää tänäpäivänä osaa laittaa monitorointia pelamaan uusien amd:n kanssa. Ja vaikka ei osaisikaan, niin se että seurauksena on koneen kaatumisia on kyllä...No eipä toistella sitten.

Ja pohditaanpa vielä hetki mikä on tämä mystinen "suora i2c" josta @pomk myös juttelu mielestäni aivan mitä sattuu taas? Linkattun SDK-koodeja esimerkkinä käyttäen i2c-luvut tapahtui AMD:n, huom AMD:n, tekemien apien läpi. Näitä AMD:n koodaamia apeja hyväksi käyttäen lukuoperaatioiden ei tarvi IKINÄ kaataa konetta. AMD:llä on apien koodauksessa erittäin hyvä mahdollisuus pitää kone pystyssä vaikka mitä luettaisiin mistä tahansa osoitteesta. Tällaisten luku-apien käyttäminen EI ole missään nimessä hakkerointia. Ei sitten vähääkään. Se oli AMD:n speksaama AMD:n toimittama i2c:n käyttämiseen tarkoitettu api.

Ei, ne eivät ole "puhtaita arvauksia", ei ainakaan kaikkien käyttäjien osalta, ja "puhdas arvauskin" on ihan eri asia kun se perustellaan pitävästi.

Se ei ole millään tasolla "industry standard" vain koska joukko loppukäyttäjiä suosii sitä (ja se joukkokin on vain pieni pisara meressä kun puhutaan tietokoneiden käyttäjistä)

Niin, siis niin AMD haluaisi että heidän korttien I2C-väylää sörkitään.
Sen sijasta ainakin osalle korteista Afterburnerin kehittäjät ovat luoneet oman ajurinsa, joka ohittaa AMD:n rajapinnat, kuten aiemmassa viestissäni todettiin Afterburnerin muutoslogin lainauksessa.
Lisäksi siihen on lisätty tuki ainakin osalle siruista suora linja sirun sisäisiin jänniteregulaattoreihin, mikä on eri kuin I2C-väylän päässä olevat jänniteregulaattorit.

edit:
Huomauttaisin myös, että kun puhuit todistustaakoista tuossa aiemmin, niin sinä et ole tuonut pöytään mitään omien väitteidesi tueksi. Esimerkiksi sen puolesta, miten I2C-väylän avulla voidaan aiheuttaa ongelmia, on tuotu.

 

[Cirrus]

Ei, ne eivät ole "puhtaita arvauksia", ei ainakaan kaikkien käyttäjien osalta, ja "puhdas arvauskin" on ihan eri asia kun se perustellaan pitävästi.

Se ei ole millään tasolla "industry standard" vain koska joukko loppukäyttäjiä suosii sitä (ja se joukkokin on vain pieni pisara meressä kun puhutaan tietokoneiden käyttäjistä)

Niin, siis niin AMD haluaisi että heidän korttien I2C-väylää sörkitään.
Sen sijasta ainakin osalle korteista Afterburnerin kehittäjät ovat luoneet oman ajurinsa, joka ohittaa AMD:n rajapinnat, kuten aiemmassa viestissäni todettiin Afterburnerin muutoslogin lainauksessa.
Lisäksi siihen on lisätty tuki ainakin osalle siruista suora linja sirun sisäisiin jänniteregulaattoreihin, mikä on eri kuin I2C-väylän päässä olevat jänniteregulaattorit.

edit:
Huomauttaisin myös, että kun puhuit todistustaakoista tuossa aiemmin, niin sinä et ole tuonut pöytään mitään omien väitteidesi tueksi. Esimerkiksi sen puolesta, miten I2C-väylän avulla voidaan aiheuttaa ongelmia, on tuotu.

Huomauttaisin sen että on täysin merkityksentä keksiä omassa päässä skenaario jossa jänniteregulaattorin suoraohjaus voi aiheuttaa ongelman, mutta mitään todistetta/viitettä/vinkkiä, eli arvausta kummempaa, ei ole siitä että jänniteregulaattorin suoraohjaus on se syyllinen. Tai että afterburner sorkkii sitä aina päällä ollessan tai mitään. Iso kasa oletuksia ennen syytä on ihan puhdas arvaus vaikka oletusketjun loppupäässä olisi jotain oikeaan viittavaa. Nyt esimerkiksi tässä keskustelussa ja muutoslogi -jorinoissa oletat että jänniteregulaattoireilla on asiaan joku osuus. Tätä käsiteltiin jo siinä että onko olemassa joku syy että jänniteregulaattorit luettaisiin tai kirjoitettaisiin aina heti uusiksi? Lukeminen olisi toki todennäköisempää kuin kirjoittaminen. Lukemisella asioiden sekoittaminen on vain paljon vaikeampaa. Skenaarioimalla omassa päässä täysin arvailupohjaisesti, niin jos afterburner lukee ne heti ja jos afterburner voi käyttää siihen TÄYSIN omaa koodiansa ja käyttääkin sitä ja jos se sen oman koodin ajuri päätyy estämään kaikkien muiden lukuoperaatiot (amd:n omat), niin sitten siitä toki oltaisin afterburnerin aiheuttamissa ongelmissa. Huomaatko kuinka monta "jos" sanaa tuohon piti kirjoittaa? Tuollainen skenaario on täysin puhdas arvaus vaikka se kaikkien lukujen estäminen on hyvä teoreettinen syy johonkin. Siltikään ei seuraus ole täysin pakollinen crash ainakaan sen afterburnerin tekemänä. Se crashaaja on joku muu.

"Industry standard" lainausmerkeissä se nimenomaan on, joita sinä sopivasti käytitkin. Ei välttämättä ilman niitä oikeassa merkityksessä. Mutta tästä väittely ei ole sen kummemin hedelmällistä tai hauskaa. Jäämme myös erimielisyteen pieni pisara meressä -kokoluokasta ja tärkeydestä. Hirmuisen moni PC-komponentti tarjoaa ison kasan tietoja omien ja ulkopuolisten softien kautta. Jos kyseessä olisi pieni pisara meressä, niin mitään tällaista ei olisi olemassakaan.

En ole keksinyt/väittänyt/kertonut mitään tarkkaa syyllistä asialle. En siis voi mitenkään todistaa mitään tarkkaa kun en edes väitä sellaista. Ja täysin päivän selvästi olen kirjoittanut että jos voisin todistaa yleiseluontosien väitteen "AMD on syyllinen, ei afterburber", olisin tehnyt sen jo ajat sitten. Miksi siis edes jankutat tästä asiasta mitään? Toki olen sitä perustellut miksi ajattelen noin, mutta ei se ole perustelu että asia 100% on niin.

 

[Mechanical Man]

Tulkitse aivan vapaasti miten haluat. Kun naputtelen täällä näitä, niin joudun luottamaan ihan omaan tulkintaani. Aivan puhtaita arvauksia syystä on kuitenkin tullut. Yhtään lähempänä sitä ei olla faktuaalisesti mikä kaatumista tekee oikeasti. Jos minun viestejä lainataan, niin voin suoraan kyllä luvata että jaksan vielä vastata ainakin 10 kertaa.

Kyllä minä tiedän mistä afterburner tulee ja se on juuri ”industry standard” sen takia kun se on suosittu ollut molempien valmistajien korteilla jo vuosia.

Ja olet täysin oikeassa että monitorointia menee varmasti päälle heti. Ja toki sen ymmärrän, mutta mitä sitten? Olen täysin vakuuttunut että afterburnerin koodaajat ei ole tyhmentyneet. Noiden ominasuuksien tekeminen on kuitenkin se heidän päähommansa tuossa softassa. Että nyt he ei enää tänäpäivänä osaa laittaa monitorointia pelamaan uusien amd:n kanssa. Ja vaikka ei osaisikaan, niin se että seurauksena on koneen kaatumisia on kyllä...No eipä toistella sitten.

Ja pohditaanpa vielä hetki mikä on tämä mystinen "suora i2c" josta @pomk myös juttelu mielestäni aivan mitä sattuu taas? Linkattun SDK-koodeja esimerkkinä käyttäen i2c-luvut tapahtui AMD:n, huom AMD:n, tekemien apien läpi. Näitä AMD:n koodaamia apeja hyväksi käyttäen lukuoperaatioiden ei tarvi IKINÄ kaataa konetta. AMD:llä on apien koodauksessa erittäin hyvä mahdollisuus pitää kone pystyssä vaikka mitä luettaisiin mistä tahansa osoitteesta. Tällaisten luku-apien käyttäminen EI ole missään nimessä hakkerointia. Ei sitten vähääkään. Se oli AMD:n speksaama AMD:n toimittama i2c:n käyttämiseen tarkoitettu api.

Juuri sulle on suoria lainauksia näytetty, että nimenomaan EI käytä AMD:n apia vaan sorkkiin sen ohi. Jos ei edes se uppoa, niin ei mikään ihme, ettet muutakaan ymmärrä. Voisit poistua trollaamaan vaikka muroon.

 

[Cirrus]

Kyllä tässä sun juttelu taitaa olla mitä sattuu sillä välin ku me muut "olkiukkoillaan". Aika äkkiä näköjään unohtui nuokin kaotikin lainaamat AB:n muutoslokit missä mainitaan I2C väylän käpistelystä. Ja jos AB tätä aiemmin on tehnyt, on vaieka uskoa että he navin kohdalla tyytyisi AMD:n tarjoamaan SDK:hon.

Ja taas oletetaan kasa kaikkea. Mitä tuo low level i2c-access tarkoittaa? Täysin omaa ajuria omalla koodilla? Vai SDK:n tukemaa ajuria jossa luku ja kirjoitus-osoitteet pääsee valitsemaan. Sellaisen käyttäminen täyttäisi kaikki kerrotut kohdat. Se voi olla tehokkaampaa kuin yksittäisten API:n käyttämien samalle tietojoukkolle. Ja ajuria joissa käyttäjä päättää osoitteet, nopeuden ja mitä muuta siellä nyt olikaan apissa, voidaan sanoa kyllä rehellisesti low level ajuriki.

Ja jos mennäänkin oletuksella että kyseessä on täysin suora ajuri, niin sehän osoittaa siinä tapauksessa että koodaajilla on kokemusta tuollaisista asiosta ja vanhemmilla mainituilla AMD:n tuotteilla.

Ja jos edelleen väitetään tätä juuri kaatumisen syyksi, niin pitää olettaa taas iso kasa lisää. Kts edellinen viesti.

 

[Kaotik]

@Cirrus siinä ihan suorassa lainauksessa sanotaan ihan täysin suoraan että se ohittaa AMD:n rajapinnat, ei se ole noin vaikeaa. Sama juttu SMC:n kanssa. Ja vielä kaiken muun päälle erikseen alleviivaavat että noiden sörkkimisestä voi tulla ongelmia etenkin jos useampi sovellus on samalla asialla.
On se kumma kun edes Afterburnerin tekijät sanomassa saman asian ei riitä.

 

[tomnav]

Ja taas oletetaan kasa kaikkea. Mitä tuo low level i2c-access tarkoittaa? Täysin omaa ajuria omalla koodilla? Vai SDK:n tukemaa ajuria jossa luku ja kirjoitus-osoitteet pääsee valitsemaan. Sellaisen käyttäminen täyttäisi kaikki kerrotut kohdat. Se voi olla tehokkaampaa kuin yksittäisten API:n käyttämien samalle tietojoukkolle. Ja ajuria joissa käyttäjä päättää osoitteet, nopeuden ja mitä muuta siellä nyt olikaan apissa, voidaan sanoa kyllä rehellisesti low level ajuriki.

Ja jos mennäänkin oletuksella että kyseessä on täysin suora ajuri, niin sehän osoittaa siinä tapauksessa että koodaajilla on kokemusta tuollaisista asiosta ja vanhemmilla mainituilla AMD:n tuotteilla.

Ja jos edelleen väitetään tätä juuri kaatumisen syyksi, niin pitää olettaa taas iso kasa lisää. Kts edellinen viesti.

Oletuksiahan nämä kaikki on. Mitä tätä keskustelua nyt muutamat viime sivut seuraillut, niin muut tuovat näille oletuksilleen jonkin näköisiä perusteita. Tämä sitten sinun mielestä on olkiukkoilua ja skenaarioilla leikkimistä. Skenaario asiassa olet tietysti oikeassa. Kenelläkään kun ei taida AB:n sorsaa olla käsillä.

Itse näkisin low level I2C accessin tarkoittavan osoitteilla tapahtuvaa käpistelyä. Toisin sanoin sinne väylään ajetaan bittejä ja toivotaan oikean slaven vastaavan halutulla tavalla. Ja jos kaikki ei mene niinkuin strömsössä voi muunmuassa I2C standardin mukaisesti slave venyttää siirtokellon jaksoa x ajan, koska timeouttia ei ole. Tässähän vaiheessa soppa on todennäköisesti jo valmis ja AMD:n ajurit kippaa.

Toki tämäkin on taas vain yksi skenaario. Mutta kerran nämä on täysin vääriä ja hyödyttömiä pystyt varmaan kertomaan miksei näin voisi tapahtua?

 

[Cirrus]

Oletuksiahan nämä kaikki on. Mitä tätä keskustelua nyt muutamat viime sivut seuraillut, niin muut tuovat näille oletuksilleen jonkin näköisiä perusteita. Tämä sitten sinun mielestä on olkiukkoilua ja skenaarioilla leikkimistä. Skenaario asiassa olet tietysti oikeassa. Kenelläkään kun ei taida AB:n sorsaa olla käsillä.

Itse näkisin low level I2C accessin tarkoittavan osoitteilla tapahtuvaa käpistelyä. Toisin sanoin sinne väylään ajetaan bittejä ja toivotaan oikean slaven vastaavan halutulla tavalla. Ja jos kaikki ei mene niinkuin strömsössä voi muunmuassa I2C standardin mukaisesti slave venyttää siirtokellon jaksoa x ajan, koska timeouttia ei ole. Tässähän vaiheessa soppa on todennäköisesti jo valmis ja AMD:n ajurit kippaa.

Toki tämäkin on taas vain yksi skenaario. Mutta kerran nämä on täyttä paskaa pystyt varmaan kertomaan miksei näin voisi tapahtua?

Skenaarioidaan nyt sitten: Näkemyksesi kaltaisen osoitepohjaisen accessin tarjosi AMD i2c-väyliin SDK:ssansa omalla heidän API:llansa. Luvun tai kirjoituksen epäonnistuessa kuvaamallasi tavalla (väylässä itsessään ei ole timeouttia). Kyseinen ajuri voi hyvin kuitenkin timeoutata ja lähettää masterille "bus clear" -komennon jolloin seuraavat luvut onnistuisivat jälleen. Käsittääkseni bus clearin osaaminen on masterille pakollista. En jaksanut kuitenkaan tarkistaa tätä nyt tätä varten. Koitan etsiä jos haluat. Tätä vasten pakollista nurinmeno ei olisi. Tätäkin toki voitaisiin skenaarioida vielä lisää että mitä jos slave puoli ei osakaan bus clearia. OK sitten olisi power cycle jäljellä ja jos tätä keinoa ei olekaan. Jos siinä tapauksessa ainoa vaihtoehto on kaatuminen.

Sen sijaan jos skenaarioidaan juuri samaa kuin tuolla jossain aiemmassa viestissä että jos low level ajuri on afterburnerin oma joka estää täysin kaiken muun tekemisen, myös AMD:n omat jutut, ja jos ja jos pari muuta juttua, niin sitten ehkä AMD:n ajurin kaatuminen olisi paikallaan...

 

[Kaotik]

Skenaarioidaan nyt sitten: Näkemyksesi kaltaisen osoitepohjaisen accessin tarjosi AMD i2c-väyliin SDK:ssansa omalla heidän API:llansa. Luvun tai kirjoituksen epäonnistuessa kuvaamallasi tavalla (väylässä itsessään ei ole timeouttia). Kyseinen ajuri voi hyvin kuitenkin timeoutata ja lähettää masterille "bus clear" -komennon jolloin seuraavat luvut onnistuisivat jälleen. Käsittääkseni bus clearin osaaminen on masterille pakollista. En jaksanut kuitenkaan tarkistaa tätä nyt tätä varten. Koitan etsiä jos haluat. Tätä vasten pakollista nurinmeno ei olisi. Tätäkin toki voitaisiin skenaarioida vielä lisää että mitä jos slave puoli ei osakaan bus clearia. OK sitten olisi power cycle jäljellä ja jos tätä keinoa ei olekaan. Jos siinä tapauksessa ainoa vaihtoehto on kaatuminen.

Sen sijaan jos skenaarioidaan juuri samaa kuin tuolla jossain aiemmassa viestissä että jos low level ajuri on afterburnerin oma joka estää täysin kaiken muun tekemisen, myös AMD:n omat jutut, ja jos ja jos pari muuta juttua, niin sitten ehkä AMD:n ajurin kaatuminen olisi paikallaan...

Edellen Afterburner ohittaa kyseisen AMD:n tarjoaman rajapinnan ainakin osalla korteista, siitä on ihan suora lainaus tuossa yllä.
Ainut kysymys on mitä kaikkia näytönohjaimia se koskee, koska sama tuki mikä erikseen lisättiin muutoslogissa mainittuihin malleihin voi sisältyä valmiiksi jokaisen sen jälkeen lisättyyn siruun.

 

[pomk]

En ole keksinyt/väittänyt/kertonut mitään tarkkaa syyllistä asialle.

Eli mielestäsi AMD:n tuotteissa ei ole vikaa, kerran et kehtaa väittää niitä syyllisiksi mistään. Hyvä tietää.

1. HWINFO ei kaada konetta ja osaa monitoroida korttien tietoja.
2. AMD:n oma softa ei kaada konetta ja osaa monitoroida korttien tietoja.
3. Afterburner kaataa koneen yrittäessään monitoroida korttien tietoja.

Nyt kymmenen pisteen kysymys:
Missä on vika?

 

[Osjur]

Ei hyvää päivää tätä keskustelua, AMD toi SMC:n muistaakseni Furyssä joka ohjaa kelloja, voltteja ja virranantoa ym. Samalla se monitoroi koko paskaa joka tekee tuosta I2C väylästä helvetin kiireisen, ottaen huomioon että se väylä on aika rajallinen. Ja nämä I2C rekisteriosoitteet muuttuvut jatkuvalla syötöllä kun uusia malleja (jopa customeita samasta mallista) julkaistaan. Afterburner nuuskii tietoa suoraan I2C väylästä ohittaen koko SMC:n joten jos siellä tulee ristiriitaisuus tai dataa haetaan/kirjoitetaan samasta kohtaa samaan aikaan (master - slave), se data onkin yhtäkkiä lukukelvotonta, niin ainoa keino jolla SMC voi puolustautua tätä vastaan on heittämällä itsensä virhetilaan mikä johtaa black screeniin, kellojen lukittumisen idlekelloihin, tuuletin 100%, etc. Siinä on ihan syy miksi unwinderillä (afterburrner kehittäjä) meni kohtuu kauan saada Furyn kellotus toimimaan kun I2C oli yhtäkkiä pirun kiireinen ja näissä uudemmissa se on vielä enemmän kiireisempi.

AMD voisi halutessa siirtyä Nvidian ratkaisuun jossa I2C ei edes ole pääsyä (tai koko väylää ei ole kun käyttävät PWMVID / SMBUS pascaleista lähtien) ja bios lukkoon jolloin kaikki hoidetaan NVSMI kautta ja tämän takia pascaleiden ja uudempien power limit rajoituksia ei voi ohittaa muuta kuin shunt modilla. AMD:llä taas on vrmtool, morepowertool ym. jolla pääsee puukottaa i2c rekisteriosoitteita suoraan jolloin sille regulle tai controllerille voi sanoa että anna mulle kaikki virta mitä susta lähtee. Lähes kaikki 3rd party softat leikkivät tuon väylän kanssa AMD korteilla kun ADL Api on susi ja tästä uudesta Driver - > SMC ohjausapista ei taida tietoa oikeen löytyä mistään.

 

[tomnav]

Skenaarioidaan nyt sitten: Näkemyksesi kaltaisen osoitepohjaisen accessin tarjosi AMD i2c-väyliin SDK:ssansa omalla heidän API:llansa. Luvun tai kirjoituksen epäonnistuessa kuvaamallasi tavalla (väylässä itsessään ei ole timeouttia). Kyseinen ajuri voi hyvin kuitenkin timeoutata ja lähettää masterille "bus clear" -komennon jolloin seuraavat luvut onnistuisivat jälleen. Käsittääkseni bus clearin osaaminen on masterille pakollista. En jaksanut kuitenkaan tarkistaa tätä nyt tätä varten. Koitan etsiä jos haluat. Tätä vasten pakollista nurinmeno ei olisi. Tätäkin toki voitaisiin skenaarioida vielä lisää että mitä jos slave puoli ei osakaan bus clearia. OK sitten olisi power cycle jäljellä ja jos tätä keinoa ei olekaan. Jos siinä tapauksessa ainoa vaihtoehto on kaatuminen.

Sen sijaan jos skenaarioidaan juuri samaa kuin tuolla jossain aiemmassa viestissä että jos low level ajuri on afterburnerin oma joka estää täysin kaiken muun tekemisen, myös AMD:n omat jutut, ja jos ja jos pari muuta juttua, niin sitten ehkä AMD:n ajurin kaatuminen olisi paikallaan...

Nyt tulee vastaus tähän vähän myöhässä... I2C ei ole mulle se vahvin juttu, mutta käsittääkseni mitään "bus clear" standardia ei ole. Väylää putsataan tietyissä tapauksissa clock cyclellä leikkimällä, mutta tämä ei käsittääkseni toimi jos slave vetää sda:n tai scl:n alas? En muista kumpi tässä oli se "avain". Silloin tulee kyseeseen tuo power cycle, mutta onko se mahdollista tehdä niin että kone pysyy pystyssä?

Mielenkiinnolla kuuntelen jos sulla on tarkemmin tietoa tästä. Kuten sanoin niin I2C ei ole sitä tutuinta aluetta, mutta sen kipukohtia on jonkinverran tiedossa ja sitä on jonkinverran käytetty. Ei kuitenkaan sillä tasolla millä nämä softat sitä käpistelee.

Ja tosiaan koko väittelyhän on tässä vaiheessa skenaarioilla leikkimistä, mutta tällein ohjelmoinnista jotain tietävänä olisi mielenkiintoista kuulla ihan softa puolelta edes niitä skenaarioita mikä siellä saattaisi mättää.

 

[JiiPee]

Hirmuisen moni PC-komponentti tarjoaa ison kasan tietoja omien ja ulkopuolisten softien kautta. Jos kyseessä olisi pieni pisara meressä, niin mitään tällaista ei olisi olemassakaan.

Oletko miettinyt että se hirmuinen määrä telemetria tietoa on tarkoitettu ajureiden sisäiseen käyttöön ensisijaisesti jotta esim. turbo ominaisuus saadaan toimimaan oikein? Se että niitä tietoja voidaan ronkkia ajureitten ohi, ei tarkoita että niin kannattaisi tehdä.
Eli se iso kasa tietoa ei välttämättä ole tarkoitettu siihen että Jorma voi sovelluksella 1337clock.exe kytätä kaikkia mahdollisia arvoja.

 

[Kaotik]

Hirmuisen moni PC-komponentti tarjoaa ison kasan tietoja omien ja ulkopuolisten softien kautta. Jos kyseessä olisi pieni pisara meressä, niin mitään tällaista ei olisi olemassakaan.

Oletko miettinyt että se hirmuinen määrä telemetria tietoa on tarkoitettu ajureiden sisäiseen käyttöön ensisijaisesti jotta esim. turbo ominaisuus saadaan toimimaan oikein? Se että niitä tietoja voidaan ronkkia ajureitten ohi, ei tarkoita että niin kannattaisi tehdä.
Eli se iso kasa tietoa ei välttämättä ole tarkoitettu siihen että Jorma voi sovelluksella 1337clock.exe kytätä kaikkia mahdollisia arvoja.

Puhumattakaan siitä että ihan ne valmistajat itse tarvitsevat raudan kehitystyössä sitä dataa, samoin kuin esimerkiksi OEM-valmistajat, kehitysstudiot jne.
Ja kun se keino saada dataa ulos on siellä kuitenkin, tulee myös sovelluksia jotka sitä dataa tulkkaavat käyttäjän silmille sopivaan muotoon, sekä ohjelmia jotka on suunniteltu säätämään korttia asetuksille, joilla sitä ei ole suunniteltu toimivaksi (tarkoituksella vähän alleviivaavasti, mutta tästähän siinä on kyse kun kellotetaan, säädetään tuuletinprofiileja, voltteja ja niin edelleen).
Se määrä käyttäjiä, jotka ihan oikeasti lataavat vaikka MSI Afterburnerin, HWiNFOn tai muun monitorointi tai säätösoftan on kuitenkin hyvin pieni pisara meressä, käytännössä vain ns. alan oikeat harrastajat ja ehkä viimevuosina vähän yleistyen pelaajien ja striimaajien keskuudessa, mutta ei missään nimessä niin paljoa että sitä yleiseksi lähtisi kutsumaan. Foorumit antavat aika tavalla vääristyneen kuvan niiden suosiosta juuri siksi, että näillä foorumeilla viihtyvät pääasiassa alan harrastajat.

 

[smaragdi]

Pitäisikö tässä uskoa että vika on afterburnerissa! Entä muut random ohjelmat, selaimet ja pelit joissa navit kippailee?

 

[pomk]

Pitäisikö tässä uskoa että vika on afterburnerissa! Entä muut random ohjelmat, selaimet ja pelit joissa navit kippailee?

Laitappa lista, niin kerron. Vinkkinä että jos ne ei mene AMD:n ajurin ohi sekoilemaan omiaan, niin kyseessä tuskin on ohjelman vika.

 

[smaragdi]

Laitappa lista, niin kerron. Vinkkinä että jos ne ei mene AMD:n ajurin ohi sekoilemaan omiaan, niin kyseessä tuskin on ohjelman vika.

Amd tekemässä kyselyssä oli n kohtaa ongelmia aiheuttavista tilanteista. Joillakin ei ole ollut (omien sanojensa mukaan) mitään ongelmia tai ehkä heillä on poikkeuksellisen hyvin kehittynyt sietokyky. Toisaalta amd:n tutkinnan ja korjauksen alla olevista ongelmista voi päätellä että joillekin, ei niin vikasietoisille käyttäjille on osunut epävakaa tai moniongelmainen yksilö. Toivoa vain sopii että uusimmilla ajureilla lähes vuoden myynnissä olleilla tuotteilla suurin osa koneen kaatavista tilanteista on jäänyt historiaan.

AMD Is Asking Owners Of Radeon RX 5700 Series Cards To Fill Out A Survey To Troubleshoot Black Screen Issue

Over on Reddit, a product manager at AMD asked users who are affected by the issue to fill out a survey to narrow down the culprit, and hopefully fix the issue once and for all.