efikkan

Kunne du gi litt bedre forklaring efikkan?

 

sudo apt-get install

nvidia-current

nvidia-352.41-updates

nvidia-352.41-dev

 

Blir det noe slik eller har du bedre forslag?

Helst installer den nyeste, men bedre med eldre driver en driver som gjør maskinen ikke starter opp.

Du skal gjøre én kommando:

sudo apt-get install nvidia-current

eller

sudo apt-get install nvidia-352.41-updates

eller

sudo apt-get install nvidia-352.41-dev

 

Alt etter hvilken som gir deg nyest versjon, dersom alle gir det samme så velger du den første.

Enkelte burde ikke prøve seg på Linux.

Enkelte burde frastå fra å delta i diskusjoner hvor de ikke har noe konstruktivt å komme med...

Kjør på. Driveren er et halvt år gammel, men det skal være en grei start. Du må trolig korrigere den linjen, jeg tror nok at pakken heter et eller annet som begynner med "nvidia".

Du kjører den hersens nouveau-driveren.

 

Først, la oss fjerne det skrotet som eventuelt er der:

sudo apt-get purge nvidia*

 

Få siste pakkeliste:

sudo apt-get update

 

Hvis du har en xorg.conf fil, flytt den:

mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

 

Svartelist nouveau:

sudo nano /etc/modprobe.d/blackclist.conf

Legg til:

blacklist nouveau

 

Ctrl+O enter Ctrl+X

 

Legg inn ny driver:

apt-cache policy nvidia-3*

Se gjennom listen etter nyest mulig driver. Aktuelle pakker:

nvidia-current

nvidia-xxx-updates

nvidia-xxx-dev

 

Se etter versjonsnummer i prioritert rekkefølge: 361, 358, 355, 352. Du skal minimum finne noe 352.x der.

Så installerer du pakken:

sudo apt-get install pakkenavn

Følg med om der kommer noen feilmeldinger

 

Start X på nytt:

sudo service lightdm start

alternativt: (dersom du har kdm)

sudo start kdm

Har du mulighet å gi et bilde, prøvde å søke etter "xxx GB volume" men kommer til pornosider.

Så vet ikke hvor man finner det.

 

Problemet med slike løsninger er at de ofte blir nesten like dyre som en liten stasjonær PC, så hvorfor ikke like gjerne da kjøpe en stasjonær pluss en bærbar?

Fordi da får du begge deler i "en enhet"?

 

Og fordelen med det er?

De fleste slike løsninger har krevd ekstern skjerm, og da ender folk opp med nesten et komplett ekstra oppsett. Greit nok om den eksterne løsningen koster lite, men om prisen blir omtrent det samme som en ekstra maskin så høres sistnevnte ut som et bedre kjøp.

Problemet med slike løsninger er at de ofte blir nesten like dyre som en liten stasjonær PC, så hvorfor ikke like gjerne da kjøpe en stasjonær pluss en bærbar?

Basert på den loggfilen så er det feil driver som er installert, men var det fra en annen installasjon?

Men kan du finne tilsvarende fil for KDE-installasjonens systempartisjon? Du skal kunne åpne den direkte i Nautilus, men den vil ha en lang tallkod eller hete noe sånt som "xxx GB volume". Gå inn i var/log/Xorg.0.log på den partisjonen.

Fant ut det nå, ser ikke ut som jeg har fulle drivere nei, bare utdaterte  352x eller noe slik.

Problemet kommer jeg på nå får driver problemer får ikke startet x.org på grunn av en feilmelding "startX vil ikke fungere" Har du noen tips her ville det være flott har slitet en del med det tidligere kommer jeg på nå.

Hvilken pakke og versjon har du faktisk installert? F.eks. 352.79 skal være en relativt nylig patchet "gammel" driverserie, den skal være "grei nok".

 

Jeg ville forsøkt:

sudo service lightdm start

 

Hvis du bruker KDM:

sudo start kdm

 

Har du en .Xauthority-fil i home? Prøv å gi den ett nytt navn.

 

En output av /var/log/Xorg.0.log hadde vært fint.

Ta en less /var/log/Xorg.0.log

Skriv

/EE

Trykk n til du finner noe

