• Live: io-techin Tekniikkapodcast tänään perjantaina noin klo 15:00 alkaen. Keskustellaan viikon mielenkiintoisimmista tietotekniikka- ja mobiiliaiheista. Suora lähetys YouTubessa. Tule mukaan katselemaan ja keskustelemaan! Linkki lähetykseen >>

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

  • Keskustelun aloittaja Keskustelun aloittaja Sampsa
  • Aloitettu Aloitettu
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.
 
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ä.
 
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
 
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. "
 
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 :facepalm:

Lie ongelma sitten tuon 144hz kanssa? Minulla on 3x1440p 75hz näyttöjä + 1080p 60hz tykki.
 
Joo hyvin taas luin sen sinun viestin :facepalm:

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.
 
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.
 
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.
 
...
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.
 
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.
 
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.
 
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.
 
Jatkuvaa vänkäystä, muiden käyttäjien perustellut väiteet sivuutetaan toistuvasti
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.
 
@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ä.
 
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?
 
Viimeksi muokattu:
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...
 
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.
 
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?
 
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.
 
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ää.
 
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.
 
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.
 
Pitäisikö tässä uskoa että vika on afterburnerissa! Entä muut random ohjelmat, selaimet ja pelit joissa navit kippailee?
 
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.
 
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.

AMD Survey
 
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.

AMD Survey

Ei siinä ole n kohtaa ongelmia aiheuttavia tilanteita vaan potentiaalisia tilanteita joilla voidaan sulkea pois tilanteita. Jos esim. suurin osa vastaa browser only, niin silloin ongelma on hardware kiihotuksessa. Jos taas gaming only, niin silloin ongelma on 3D grafiikan luonnin puolella. jne. Eli mielestänio melko hyvin aseteltuja vaihtoehtoja joilla pystytään paremmin kohdentamaan ongelma.
 
Kyselyn tulokset on julkaistu

 
Jotenkin absurdia ollut vääntö täällä kun peilaa siihen, että ihan hyvin toi Afterburneri tuntuu toimivan Navilla.
 
Jotenkin absurdia ollut vääntö täällä kun peilaa siihen, että ihan hyvin toi Afterburneri tuntuu toimivan Navilla.

No eipä itselläni toiminut, että absurdi vääntö tosijjaa

Ohjasi tuuletinta ihan väärään lämpötilan mukaan, joka aiheutti throtlailua
 
No eipä itselläni toiminut, että absurdi vääntö tosijjaa

Ohjasi tuuletinta ihan väärään lämpötilan mukaan, joka aiheutti throtlailua
Ei toiminut vai ei toimi? Siinä on aika iso ero. Lisäksi minä varsin selvästi ilmaisin, että "tuntuu toimivan" ymmärrätkö subjektiivinen mielipide.
Näyttää täysin samoja lämpöjä kuin radeon software.
 
Ei toiminut vai ei toimi? Siinä on aika iso ero.

Ei toiminut sunnuntaina (tai oisko ollut launataina) kun testasin takuusta palaneen kortin. Luulin, että on edelleen paskana, mutta afterburner paljastuikin ongelmaksi.

Lisäksi minä varsin selvästi ilmaisin, että "tuntuu toimivan" ymmärrätkö subjektiivinen mielipide.
Näyttää täysin samoja lämpöjä kuin radeon software.

Yhden henkilön subjektiivinen mielipide/kokemus ei tee täällä olleesta väännöstä absurdia.
Jos tekisi, niin koska ne yhdet nvidian ajurit eivät aikanaan polttaneet kaikkia 8800-sarjan kortteja, niin niistä varoittelu olisi ollut absurdia...
 
Ei toiminut sunnuntaina (tai oisko ollut launataina) kun testasin takuusta palaneen kortin. Luulin, että on edelleen paskana, mutta afterburner paljastuikin ongelmaksi.

Yhden henkilön subjektiivinen mielipide/kokemus ei tee täällä olleesta väännöstä absurdia.
Jos tekisi, niin koska ne yhdet nvidian ajurit eivät aikanaan polttaneet kaikkia 8800-sarjan kortteja, niin niistä varoittelu olisi ollut absurdia...
On se jännä miten koko keskustelu alkoi täällä "luin internetistä" tyylisesti ja nyt se jatkuu samalla linjalla.
Tossa mun. Olisko sulla näyttää vastaavaa?
Väite oli, että kaataa koneen ja muuta vastaavaa. Ei ole kaatunut vielä kone Afterburnerin takia.
 

Liitteet

  • samat luvut.JPG
    samat luvut.JPG
    124,5 KB · Luettu: 45
