Один я искренне не понимаю зачем всё это нужно?

Если большая часть рендеринга- на цп, то на кой вообще видеокарта? Возвращаемся во времена 386?

Второе новшество - основная работа по рендеренгу ведётся на CPU, и только в случае когда драйвер _абсолютно_ уверен в возможности аппартной акселерации на GPU (DRI and RENDER pixmaps) указанный GEM-объект переносится в видеопамять.

Откуда ты этот бред выцепил?

прирост скорости вплоть до 14-кратного в 2d и 1.5-2 кратный прирост в 3d за объяснение не сойдут?

А я уже сегодня выпил. Теперь хоть знаю за что :)

Может ли служить объяснением нужности некоего устройства тот факт, что с его помощью можно в 14 раз быстрее ковыряться в носу и в 1.5-2 раза в попе?

Еще немного, еще чуть-чуть...

Дай угадаю, у тебя PIII до сих пор?

Революция в производительности!!

Теперь Intel-GFX всего в 1000 раз отстает от самой дешевой дискретной видеокарты!

Дай угадаю, у тебя PIII до сих пор?

Ты бы лучше следил за проектом libastral, глядишь обновляться не забывал бы.

Еще чуть-чуть, и будет совсем как Trident CyberBlade. Эх, времена...

src/sna/README

Furthermore, we try very hard to avoid migrating between the CPU and GPU. Every pixmap (apart from temporary «scratch» surfaces which we intend to use on the GPU) is created in system memory. All operations are then done upon this shadow copy until we are forced to move it onto the GPU. Such migration can only be first triggered by: setting the pixmap as the scanout (we obviously need a GPU buffer here), using the pixmap as a DRI buffer (the client expects to perform hardware acceleration and we do not want to disappoint) and lastly using the pixmap as a RENDER target. This last is chosen because when we know we are going to perform hardware acceleration and will continue to do so without fallbacks, using the GPU is much, much faster than the CPU. The heuristic I chose therefore was that if the application uses RENDER, i.e. cairo, then it will only be using those paths and not intermixing core drawing operations and so unlikely to trigger a fallback.

До этого бывали ситуации вида - затолкали pixmap в видеопамять, а потом оказалось что GPU нужную операцию не поддерживает - тащим назад, в системную память .... А это медленно (10Mb/s). И то, что intel-овские интеграшки UMA - ситуацию не спасало, приходилось делать полную копию, из пространства памяти которое для CPU - uncached, конечно можно было сначала вытащить в GTT, потм убрать эти страницы со свежими данными из ремаппинга к GPU, опять же настроить кэширование для CPU, получалось быстрее чем просто некэшированное чтение из видеопамяти - но всё равно медленно. Интегрированные в процессоря видеоядра, как я понимаю, могут притворятся ещё одним ядром SMP системы, с точки зрения взаимодействия кэшей, ядер и основной памяти.

Мелкие детали всегда было очень сложно рисовать чисто на GPU - оверхэд от настройки и последующего сброса состояния целого 3D-конвейера на рисование одной-двух точек, или запуск ДМА для подобных же объемов данных гораздо больше, чем просто нарисовать точки процессором, и затолкать в GPU одним махом.

Короче: процы и гпу скоро похоже опять станут одним целым, ибо всё к тому идёт. Уран!

А код, однако, очень качественный. Даже с комментариями в несколько абзацев и картинками в псевдографике для описания алгоритмов.

Что наконец-то? Вот бы.

Когда это появится в моей убунточке?

Через полгода, если ты об официальных репах.

Видимо, 11.10 будет замечательным релизом для нетбуков: допиленный юнити/юнити2д + этот драйвер. Ждём-с.

Ну что. Наконец штеуд радует.

Поставил xf86-video-intel-git libdrm-git

Последний коммит на момент сборки.

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bcef98af5...

GMA900, 2d стал реактивным. На 3d не расчитывал, но torcs без рывков стал идти при тех же fps (я его держал для отслеживания регрессий, когда периодически из гита дрова собирал). Так что если у кого санди бридж - пробуйте, дрова для него писались.

>>Если большая часть рендеринга- на цп, то на кой вообще видеокарта? Возвращаемся во времена 386?


а видеокарта как бэ должна только отдавать содержимое фреймбуфера устройству отображения с необходимой синхрой. GPU как класс не нужен. нужен универсальный сопроцессор (и не один) который сможет выполнять специфичные таски.