q for å avslutte.

Hva installerer man hvis man har første generasjons titan og har nyeste kubuntu?

Medfølgende driver er OK, ellers kan du installere siste driver manuelt, selv om jeg anbefaler å bruke pakkesystemet til (*)ubuntu.

 

Husker ikke hva slags versjonnummer jeg har tror jeg har den nyeste:

sudo add-apt-repository ppa:xorg-edgers/ppa -y

sudo apt-get update

sudo apt-get install nvidia-current

 

Gjør følgende:

apt-cache policy nvidia-current

Hvis du har f.eks. 358.x eller 361.x så har du veldig nye drivere.

 

Hvordan setter man DVI\Displayport til (Display)

HDMI = Receiver out

 

For problemet slik det er nå så tror skjermkortet det 2 skjermer, så jeg får lite skjermbildet hvis jeg prøver å justere oppløsning så blir ikke bildet skalert riktig.

Nå bruker jeg ikke nyere Kubuntu, men det skal være under lydinnstillinger/volumkontroll. Et eller annet sted der skal du velge hvilket lydkort du skal bruke.

 

Vet du hva linux bruker som driverdatabase? Siden jeg har lenge lurt på hvorfor windows 10 kan bytte hovedkort uten oppstartproblemet. Men linux ofte henger seg i oppstart ved bytte av hovedkort.

Vel der finnes vel ingen felles driverdatabase, og den hos Ubuntu selv er totalt utdatert.

 

Du må nesten komme med flere detaljer om problemet ditt. Generelt sett så bruker vanlige hovedkort med Intel-chipsett å fungere uproblematisk.

 

Nvidias drivere støtter det aller meste, inkl. SLI, G-Sync, overklokking, ørten AA-modi osv. Det er vel egentlig kun Direct3D som mangler Men det finnes vel omtrent to spill som bruker SLI i Linux, og ingen av de er nye.

Merker en del distribusjoner har utdaterte drivere særlig nvidia til linux, og funger dårlig å få lyd gjennom HDMI.

Nå har jeg ikke testes SLI noe særlig, men er det SLI Visial enable indicator du tenker på?

 

Vet at NVIDIA 3D Vision funger dårlig i linux,men en stund siden jeg testet det.

Men godt mulig nvidia surrund funger bedre.

 

Lyd gjennom HDMI skal ikke være noe generelt problem, det er bare å installere driveren og aktivere som output.

 

Dessverre henger distribusjoner ofte noe etter med nye driverserier. Ubuntu bruker ofte å komme raskt med patcher derimot.

 

SLI kan du lese om i README.

 

3D Vision er avhengig av programmet/spillet som anvender det. Driverstøtten skal være bra, men jeg vet ikke om ikke-profesjonelle produkter som bruker det for Linux.

Så hvis jeg bør donere penger bør det gjøres til: https://www.winehq.org/donate

Da hjelper det alle distribusjonene? Istedenfor å gå til mellomann?

 

Du ville gjort heller det en å betale større sum til ReactOS?

Nå kan det være at du er supernostalgisk og ønsker en open source super-utdatert Windows?

Hvis målet ditt derimot er bedre spilling på Linux så bør pengene gå direkte til det prosjektet ja, Wine.

 

Du kunne gitt ReactOS millioner, det ville neppe utgjort stor forskjell.

 

Linux har en del problemet med SLI\crossfire X og nyere drivere?

Nvidias drivere støtter det aller meste, inkl. SLI, G-Sync, overklokking, ørten AA-modi osv. Det er vel egentlig kun Direct3D som mangler Men det finnes vel omtrent to spill som bruker SLI i Linux, og ingen av de er nye.

 

Catalyst/Crimson(fglrx) har vel noe eksperimentell støtte for CrossFire, men så vidt jeg vet så er ikke den solid. Støtte for FreeSync skal kommer "snart".

 

Er dette noe produsentene må prioritere, eller kan linux forbedre de åpene driverene?

Ja naturligvis må dette prioriteres av produsentene. F.eks. Nvidias drivere er ypperlig fordi Linux har vært en svært viktig arbeidsstasjonsplattform for Nvidia i over ett tiår for compute, profesjonell grafikk og profesjonell videoredigering. Men de andre produsentene prioriterer ikke Linux i tilsvarende grad.

 