Kertoo miten järjetön 2080ti:n hinta on.
218% kalliimpi (siis kolme kertaa kalliimpi) kuin 5700xt ja saat... *drumroll* 21% lisää tehoa (1080p). Tai 34% Techpowerupin mukaan.
E: Hinnat hinta.fi halvimmat

2080 Ti:n hinnassahan nyt on poskettomasti ilmaa, ei kai sitä kukaan kiellä. Mutta on aivan naurettavaa Katella joitain 1080p tuloksia ko. kortin kohdalla, kun joka ikinen peli on prossurajoitteinen tuolla resolla, jos näyttiksenä on 2080 Ti.
 
2080 Ti:n hinnassahan nyt on poskettomasti ilmaa, ei kai sitä kukaan kiellä. Mutta on aivan naurettavaa Katella joitain 1080p tuloksia ko. kortin kohdalla, kun joka ikinen peli on prossurajoitteinen tuolla resolla, jos näyttiksenä on 2080 Ti.

1440p: 40%
2160p: 50%

Myönnän, että 4K-resolla alkaa tuntumaan 50% FPS:ssä mutta suolanen on hinta silti. Valitettavasti ei ole kilpailua niin ei ole tuolla kärkiluokassa.
 
Valitettavasti 2080 Ti on myös ainoa kortti, jolla 4K-pelaamista voisi edes kuvitella. Silläkin tekee tiukkaa. Jos siis halutaan se 60fps.
 
Valitettavasti 2080 Ti on myös ainoa kortti, jolla 4K-pelaamista voisi edes kuvitella. Silläkin tekee tiukkaa. Jos siis halutaan se 60fps.

Hmm nopeasti selailin TPU:n testejä, niin 2080 päästään avg. 60 fps aika monessa pelissä parhaimmilla asetuksilla. Ei se nyt ihan noin siis ole?
 
Valitettavasti 2080 Ti on myös ainoa kortti, jolla 4K-pelaamista voisi edes kuvitella. Silläkin tekee tiukkaa. Jos siis halutaan se 60fps.
Vain jos on pakko laittaa kaikki asetukset ultralle.

Samoin kuten näyttisten hinta/tehosuhde huonontuu sinne kärkipäähän siirrettyessä, myös pelien graafisen laatuparannuksen ja laskentatehovaatimuksen suhde heikkenee kun siirrytään kohti ultra-asetuksia.
 
Tarkoitin 60fps minimiä. Taloudessa on 2070S ja 2080 kiinni 4K-telkkareissa, ja tyypillisesti reson pitää olla jossain 60-80% 4K:sta ja silloinkin ultra asetukset voi unohtaa.

Viimeaikaisia kokemuksia:

Control ei jaksanut pyöriä 1080p RTX päällä jatkuvaa 60fps 2080:llä. Ilman RTX jaksoi 2560x1440 jos karsi muutaman asetuksen mediumiin. Mechwarrior 5 jaksaa sen 2560x1440 jos karsii vähän asetuksia. RDR2 ei jaksa edes 1080p asetukset tapissa, vaikka MSAA:ta ei käytäkään. XBOX asetuksilla jaksaa 2560x1440 tai vähän korkeampaakin. Total War Warhammer pyörii ~3k tienoilla olevalla resolla, kun karsii asetuksia medium-high haarukkaan. 4K:sta ei toivoakaan minkään näiden kohdalla vaikka asetukset vetäisi pohjamutiin.
 
Viimeksi muokattu:
Kertoo miten järjetön 2080ti:n hinta on.
218% kalliimpi (siis kolme kertaa kalliimpi) kuin 5700xt ja saat... *drumroll* 21% lisää tehoa (1080p). Tai 34% Techpowerupin mukaan.
E: Hinnat hinta.fi halvimmat
2080Ti ja 1080p typerää vertailua kun prossut ei pysy mukana ja muutenkin 2080Ti on parhaimmilaan 1440p/4K jossa tarvitaan vääntöä.

Pelailee 1080p näyttöllä ja omistaa yli 1000e näyttönohjaimen just just :rofl2:
Se on mahtavaa kun kannattaa tarpeeksi jotain niin haetaan jotain typeriä vertailuja ja tilanteita että se ohjain/merkki jota kannattaa ei näyttäisi niin paskalta.

5700XT on täyttä paskaa 4K.lla! Tuolla 2080Ti nyt vielä menee ja pärjää kohtuullisesti mutta enempikin saisi olla vääntöä. sellaiset +40% lisää niin alkaisi jo 4K pelailua maistua.
 
