"A Khronos Group híres a különböző szabványos API-jairól, amelyek segítenek hatékonyabban kihasználhatóvá tenni az egyes területek eltérő hardvereit"

Ja, mint pl. a híres OpenGL, ami egy folyamatosan növekvő bloathalmaz vagy a Vulkan, amit igazából az AMD-től kaptak ajándékba, hogy a saját képükre formálhassák.

Nem lehetne inkább, hogy valaki olyan tervezi meg az API-t, aki ért is hozzá, Khronosék pedig csak lekoppincsolják, ahogy szokták? Még a nevén sem kellene gondolkodniuk, eléraknak egy "Open" stringet mint prefixet, és már kész is.

Hát nem tudom mennyire nézted-e a vulkan meg Mantle api-kat, de eléggé eltérnek. Tény, hogy merít koncepciókat a Mantle-ból, de elég sok a különbség. Továbbá a Vulkanban rengeteg az olyan konstrukció ami a mobil gpu-kból ered

Igen, pont erre gondoltam, lekoppincsolják az alapkoncepciókat, aztán elkezdik feldíszíteni a saját, mindent is lefedni akaró, egyre nagyobb halmazt alkotó hülyeségeikkel.

na, látom te képben vagy, tudsz segíteni nekem értelmezni mondjuk hogy ez a Kamaros ez hogy fog illeszkedni mondjuk az UVCVideo-hoz? már ha egyáltalán, persze.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Csak tipp az eddigi infok alapjan, de ez inkabb UVCVideo mellett, mint helyett/felett/alatt uzemelne. Gyak atvenne az UVCVideo szerepet, mint egy nagyobb ivu (cserebe nyilvan kevesbe optimalis, mivel minimum egy extra layer), altalanos camera API.

Amit valoszinubbnek latok az inkabb az, hogy ha bejon es jol is fog mukodni meg minden, akkor linux oldalon valszeg megmaradnak a low level cuccok annak, aki akarja, meg valami implementacio ezen a cuccon, ha valakinek fontosabb az, hogy mindegy az csak mukodjon, fajdalommentesen a barmi, mint hogy hatekonyan es gyorsan erjen el egy nagyobb figyelmet igenylo valogatasnyi kamerat.

Amugy szerintem maga az otlet nagyon jo, meg igeny is van ra, bar ha oszinte akarok lenni, En se bantam volna, ha valaki masnak jut eszebe a dolog...

[ Szerkesztve ]

"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin

hogy ki csinálja az annyira nem izgat, csak ne legyen ebből az hogy akkor a "nincs driver, nem megy az API" című problémakörbe futunk bele. én valszeg maradok még egy darabig az uvcvideo-nál, ez nálam ilyen mindent tud ami kell, minek cserélni jellegű dolog.

amúgy eddig én is eljutottam, csak a kolléga annyira okosnak és jól tájékozottnak tűnt a kérdésben hogy érdekelt az álláspontja

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Tudtommal az UVCVideo egy kernelmodul. Khronoséktól pedig kapsz majd egy user módú API-t, ami általában véve tudogat dolgokat, de persze hülye nyakatekert módon, hogy a golyóstoll kamerájától kezdve a 40 éves kameraállványokig mindent tudjon kezelni, utána meg jönnek majd szakmányban az extension-ök, hogy minden típust lehessen akár hatékonyan is meghajtani. Amikor már sok van belőlük, akkor pedig ezeket halmazokba csoportosítják, amelyeket elneveznek profiloknak, hogy ne kelljen mindenkinek minden marhaságot megimplementálni. 2040-re pedig az egész egy "kiforrott", "robusztus" API-vá válik, 1024+ db core függvénnyel.

Ez az én tippem az eddigi gyakorlat alapján.

Tehát az a probléma, hogy egy vendor specifikus mára már elavult API helyett van egy univerzális, naprakész megoldás?

valóban van egy uvcvideo nevű kernel modul, viszont az UVC nem ennyi hanem egy framework, aminek része a V4L-származék kernel driver, az uvcvideo kernel modul, egy kazalnyi library meg jónéhány usermode tool, ideértve komplett alkalmazásokat is mint a guvcview (bár ez valójában inkább egy frontend az uvc-hez)

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)