Многоядерное рисование

доступ к шине всё равно по очереди будет

Имхо, то же самое, что и каждым процессорным ядром пытаться писать в одну и ту же область памяти или делать вывод в один и тот же порт. Шина данных, как и шина ввода-вывода, хоть и широкая, но последовательная.

По моему скоромному мнению, куда более удачной идеей было бы командовать видеокарте, что рисовать (тот же OpenGL), а драйвер уж как нибудь распараллелит это дело (на ядрах видюшки).

Почитай про OpenCL/CUDA и не парь людям мозги.

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

Почитай про OpenCL/CUDA и не парь людям мозги.

+

и в частности, можно делать блокировки нитей по цвету пикселя, например

Если кто-то будет обещать поддержку атомарных операций над этой памятью, то можно. Но, афаик, этого нет.

Если я правильно понимаю, что выполняется отображения части адресного пространства процессора на память в видеокарте

Так только с барами. Но через бары будет где-то пару мегабайт в секунду. Запись кешируется, и когда читаешь обратно оно шлётся в железяку страницами, толи по 128 толи по 512 байт, точно не помню. А что бы было быстро нужен пдп. Но пдп контролёру пофиг сколько там у тебя ядер. Хоть стописот, один фиг скорость будет зависеть от количества лейнов.

Что если хочется каждым процессорным ядром рисовать на PCI-e видеокарте?

Рисует не CPU, рисует видеокарта. CPU только кормит GPU данными и командами, и иногда что-нибудь забирает по шине. А шина мало того, что последовательная, так ещё и относительно медленная. Плюс ещё и DMA, т.е. видеокарта сама обращается к памяти минуя CPU.

Вообщем, CPU тут не у дел.

видеокарта сама обращается к памяти минуя CPU.

мы уже в соседнем топике выяснили, что не может обращаться никто напрямую к памяти минуя ЦПУ - у каждого ЦПУ своя собственная память и никого он к ней просто так не пускает.

Вот тебе картинка типичной системы времен Core 2: http://i.imgur.com/ZF3XLBM.png?1

В современных процессорах это всё на одном кристалле CPU, без всяких разделений на мосты.

Даже если логически рассуждать, можно догадаться, что память подключена к CPU не напрямую не спроста.

В современных процессорах (я пока про x86_64) CPU общается с контроллером памяти через внутренюю шину офигительной скорости. К этой же шине подключен контроллер PCIe. Соответственно, контроллер PCIe может напрямую общаться с контроллером памяти. Естественно, на шине предусмотрен арбитраж и всяческие защиты от зависаний. Арбитраж может управляться CPU, т.е., например в таком стиле: в CPU приходит приходит запрос от PCIe: «эээ слыш, тут девайс долбится в память по такому то адресу, можно на 5 микросекунд память занять?» CPU может ответить «OK» или «неОК, подожди я кэши посинкаю сначала». И в то время как PCIe работает с памятью процессор ничего с ней сделать не может.

Из-за того, что всяческие девайсы могут писать/читать в память обходя CPU, начинаются проблемы с когерентностью кэшей. Поэтому придумывают всякие штуки вроде DMA snooping (тут хороший вопрос на stackoverflow). ЕМНИП, даже в ядре linux есть режимы DMA с учетом кэшей и без.

у каждого ЦПУ своя собственная память и никого он к ней просто так не пускает.

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

P.S. И таки иногда внешним девайсам (например FPGA с кривым PCIe контроллером) удается намертво завесить PCI-хост и шину процессора, проверено личным опытом.

Я бы начал с вопроса... а ЗАЧЕМ ТС-у делать то о чем он спрашивает? В 90% случаев удается переубедить человека делать более стандартные тривиальные вещи.

-

мне нужно понимание конкретики (а не абстрактной модели, которая сможет работать даже на обычном процессоре)

не парь людям мозги

не давай офтопичных советов. Разве я спрашивал, как это делать через абстрагирующие программные интерфейсы? я спрашивал как работает железо. В абстрактной спецификации ничего конкретного быть не может.

а ЗАЧЕМ ТС-у делать то о чем он спрашивает?

чтобы получить понимание того, как это работает. Конкретное и проверяемое. А то может вы всё хотите за абстракциями запрятать...

А какой конкретики-то ты хочешь? На том же OpenCL можно решить задачу как эффективно, так и стрёмно, абстрактные модели тут не к месту.

На вот тогда почитай, например

http://www.realworldtech.com/ivy-bridge-gpu/

И посмотри

https://software.intel.com/en-us/articles/opencl-fall-webinar-series

А какой конкретики-то ты хочешь?

адреса, пароли, явки команды, примеры

На том же OpenCL можно решить задачу как эффективно

нельзя, потому что для моей платформы OpenCL не реализован...
всё, больше про OpenCL ты не будешь вспоминать и офтопить?

