LINUX.ORG.RU
ФорумTalks

[ненависть][многабуков]Intel must die

 


0

0

Предистория: весь сегодняшний день был потрачен на выяснения причин, по которым объём видеопамяти на интегрированной видеокарте Intel GMA, установленный в BIOS, отличается от фактического в 4 (!) раза. Решение проблемы найдено так и не было, ибо её корень в самой архитектуре интегрированного видео (и в значительно меньшей степени - в кривой реализации их поддержки в ядре Linux).

Однако потраченное время не прошло даром: я окончательно осознал кривизну современной архитектуры.

К примеру вот история (упрощенная) развития подходов в рендеринге видео: Начало 90х: видео обрабатывается на ЦП, который пользуется ОЗУ, все довольны. Конец 90х: рендеринг переносят с ЦП на отдельный процессор (для увеличения производительности, угу) => для того отдельного процессора нужна отдельная память. Середина 00х - для увеличения степени интеграции процессор, обсчитывающий видео, интегрируют в чипсет, и с помощью костылей заставляют это убожество юзать ОЗУ. Начало 2009го года: Microsoft изобретает технологию рендеринга на ЦП и обещает представить её в новой Windows7.

Что до меня, мне кажется, резонно предполагать в ближайшем будущем создание устройств, использующих одно суперскалярное RISC ядро как для обсчета видео, так и для эмуляции x86 инструкций (отказываться от которых, кажется, производители пока не готовы). Если бы были деньги - прямо сейчас побежал бы патентовать.

Что касается технической проблемы, которая привела меня ко всем этим выводам: в BIOS установлен объём видеопамяти 64Мб.

$ grep -i VideoRam /var/log/Xorg.0.log
(==) intel(0): VideoRam: 262144 KB

$ sudo lspci -vs 00:02.0
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
	Subsystem: Acer Incorporated [ALI] Device 0110
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at d0300000 (32-bit, non-prefetchable) [size=512K]
	I/O ports at 1800 [size=8]
	Memory at c0000000 (32-bit, prefetchable) [size=256M]
	Memory at d0400000 (32-bit, non-prefetchable) [size=256K]
	Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
	Capabilities: [d0] Power Management version 2
	Kernel modules: intelfb

$ cat /proc/mtrr 
reg00: base=0x000000000 (    0MB), size= 1024MB, count=1: write-back
reg01: base=0x040000000 ( 1024MB), size=  512MB, count=1: write-back
reg02: base=0x05f700000 ( 1527MB), size=    1MB, count=1: uncachable
reg03: base=0x05f800000 ( 1528MB), size=    8MB, count=1: uncachable
reg04: base=0x0c0000000 ( 3072MB), size=  256MB, count=1: write-combining

Nixopatolog
() автор топика
Ответ на: комментарий от Fray

Учитывая, что драйвера для своей продукции под Linux Intel пишет сам, вина всё равно на них. И не пытайтесь реабилитировать эту контору в моих глазах. Доверие подорвано навсегда.

Nixopatolog
() автор топика

> Середина 00х - для увеличения степени интеграции процессор, обсчитывающий видео, интегрируют в чипсет, и с помощью костылей заставляют это убожество юзать ОЗУ.

Неверно. Intel 810 вышел в начале 1999 года. И он был далеко не первым.

question4 ★★★★★
()

> резонно предполагать в ближайшем будущем создание устройств, использующих одно суперскалярное RISC ядро как для обсчета видео, так и для эмуляции x86 инструкций

нене, имхо, саммое оптимальное - это кучка специализированных ядер (I/O, графика, звук, аппаратное декодирование всяких mp3, xvid, етц) на одном кристалле.

isden ★★★★★
()

> Начало 90х: видео обрабатывается на ЦП, который пользуется ОЗУ, все довольны.

PC был таким с самого начала, если не путаю. Так дешевле.

> Конец 90х: рендеринг переносят с ЦП на отдельный процессор (для увеличения производительности, угу) => для того отдельного процессора нужна отдельная память.

А большинство 8-битных игровых компьютеров с конца 1970-х имели графический чип. Он мог пользоваться основным ОЗУ, своим собственным, или переключаться. Изображение получалось лучше, но стоил компьютер дороже и писать программы было тяжелее.

question4 ★★★★★
()