De "åpne" driverne kommer aldri til å konkurrere med proprietære. Alle de "åpne" driverne henger årevis bak i driverstøtte, ytelse, ytelse/watt osv. Og alle av de (muligens med unntak av Intels som er offisiell) vil aldri være i stand til å ta igjen, siden de offisielle driverne er klare ved produktlansering mens de "åpne" begynner implementasjonen ved lansering. I tillegg er det et gjennomgående problem at alle disse driverne er en ikke-native implementasjon som betyr at der alltid vil være mer overhead. Situasjonen er faktisk nesten uendret på fem år, på tross av stadig mer ressurser på de "åpne" driverne. (Jeg sier "åpne" fordi de heller ikke er 100% åpne, de er bare noe mer åpne) Å utvikle drivere er trolig den tyngste formen for programvareutvikling, og spesielt grafikkdrivere som er de desidert mest kompliserte driverne. Utvikling av slikt vil aldri komme noen vei samme hvor store donasjoner som kommer inn. Dette må vi rett og slett overlate til produsentene som tross alt utvikler sine drivere i parallelt med med maskinvaren av eksperter. Maskinvaren er utdatert lenge før de "åpne" driverne kommer diltende etter.

 

For tror det gir lite verdi hvis jeg både skal donere til kubuntu\redhat og opensuse. Da det er de distribusjonene jeg bruker mest i dag.

Distribusjoner får generelt mye oppmerksomhet sammenlignet med de små prosjektene hvor det meste av den reelle utviklingen skjer. Enkelte distribusjoner (deriblant Red Hat) er store pådrivere for enkelte prosjekter. Men det er ikke alltid at pengene når dit det trengs mest, så donasjoner kan være et fint supplement der det virkelig trengs. Likevel er de store kommersielle produktene hovedfinansieringen for småprosjektene

 

Hva mener du med Steam OS og Vulkan?

SteamOS er bare en modifisert Debian som Valve bruker som distribusjonskanal. Vil du støtte denne så støtter du produkter som distribueres gjennom Steam.

 

Vulkan utformes av Khronos og implementeres av drivere. Der er det lite vi kan bidra, men vi kan bidra til at det blit anvendt; du kan kjøpe spill når de kommer.

 

men jeg prøver å få svar på om jeg kaster bort pengene mine hvis jeg doner til slike prosjekter.

Det er vanskelig å svare på. Men donerer du direkte til prosjekt så vet du hvor pengene går. Gir du penger til Red Hat så når nok noen av pengene frem til bra prosjekter.

 

Det er verdt å nevne at det er selskaper som Red Hat, IBM og flere som har gjort at Linux er så bra som det er. Som et rent donasjonsfinansiert hobbyprosjekt så hadde Linux-økosystemet aldri kommet noen vei.

 

Så donasjoner kan være målrettede supplement, men det er ikke drivkraften.

 

Egentlig burde staten\bedrifter være de som betaler slike ting slik at vi andre får det gratis.

F.eks gjennom lisensering. Særlig høyskoler\skoler kunne spart mye å gå for linux. Det er kun prinsippsak.

De skolene som går for linux velger neppe å donere noe vil jeg tro hvertfall.

Hensikten med Linux eller annen fri programvare er ikke at den skal være gratis. Hensikten er at infrastrukturen skal være fri og åpen slik at alle kan kjøre det de vil på toppen av det uten å bli låst inn til én monopolist. Når en offentlig institusjon vurderer en plattform som bygger åpen fri og åpen løsning så er ikke den gratis, der er alltid kostnader involvert. Og selv om det ofte betyr innsparte penger over tid, så er likevel hovedargumentet at de skal ikke låses til én aktør. Så hvis noen investerer i f.eks. Red Hat så kan de relativt enkelt hoppe til Suse senere, i motsetning til hvis de er dypt investert i MS.

 

Når en offentlig institusjon investerer i slik infrastruktur så bruker de midler på support-avtaler, og det innebærer som regel at det drypper tilbake til utviklerne.

 