2080Ti ja 1080p typerää vertailua kun prossut ei pysy mukana ja muutenkin 2080Ti on parhaimmilaan 1440p/4K jossa tarvitaan vääntöä.

Pelailee 1080p näyttöllä ja omistaa yli 1000e näyttönohjaimen just just :rofl2:
Se on mahtavaa kun kannattaa tarpeeksi jotain niin haetaan jotain typeriä vertailuja ja tilanteita että se ohjain/merkki jota kannattaa ei näyttäisi niin paskalta.

5700XT on täyttä paskaa 4K.lla! Tuolla 2080Ti nyt vielä menee ja pärjää kohtuullisesti mutta enempikin saisi olla vääntöä. sellaiset +40% lisää niin alkaisi jo 4K pelailua maistua.

Alunperin tomshardware on vertaillut tuossa jutussaan 1080p. Siitä minä ne luvut otin... Aika aggressiivisesti tulee kommenttia takasin päin ja oletetaan, että "kannatan" jotain merkkiä enemmän kuin toista.
Minä en sanonut missään vaiheessa, että 5700XT on hyvä 4K kortti. Mutta kolminkertaisella hinnalla pitäisi saada enemmän, kuin 50% (4K) lisää tehoa.
 
Alunperin tomshardware on vertaillut tuossa jutussaan 1080p. Siitä minä ne luvut otin... Aika aggressiivisesti tulee kommenttia takasin päin ja oletetaan, että "kannatan" jotain merkkiä enemmän kuin toista.
Minä en sanonut missään vaiheessa, että 5700XT on hyvä 4K kortti. Mutta kolminkertaisella hinnalla pitäisi saada enemmän, kuin 50% (4K) lisää tehoa.
Jep tulee kyllä koska "väittelyketju"

Mutta kyllä siellä on ihan 4K vertailujakin
qNsvybPwxDRDJsYtymSCiA-1200-80.png


Ja se että pitäisi ja pitäisi saada niin miksi pitäisi kun ei ole kilpailuakaan.
Munkin pitäisi saada 100k avustus rahaa vaan en saanut.
Toki 700e tollanen 2080Ti kelpaisi mutta kun ei saa niin ei saa joten pakko maksella jos meinaa 4K pelailla siedettävästi.
 
Eiköhän se tuleva 3080 maksa tuota luokkaa ja on sitten mukavasti nopeampikin kuin 2080 ti...
Joko tämä tiedetään?

Ei tiedetä yhtään mitään nopeuksista tai hinnoista. Huhuja varmaan on ollut ties minkälaisia.
Olisin todella yllättynyt, jos 2080Ti:tä nopeampi näytönohjain maksaa 700e. Veikkaan, että samaan nopeuteen (3080 ehkä?) päästään 750-800 eurolla. Olisko MSRP $699? En tiedä, vähän optimistiselta tuntuu.
 
Valitettavasti 2080 Ti on myös ainoa kortti, jolla 4K-pelaamista voisi edes kuvitella. Silläkin tekee tiukkaa. Jos siis halutaan se 60fps.

Totta, joka tekee 4k-pelaamisesta toistaiseksi Linus Sebastiania lainatakseni ''dumb''. Ehkä molempien AMD:n ja Nvidian seuraavat julkaisut tuo jopa 4k-pelaamiseen hinnan puolesta vähän järkeä. Silti lompakon ja FPS:ien puolesta 1440p taitaa pysyä järkevämpänä pelaamisena.

Nvidia tuskin laskee ylemmän teholuokkansa hintoja. AMD tarjonnee taas halvemmalla 1440p - 1080p -kortteja, mutta ajuriongelmat pitäisi saada kuriin. Mielenkiintoista nähdä kuinka kovia kortteja sieltä on tulossa. Konsolien tehoista on liikkunut hurjia huhuja laskentatehon puolesta. AMD varmasti ottaa ison stepin RDNA2 myötä, ja Nvidia varmasti lyö vielä kovemmat. Myös AMD:n RT tuo oman mausteensa soppaan.
 
Viimeksi muokattu:
Pikselien näkeminen ei ole ikinä haitannu, siksi ei aina ymmärrä tätä "enemmän resoa perkele" mentaliteettiä. Täällä mennään edelleen 1080p resolla. Ei ole rahasta kiinni edes. Sisältö ratkaisee enemmän.
 

Uusimmat viestit

Statistiikka

Viestiketjuista
257 220
Viestejä
4 469 304
Jäsenet
73 907
Uusin jäsen
kaitsun6

Hinta.fi

Back
Ylös Bottom