> Что до меня, мне кажется, резонно предполагать в ближайшем будущем создание устройств, использующих одно суперскалярное RISC ядро как для обсчета видео, так и для эмуляции x86 инструкций (отказываться от которых, кажется, производители пока не готовы). Если бы были деньги - прямо сейчас побежал бы патентовать.

зачем мне графическая подсистема в ядре, если я не использую ее для рендера 3D графики ? Ничего такого не будет, у AMD/ATI были проекты, но они, к счастью, загнулись. пусть лучше развивают GPU

phasma ★☆
()
Ответ на: комментарий от phasma

>зачем мне графическая подсистема в ядре

Специально для таких как ты выпустят версию, на которой соответствующий блок будет выведен из строя. Рынок полупроводниковых приборов чуден.

И вообще ты не прав: при таком подходе возникнет возможность пустить неиспользуемую мощность на вычислительные задачи - суперскалярному ядру общего назначения всё равно (ну, почти), над чем работать: обсчитывать 3D, решать диффуры или компилить ядро.

Nixopatolog
() автор топика
Ответ на: комментарий от question4

>А большинство 8-битных игровых компьютеров с конца 1970-х

Я не говорю, что это революционно новый костыль. Но от своей баянистости костылём он быть не перестаёт.

Nixopatolog
() автор топика
Ответ на: комментарий от isden

>имхо, саммое оптимальное - это кучка специализированных ядер

И в чем же оптимальность, когда у тебя 90% кристалла будет попусту простаивать в силу неуниверсальности компонентов? И размеры кристалла будут оставлять желать лучшего...

Программисты уже давно поняли то, что до некоторых производителей железа никак не дойдёт: если что-то должно делаться много раз в разных местах, достаточно реализовать это в одном месте (но зато это можно реализовать качественно). И графике, и звуку, и аппаратному декодированию надо считать синусы. Так зачем плодить математические сопроцессоры в каждом специализированном ядре?!

Nixopatolog
() автор топика

>Что до меня, мне кажется, резонно предполагать в ближайшем будущем >создание устройств, использующих одно суперскалярное RISC ядро как для >обсчета видео, так и для эмуляции x86 инструкций (отказываться от >которых, кажется, производители пока не готовы). Если бы были деньги - >прямо сейчас побежал бы патентовать.

даю другое предсказание - в ближайшем будущем(лет через 20) народ перейдет на плис матрицы вместо процов общего назначения, которые будут перепрошиваться для каждой новой программы.

впринципе уже сейчас время перепрошивки самых крутых Xilinx - доли секунды. и если каждый раз делать проц под задачу на быстрой плис матрице - получается гораздо быстрей чем с процами общего назначения.

и уже сейчас есть автоматические генераторы проца и кода под него из system C и system Verilog кода.

vasaka ★★★
()
Ответ на: комментарий от vasaka

так что грядет эпоха когда железо будет делаться под программы, а не наоборот.

и сейчас частенько так, но вскоре это будет дешево.

vasaka ★★★
()
Ответ на: комментарий от vasaka

> впринципе уже сейчас время перепрошивки самых крутых Xilinx - доли секунды. и если каждый раз делать проц под задачу на быстрой плис матрице - получается гораздо быстрей чем с процами общего назначения.

Перепрошивки то маленькое, а вот синтеза этой прошивки...


eXire ★★
()
Ответ на: комментарий от eXire

ну можно насентезировать заранее.

вот гентушникам придется туго.

vasaka ★★★
()
Ответ на: комментарий от Nixopatolog

> когда у тебя 90% кристалла будет попусту простаивать

с чего бы вдруг? тот же ARM например, умеет отключать неиспользуемые ядра.

isden ★★★★★
()
Ответ на: комментарий от vasaka

> грядет эпоха когда железо будет делаться под программы, а не наоборот

Она уже давно наступила. Сюрприз?

Relan ★★★★★
()

>по которым объём видеопамяти на интегрированной видеокарте Intel GMA, установленный в BIOS, отличается от фактического в 4 (!) раза

man DVMT

devl547 ★★★★★
()
Ответ на: комментарий от vasaka

>только сейчас процесс долгий - а впредь будет делаться любым программистом.

Не ,не надо такого :)) - бардака в Linux и так хватает.
А еще как начнут стругать Jast for fun железяки - совсем капец мозгам будет.

elipse ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.