Donasjoner er flott, spesielt for de som er engasjert kan komme med målrettede bidrag. Men jeg tror du vil slite med å bli tatt seriøst om du forsøker å få staten til å gi penger til prosjekt x.

 

En annen måte kunne linux\ og andre frivillige finne andre måter å få inn penger på f.eks gjennom reklame.

Tror det er bedre måte.

Det er slik flere distribusjoner og prosjekter allerede finansieres. F.eks. Ubuntu og Mozilla (og deler av Opera). Dette oppnås gjennom avtaler med søkemotorer, annonsepartnere og butikker som f.eks. Amazon.

Hei, tror dere å droppe å betale Microsoft\Apple for lisens.

Og heller bruke de pengene, f.eks donasjon til opensouce miljøet f.eks 2000 kr i året hadde hjelpet å få Linux\ ReactOS til å bli mere konkuransedyktig mot Windows 10\OSX Yosemite?

Bare så det er sagt, ReactOS er en reimplementasjon av en utdatert Windows NT-versjon, de er mange år fra noe som er brukbart og jeg forstår ikke hensikten når det innen da er nærmere 20 år utdatert. Men det er én positiv ting med ReactOS; at Wine får noe igjen for kunnskapen. Du vet "når det regner på presten...".

Jeg mener det finnes langt bedre "investeringer" enn ReactOS hvor kronene dine kan komme mer til nytte.

 

For skal man bli profesjonel på linux gjerne mot servere\arbeidstasjoner bør man vurdere FreeBSD som er er en unix veriant. Men det blir litt tungvidt med mye kommandoer.

Den forstod jeg ingenting av. Greit nok at FreeBSD en en god BSD som har absolutt sine bruksområder, men desktop/arbeidsstasjon er neppe ett av de områdene den gjør det bedre enn Linux.

 

Så tror dere det er penger det står på, eller tror dere ganske mange må gjøre det samme for å få fortgang i utviklingen? Særlig med tanke på drivere\nyttige programmer og vulcan?

Jeg mener det er viktigst å støtte de essensielle byggeblokkene i Linux og BSD som ofte er oversett men som vi alle er avhengige av. Linux-kjernen i seg selv er godt finansiert og vedlikeholdt, men økosystemet rundt står det delvis verre til med. Jeg tenker da på biblioteker som (g)libc, OpenSSH, OpenSSL*, compiz osv. Compiz er knapt vedlikeholdt og er en av hovedårsakene til desktop-problemer i Linux. I tillegg kan det være verdt å slenge noen kroner i retning av programmer som du er avhengig av, f.eks. modellering, grafikk, lydstudio osv.

(*OpenSSL har fått mye oppmerksomhet og midler den siste tiden pga. problemer vi alle har hørt om)

Så dette blir et filter mellom baklyset og panelet. Hvis teksten i artikkelen er riktig så blir dette et slags utjevningsfilter for lokal dimming. Dette gjøres nok fordi de trenger kraftigere baklysning for å nå lysstyrkekravet til HDR, men at det vil introdusere lyse flekker i panelet uten et slikt filter.

 

Dette er nok bare begynnelsen på de kreative "jukse-løsningene" vi kommer til å se på LCD-fronten de neste årene. Vi vet fra før at lokal dimming introduserer stor lokal feil i lysstyrke innenfor sonene:

Jeg har sett bedre bilder på dette, men dette var de jeg fant i farten. Noe av det verste du kan vise på en slik skjerm er en gradient som går på skrå over skjermen.

 

For de som ønsker HDR så er det bare å spare/vente til en annen teknologi enn LCD.

Hvorfor skal man i det hele tatt bruke OpenGL på nye prosjekter da?

Vi er der hvor utviklere bør begynne med å vurdere Vulkan for nye prosjekter, gitt at de lager spillmotoren. Men selv dyktige utviklere vil trenge flere måneder på å bli godt kjent med Vulkan, og når produktet skal ferdigstilles bør være en del av vurderingen. Det er litt kjedelig om produktet mister 30% av kundemassen hvis de velger å lansere et spill på Vulkan for tidlig. Ting som skal lanseres om 1.5-2 år vil nok være mindre problematisk.

 