я не знаю про что ТС пишет и возможно ли это.

но советую посмотреть на 2х сокетные материнки по Зеоны.
Там как раз такая интересная фигня, что каждый сокет имеет свою pci-e x16, это помимо своего набора памяти.

так что возможна идея и не тупняковая.

я не уверен, что можно записать что-либо напрямую в видеопамять, минуя Memory Controller из состава GPU.

В случае, если нельзя - многоядерное рисование должно делаться не центральными процессорами напрямую, а несколькими GPU под командованием нескольких CPU

Але, PCIe - последовательный интерфейс. Точнее, набор независимых последовательных каналов.

Не свисти, начиная с Sandy Bridge DMA умеет в кеши CPU гадить.

Ну так и читай, кто ж мешает-то? http://en.wikipedia.org/wiki/PCI_Express

На фига на лоре спрашивать о том, что гуглится легко?

Не всегда, то, что возможно, имеет смысл делать.

Можно ли организовать, чтобы четыре ядра рисовали каждое свою четвертинку экрана напримую в экранный буфер - да. Будет ли это быстрее, чем если одно ядро будет управлять GPU - вряд ли.

На фига на лоре спрашивать о том, что гуглится легко?

ну пойди нагугли строчки в опенсорсном драйвере (каком, кстати - radeon ?), где это проделывается...

чтобы понимать, что имеет смысл делать, нужно понимать, что возможно делать в принципе. Я пока не понимаю и никто ответить не может. Ответом бы являлся пример - каким кодом на CPU инициализировать видеокарту и нарисовать на ней пару букв в графическом режиме без использования BIOS.

Ну найти наверно ещё можно, но искать надо порядка 20 лет тому назад

искать надо порядка 20 лет тому назад

а вот и нет. Отдельностоящие высокопроизводительные GPU появились в ~2006-2009 годах

Вот только на высокопроизводительных GPU как правило не используется непосредственное управление и рисование от CPU.

каким кодом на CPU инициализировать видеокарту и нарисовать на ней пару букв в графическом режиме без использования BIOS.

Без биоса - никак.
Либо дёргать INT10h, либо работать через VBE.

как правило не используется непосредственное управление и рисование от CPU.

вообще-то это единственный способ что-то нарисовать - выполнить программу, заруженную с ЦПУ, цитирую:

A host application cannot write to R600 local memory directly, but it can command the R600 to copy programs and data from system memory to R600 memory, or vice versa. A co mplete application for the R600 includes two parts: a program running on the host processor, and programs—called kernels or shaders — running on the R600 processor. The R600 programs are controlled by host commands, which do such things as set R600-internal base-address and other configuration registers, specify the data domain on which the R600 is to operate, invalidate and flush caches on the R600, and cause the R600 to begin execution of a program.

Без биоса - никак. Либо дёргать INT10h, либо работать через VBE.

вылезай из криокамеры.

вылезай из криокамеры.

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

универсальных способов достучаться до них всего два

три - еще по драйверу на каждое устройство

универсальных
по драйверу на каждое устройство

Ну-ну.

что ну-ну, этот ваш xorg так и работает

С дуба рухнул? А вся видяшная обвязка в ядре лишней вдруг стала? Более того, можно вообще картинки выводить и без иксов, напрямую через фреймбуфер.

А еще можно текст выводить и без фреймбуфера. Через 10h, либо вручную инициализировав режим экрана через регистры видяхи, а ПОТОМ уже записывая данные в область памяти (текст вроде с 0xB8000 пишется)

тебе нужно не многоядерное рисование, а многоядерный рендеринг,как в VRay и блендере. Алгоритмы в сети лежат, можешь попробовать. Многоядерное рисование не позволит видеошина и шина доступа к памяти

If you are not in VBE 3.0, unless you have not a V86 mode manager you cannot change VESA mode in PM if you have not VBE version on you graphics card
- Bochs, virtual PC, vmWare, virtualbox are all in VBE 2.0
- having a V86 mode manager is a lot of work

Переключением режимов занимается код в ядре.
Но если у тебя есть ядро - у тебя есть и фреймбуфер.

у меня нет ядра и мне код переколючения режимов надо написать.
как-то так:
http://wiki.osdev.org/How_do_I_set_a_VGA_mode_without_the_BIOS

только для современной видеоплаты, у которой другие регистры и режимы

мне код переколючения режимов надо написать.

1. Почему не сделать как надо через bios?
2. Почему не сделать через VBE?
3. Если определённая видеокарта - то читать на неё документацию. И забыть о совместимости с другими.

1. потому что тут - http://wiki.osdev.org/How_do_I_set_a_graphics_mode
написано, что код bios будет работать только до переключения в защищенный режим. А я уже в нём.

2. Потому что версия неправильная, писал выше

3. Именно это я спрашиваю в соседней ветке, только никто ответить не может

и плевать я хотел на совместимость