Kan ikke dette da føre til at spill får en "failsafe"-sti for kompilatorer som ikke tolerer feil i spesifikasjonen, og en "rask"-sti for kompilatorer som tolererer feil i spesifikasjonen?

Neppe, det handler om syntaks på shader-kode*. Hvis du skal aktivere funksjonalitet utover minste-spesifikasjonen så må det eksplisitt inkluderes.

 

-----

 

*)

 

 

 

Det tar ca 1 år! Mange DX12 tittler dukker opp i år, og mange fler neste år! De fleste sitter med sitt skjermkort i mange år før dem oppgraderer! Pascal vil ikke bli redningen for nvidia! AMD kommer til å spise markedsandeler i fra nvidia^^ DX11 historien er en saga blott nå! GCN ble lansert for tidlig, da den er en DX12 arkitektur. Bra for nvidia at AMD tenker litt lenger enn andre^^

Det var fryktelig mange påstander her

Jeg vet fremdeles ikke hvordan AMD tenker lenger enn andre?

Vulkan og DX12 blir ikke virkelig relevant før om to-tre år tidligst, og innen den tid vil både 390X og Fury X være utdaterte kort ytelsesmessig.

Riktig.

 

Jeg mener bestemt å huske at Nvidia sin implementering av OpenGL generelt sett anser spesifikasjonen som en retningslinje der GPUene ender opp med å gjøre noe som er nært nok til å anses som akseptabelt, og raskt. Som dermed har ført til at "NvidiaGL" er et uttrykk. Til sammenligning skal visstnok AMDs implementering være mer etter spesifikasjonen, men også tregere i prinsippet.

 

Men det kan også hende dette er gammel/feil informasjon.

Du er inne på noe som ofte er misforstått. Der er noen aspekter av shadere som Nvidia ikke er like strenge som spesifikasjonen, noe de har valgt siden shader-kompilatoren til GLSL er den samme som HLSL for Nvidia, som er Cg-kompilatoren. Derfor kan du altså i noen tilfeller kompilere feil OpenGL-syntaks og utviklere som ikke er oppmerksom på dette kan gjøre tabber. Det har derimot ingen verdens ting med ytelse å gjøre, for hvis du gjør denne feilen så vil det enkelt og greit ikke kompilere på annen driver.

Trenden er den samme når det gjelder DX12 og vulkan! AMD banker nvidia i vulkan.

Eeeh, nei!

 

Mantle, DX12 og vulkan er veldig like...

Eeeh, nei!

 

AMD har sin store fordel der!

Som ingen har sett manifestere seg så langt!

 

Hadde du holdt deg til en enkelt tråd med de "harde" faktaene dine hadde jeg trolig ikke reagert , men slik jeg ser det bruker du enhver mulighet du har til å kommentere negativt og ikke minst kvast AMD.

Spar oss for de løgnene dine!

Hver gang jeg kommer med fakta så svarer du mer personangrep. Det er usaklig oppførsel som ikke sømmer seg.

 

Nå er dette min subjektive oppfatning av deg og jeg lover faktisk at jeg ikke kommer til å påpeke dette flere ganger selv om jeg personlig oppfatter denne type for kvasse og negative meninger som ødeleggende for en god diskusjon.

Du og et par andre her har stått for systematisk sabotasje av saklig diskusjon ved at dere angriper enhver som påpeker faktum som ikke setter AMD i det lyset dere ønsker. Skal vi ha en god diskusjon så får dere lære dere å kontrollere følelsene deres i møte med fakta. Det er helt bak mål at jeg skal angripes for å bidra til en saklig diskusjon.

 

Er det spekulasjoner eller er det gjort endringer i Opengl nå i det siste som gjør at Nvidia kortene ikke greier å gi den samme ytelsen som Amd kan.

Der er ingen store underliggende endringer i OpenGL de siste årene. De støste endringene er utvidelser som bindless graphics, sparse textures, bedre occlusion, command list og conservative raster. Alt dette bygger videre på 4.x, og ingenting skulle tilsi at den ene skulle slite mer enn før.

 

Siden du tydeligvis har god erfaring i nettopp Opengl hadde det jo vært fint om du hadde påpekt årsaken eller om det rett og slett er trolig dårlig koding eller optimalisering mot Amd som foregår her.

På Tesla og Fermi så var det ikke et veldig stort ytelsegap mellom AMD og Nvidia (selv om AMD hang etter på spesifikasjonsfronten). I utdaterte OpenGL 2.x har AMD nesten hengt med, men "ingen" lager noe nytt i det. Men med Kepler så gjorde Nvidia et betydelig hopp i ytelse i OpenGL 4.x som AMD ennå ikke har svart på. Til mer komplisert lasten er til større er forskjellen, noen ganger 30-40%, noen ganger mindre og andre ganger betydelig mer. Jeg tror absolutt at AMD kunne hentet ut mye av det samme bare de hadde prioritert det. Dessverre har aldri OpenGL vært en prioritering fra AMD, noe som er virkelig synd siden det har hindret utbredelse. Mitt største håp for Vulkan er at AMD skal ta det seriøst slik at spillselskaper faktisk kan bruke det. Jeg tror du forstår det også om du tenker deg om, at når situasjonen for utviklere er at OpenGL medfører dårlig ytelse for ~30+% av kundene men øker markedet med ~5% (inkl. XP), så forblir Direct3D det naturlige valget. Jeg klandrer ikke spillutviklerne for det valget, men de to driverprodusentene som ikke får ut fingeren.

Det kommer ikke som en overraskelse at du er ekstremt negativ og ikke minst kvass i forhold til ytelsen til Amd

Nå er det på tide at du gir deg med det våset ditt! Alt jeg kommer med her er rene og harde fakta.

 

Om vi snur på det kan vi jo spørre oss hvorfor Nvidia ikke greier å yte bedre enn Amd i denne testen da de både har bedre hardware og drivere rent historisk?

Det blir bare ville spekulasjoner.

 

 

Men, slik som Malvado skriver, så er det "rart" at AMDs 290 er på høyde med 980, men som det skrives også, det kan være pga. async. shading. muligens.

Nei, Doom bruker OpenGL som ikke støtter async shading ennå.

 

Ja, det er uheldig med optimalisering mot kun en arkitektur, men igjen så er det artig å se hvordan kortene yter uten optimaliseringer.

Som jeg har nevnt før, hvis utviklere jobber daglig på kun én produsent og tester på de andre en gang i blant så vil de gjerne ende opp med å gjøre designvalg som favoriserer den ene (uten at det trenger å være bevisst). Dette kan lett utgjøre 15-20% ytelse.

 

Doom DX12 viser sammen trenden som tidligere DX12 tester. Kun pascal som kan redde nvidia ang. DX12 og Vulkan! AMD gjør det mye bedre enn nvidia uten optimalisering...

Det er et glimdrende blinkskudd å bruke en OpenGL-benchmark for å vise at Direct3D 12 yter bedre på AMD-maskinvare!?!?!?

AMDs/ATis linuxdrivere har vært viden kjent å være elendige.

AMD er kjent for å ha elendig OpenGL-ytelse (uansett plattform) og dårlige Linux-drivere. OpenGL-ytelsen på tvers av plattformene er omtrent i samme klasse.

 

Men jeg er enig i at å bruke det som 100% fakta for ytelsen i DooM 2016 vil bli feil da dette er fra en Alpha test. Synes dog det er interessant lesning da, ifølge journalisten, ikke er gjort spesifikke optimaliseringer i motoren på det tidspunktet og da at AMD har en så solid ytelse.

Alpha er alpha, vi aner ikke hva de har gjort. Uansett så er det alltid uheldig med spill som blir optimaliserte mot én produsent. Det er helt greit å støtte valgfrie deler av OpenGL, men å bygge om shader-programmer og datastrukturer for å passe én GPU-arkitektur er idiotisk (selv om de fleste spill gjør det).

Vet ikke hvor mye vi skal legge i dette:

 

http://www.tweaktown.com/news/50737/amd-beats-nvidia-early-doom-benchmarks-dominating-4k/index.html

Vel vi får nå se på den endelige versjonen. Jeg har lenge håpet på ordentlig OpenGL-støtte fra AMD, men jeg har ennå ikke sett det, og fra før av vet vi hvor dårlig ytelsen kan være.

Vil det bli støtte for Vulkan i GTX 980? Leste at Ashes of Singularity ville bli utgitt på Linux med Vulkan.

Alt av Kepler og Maxwell støtter allerede Vulkan, men driverstøtten er naturligvis i beta.

Ja nesten, Men det morsomme med DX12 og vulkan er jo at du slipper og ha like skjermkort for og kjøre multi gpu,

Fordelen med det er jo at du fortsatt kan ha det gamle skjermkortet når du bestemmer deg for og oppgradere.

I motsetning til AFR er det begrenset til hva som kan splittes opp mellom flere GPUer uavhengig av hverandre, og det må spesifikt styres fra spillet sin side. F.eks. noe fysikk og partikkelsimulering kan typisk gjøres i parallell, men utover det er det veldig begrenset. Derfor vil du aldri kunne bruke dette til å få f.eks. 30-40% bedre ytelse i alle spill.

 

En GPU gjør i dag mange forskjellige type oppgaver, ser ikke hvorfor det ikke skulle gå ann å spre noe av dette over flere GPUer. Ett eks. er physx. Det blir noe annet med "tradisjonell sli/cx" når annenhvert bildee eller halvparten av hvert bilde deles mellom GPUer. Jeg vil tro at denne måten å gjøre ting på kan moderniseres betraktelig.

SFR har vel blitt kuttet ut pga. alle problemene det har, og ytelsen blir heller ikke spesielt god. Når flere GPUer skal dele tegning av ett bilde så kreves det mye synkronisering frem og tilbake, og det meste av rendering i dag skjer i flere steg som gjør det i praksis ubrukelig. Inntil videre forblir AFR eneste gode alternativ.

Som forventet vil det bli en rekke med test-drivere fremover som forbedrer Vulkan-støtten: 356.43 (Windows) og 355.00.28. Dette er altså andre patch for Linux.

 

Do not feed ^^

 

LXQt? Var ikke litt av poenget med LXDE at det skulle være lite bloat?

 

Qt i seg selv er ikke ille sammenlignet med superbloat som .NET/Mono og Java, og er riktig nok noe enklere og ryddigere enn GTK. Men GTK brukt riktig er fremdeles mer effektivt, og strengt tatt synes jeg det er greit at det er litt terskel for å lage noe. GTK er kanskje modent for utskiftning, men det bør gå i retning noe implementert i GPU fremfor mer bloat.

 

Jeg kunne nok spesifisert det, men jeg tenkte spesifikt på CPU-last. Noe marginalt mer minneforbruk i seg selv burde ikke være et stort problem, spesielt hvis det er relativt konstant for det gitt program og for grunnsystemet. Det er en generell trend at programmer og grensesnitt bruker stadig mer og mer ressurser gjennom abstraksjon og er mindre optimalisert. Eksempler er bruk av listeners i stedet for callback, osv. Og vi kan ikke slippe unna med raskere maskinvare heller, for CPU-ytelse har stått stille i fem år nå. For den som forstår seg på lavnivåoptimaliseringer så kan det nevnes at nyere arkitekturer er mer avhengig av god kode for å yte optimalt (eks. Haswell vs. SB). Skal vi ha programvare som yter mye bedre i fremtiden (spesielt på bærbare enheter) så trengs bedre kode som utnytter CPUen optimalt, og bruker GPUen der det gir mening.

Linux trenger en ny "legacy" desktop, der man tar de gode tingene fra tidligere desktoper og lager den fra scratch (har jeg hatt tid og fått betalt skulle jeg ha gjort det selv).

Riktig. Enkelt, ingen bloat, ryddig og effektivt implementert for nye plattformer. Fancy funksjonalitet kan overlates til valgfrie tredjepartsprogrammer. Det er også ganske tullete at både Gnome og KDE skal fokusere på sine (delvis ubruklige) erstatninger av alle støtteprogrammer; som e-post, nettleser, musikkavspiller, osv. Det som var bra i Gnome var det som ble laget på 90-tallet. Og selv om koden i seg selv har blitt forsømmet og trenger erstatning så er selvsagt alle de prinippielle forbedringene som ble gjort over tiår verdt å ta med videre.