Перейти к содержанию
    

WitFed

Свой
  • Постов

    295
  • Зарегистрирован

  • Посещение

Репутация

1 Обычный

Информация о WitFed

  • Звание
    Местный
    Местный
  • День рождения 15.12.1969

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

3 112 просмотра профиля
  1. Интересное дело обнаружилось: https://en.wikipedia.org/wiki/Write_combining. В Intel и ARM давно есть, помогает писать в видеопамять пачками около 64 байт, предварительно собирая до кучи мелкие соседние записи. Как его применить к BAR памяти в драйвере Windows, подскажите. Читать быстрее оно тоже может помочь ?
  2. Да, для ПЛИС меня это и интересует, уже сколько лет мучаемся с тормозными разовыми обращениями. По 8, 16 байт оно, конечно, немного быстрее. Но "продвинутые" мосты пока не попадались, чтобы совсем до кучи слепить хотя бы запись. Она же эффективнее, чем чтение из самого устройства. В инете гуглилось, что в GPU данные закачиваются медленнее, чем выгружаются обратно, это лишнее подтверждение, что там на борту тоже своё DMA. Реализация DMA в плате у нас в конце концов и делается, но это криво, с моей точки зрения. Какие могут быть разумные аргументы для отсутствия в архитектуре Intel прямого DMA для любых пересылок, и в первую очередь -- записи наружу ? Пнул и отвлёкся, ещё кого-то стартовал через FIFO запросов большой глубины, занимаешься другими добрыми делами, а потом как-то узнал, что всё закончилось.. Это же очень удобно. В https://electronix.ru/forum/topic/174010-api-dlya-bystrogo-kopirovaniya-bolshih-obyomov-dannyh-v-ustroystvo-dma/ я спрашивал -- там знатоки молчат. В книге Guk-M.-Entsiklopediya.-SHiny-PCI-USB-i-FireWire-2005.pdf прямо сказано: Т.е. мы в устройстве на чтении даже не знаем, какая будет длина транзакции, открываем страницу и читаем сразу большой кусок памяти, а начинаем отдавать -- и после первого обмена облом. Похоже, это только со стороны Intel осмысленная недоработка, которую легко исправить, учитывая обычную сверхсложность решений этой фирмы, просто ещё добавить арифметики в реализацию REP MOVS*. Мы же знаем сразу, какой объём последовательных данных предстоит передать, и по аналогии с обращением через SSE/AVX регистры можем подать в PCI запрос W/R именно на этот размер. Доброе дело тормозится по политическим причинам, как обычно ? А другие архитектуры бывают посолиднее ? В PCI Express тоже всё нормально в архитектуре заложено, там копия PCI, для совместимости. Большим пакетом можно всё сложить и послать при записи REP MOVS*, а на чтении -- один пакет запроса с общей длиной и обоими адресами. Или как ?
  3. К конкретному устройству привязываться неправильно, даже если его и расковырять, нужен стандартный метод. В книге "Михаил Гук. Интерфейсы ПК" в разделе "6.2.5. Пропускная способность шины" про PCI говорится, что: > при записи массива данных в устройство PCI (передача с последовательно нарастающим адресом) мост может пытаться организовать пакетные циклы. > продвинутый мост может пытаться собирать в пакет и последовательные запросы, что может породить пакет существенной длины. Если использовать "REP MOVSD", где счётчик повторений известен, то современный процессор порождает burst операцию, кто-то пробовал ? Скорость памяти обычно гораздо больше, чем в шине, подгрести должно успеть.
  4. Обидно. Всем нужно, у всех есть, и никто не хочет "вынести за скобки" или поделиться. Видеокарты ведь качают большие объёмы данных к себе и обратно, как GPU. Это тоже всё изнутри делается, а не снаружи, от CPU, только по его командам ? И никакого API не экспортируется для любой пары физических адресов ?
  5. Народ, за 15 лет произошли какие-то сдвиги ? Появилось системное средство, чтобы без самописного DMA что-то быстро (burst-) писать/читать в PCIe ?
  6. Много лет проблема стоит для Windows. (И для Linux тоже.) Запись в память устройства по PCI ещё как-то устраивает через оптимизированный код в memcpy(), где применяются команды по 8 и 16 байт за такт. А вот читать уже на порядок медленнее, даже порциями по 16 байт, там хочется слепить соседние запросы в burst-транзакции, чтобы стало похоже по эффективности на запись. В идеале -- надо запустить свободный системный канал DMA (их масса на материнке) "туда" или "обратно", самому заняться другими делами, а по готовности операции уже вернуться обратно на готовое. Наверняка кто-то уже решал подобную задачу. Или MS где-то припрятала такой функционал ? Базовая вещь. Физические адреса в устройстве есть, они непрерывные. У нас в памяти виртуальные непрерывны, а физические попутаны, как ОС раздаст, но с этим ядро ОС разбирается хорошо. К физическим и вообще аппаратуре не подпускают из верхнего уровня приложений, нужен драйвер. Писал уже кто-то такое "на продажу" ? Чтобы не ходить по граблям в 1000...-й раз, вызвать функцию волшебного драйвера и забыть...
  7. Да, была такая функция, но в силу видения "выстрелов в молоко" не сильно верится в её использование. Хотя и в мою дееспособность тоже, 😉 если ни у кого таких проблем больше нет. Вот примеры обёрток: ULL FParamUnit = (ULL)&pUM_local; // Структура с параметрами модуля, это указатель, его память вернута из драйвера, обращение к ней в отладчике почему-то вешает ПЛИС, потому обёрнуто функциями WCHAR* get_HardwareId() { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->HardwareId; } ULONG get_vBarMem_Count() { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->vBarMem_Count; } DEF_DLL_EXP(ULL) get_vBarMem_Size(ULONG i) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->vBarMem_Size[i]; } ULL getPhis(ULONG i) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->memBase[i]; } ULL getVirt(ULONG i) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; return pu->pBarMem_Virt[i]; } int /*bool*/ isBAR(ui bar) { PPARAM_FOR_USERMODE pu = (PPARAM_FOR_USERMODE)FParamUnit; if (!pu || bar >= pu->vBarMem_Count) return 0; return 1; } pUM_local -- статическая переменная, её заполнение идёт в ините устройства по памяти, выданной нашим драйвером, со всеми добытыми нужными потрохами. Её адрес кастуется в длинное целое, в обёртках выкастовывается обратно, идут чтения и возврат значений. Память эта точно локального процесса, но степанье отладчиком в районе вызовов "стреляет" и регулярно вешает всё, файлы регулярно портятся. Там в структуре есть физические и виртуальные адреса, они разыменовываются после получения в других функциях типа: ULONG getUL(ULL a) { PULONG p = (PULONG)a; return *p; } void putUL(ULL a, ULONG d) { PULONG p = (PULONG)a; *p = d; } ULL getULL(ULL a) { ULL *p = (ULL*)a; return *p; } Но "стреляет" и виснет даже не возле них, а возле первых, вызовы типа: ULL pB = getVirt(barR) + ofsR; Что заставляет Студию лазить адресам, соответствующим целым числам, совсем неясно. Типа очень крутой ИИ, прослеживающий всё на "годы вперёд" и без Релиза, что потом из pB будет скастован указатель, который можно нам показать "ради удобства" незаказанного, или что-то ещё... И обращения не в саму эту память, а рядом или "в молоко", хотя и повторяемое от зависания к зависанию. Незря нам Илон Маск (++) предлагает нейросети запретить. Даже если кнопку "Выкл" к ним прикрутишь, а они её изнутри отгрызут 😉
  8. Ура, Мышка по делу высказалась. СпасиБо за отзывчивость. Паранойи и менеджмент/маркетинг давайте отбросим, это диавольский перемудрёж, как и вся система драйверов у MS, нам хотя бы детский функционал отладить, W/R регистров и памяти, а хаканье оставить имеющим больше мозгов и проблем от них. Сегодня на другой плате та же беда -- с точками останова и степаньем по коду виснет всё напрочь, даже кнопка резета не помогает. Без отладочных действий, но из Студии по F5, всё работает чисто, и нет ни одного окна, которое можно заподозрить в подсмотрах, и указателей тем более на уровне степанья. Т.е. скомпилированный код сам чист. В поддержку MS писать бес-полезно -- старые Студии они патчить не будут, а в новых столько других проблем, что там эта решённая никого не спасёт. Только ключик вдруг кто-то вычитал и знает об редуцировании избыточных сущностей. Сколько любители усложнений на 2-3 порядка ни думают вширь, всё равно вирусов и хакеров меньше не становится, а дырок -- только больше, ибо путь тупиковый. И всё в зверски мощных гаджетах больше и больше тормозит, что есть маркетинг, основа демо-жизни. Норушка, есть ещё одно лекарство, но я от своих желязячников его никак не добьюсь за 10+ лет: чтобы запросы чтения в общую шину всегда возвращали хоть FF, и хоть через секунду, это недорого, как бывает обычно устроено в сильнее развитых архитектурах. Когда-то жареный клюнет наконец, качества и надёжности захочется не только на словах. MS на этом свойстве Intel базируется, исключения у них могут происходить при обращении не туда, а когда у нас "собирающий" и "окружающий" массу содержимого блок не отвечает за "небазар" своих подчинённых, мы потом неделями отлаживаемся и ловим неописаные глюки отладчиков, в которых логику ещё надо найти.
  9. Макс, это очень серьёзное заявление. Надо подкрепить логикой и конкретикой, чего мы должны бояться. Хотя это уклонение в сторону от нити топика. Если имеем физический адрес BAR-а в драйвере, отобразим его в виртуальный и дадим пользовательскому уровню для обращений к своему устройству, то что может пользователь поломать больше драйвера в своём устройстве ? Конечно, если другое устройство или чужую память нам дать потрогать, мы сможем грязно у кого-то в огороде потоптаться, но и драйвер может то же самое, если захочет, и с гораздо большими правами. И отлаживаться там гораздо сложнее, в ядре, дров можно наломать. ...Т.е. никто с такой проблемой "заступов" в продуктах MS не сталкивался ? Продолжать винить себя можно, искать свои глюки, но сильно непохоже. Записей таких левых пока не встречалось.
  10. 😉 Драйвер нам вначале всё выдал, а потом мы его трогаем в конце, чтобы отдать ресурсы обратно. Или вообще не трогаем, если программа завершается неожиданно. Хотя там тоже что-то ОС вызывает у драйвера, чтобы автоматически отключить устройство. Макс, подскажи(те) или ссылку дай(те) на теорию, как у вас глобально всё организовано, если вся работа повешена на драйвер. по-штатному. У нас используется концепция, что драйвер под Винду -- дело жуткое, переусложнённое, небезопасное, и отлаживаться внутри в ядре в тысячах строк кода вдобавок к драйверным и по шагам ходить -- смерти подобно. Для того MS с Intel и вводили много уровней привилегий и сертификацию драйверов, чтобы самые опасные действия были под максимальным контролем. Потому у нас в своём драйвере что-то как-то давно наляпано и отлажено, которое открывает наш девайс, ворует у Винды все BAR-ы и маппит их адреса phis/virt, передаёт на уровень MS VS особым запросом, и там всё в шоколаде для прикладного программиста, порушить уже что-то сложнее. Закрывается устройство -- всё размапливается и отдаётся системе, никаких признаков проблем не было. Вот кроме этих спорадических "прилётов" от отладчика, зависящих от траектории хождения по исходнику и портящих жизнь на начальных этапах оживления и разборок, пока всё не полетит. Вряд ли портятся маппинги, ибо в BAR-ах всё (память и регистры) работает глобально чисто, пока не закроем девайс. Это у MS (догадываюсь) просто записей по дефолту никуда нет, ибо дело опасное, а любые чтения для своих окон отладчика из любого региона они считают несмертельными, потому много подсматривающих недоотлаженных чтений, которые нам без теории объяснить невозможно -- и когда все-все окна закрыты, всё равно что-то выстреливает и мешает. В очередной раз хочется настройку "Выключить весь интеллект", ибо регулярно он перемудривает и мешает.
  11. Вин7 сейчас, драйвер выдал отмапленный адрес BAR-а AC0000 в моё пространство адресов размером 4 М. Просто читаю из VS.2012 по указателю, сформированному из базы виртуального адреса и смещения внутри. Но глючит не при обращении в BAR -- оно честно происходит, а где-то рядом. Прилетают или чтения по 4 байта из адресов 18, 10, 08, или из какого-то мусорного типа В31870, в зависимости от места, но первые 3 чаще. Это автор прошивки видит в ЛА. В принципе, там выше/ниже в памяти всё от моего процесса, стек, данные, код, но пересекаться они не должны. Тем более, что обход "страшных" мест выше уровнем всё нивелирует. Из Убунты на другой плате ребята тоже "делали" 4 чтения, которых не хотели -- VS Code. Долго разбирались, концов в коде не нашли, тем более, что дизассемблера там нет, и с ним всё тоже у меня меняется...
  12. Перекиньте этот запрос в более подходящую ветку, если я пока что не нашёл её. Наверняка, с этим уже кто-то сталкивался и как-то порешал. Глобально -- есть устройство на PCI, управляемое через ПЛИС, ты ходишь в тестовом ПО по шагам, и в BAR-ы прилетают обращения R/W по дурацким адресам, которые ну никак не следуют из кода исполнения. Ассемблер смотришь -- нет там ничего опасного. Но виснет регулярно напрочь, ибо это не предусмотрено алгоритмами работы. Если обходить это место выше уровнем функций, то ничего страшного не происходит. А чем ближе к железу опускаешься, тем вероятнее встретить эти "выстрелы", которые, в принципе, повторяются, но адреса у себя найти не выходит. И в MS VS это бывает под Винду, и под Линуксом в MS Code, лет 10 точно эффект встречается, во всех версиях отладочного ПО MS. Не помогает удаление Autos, Locals, Memory, Call Stack, чтобы на каждом шаге отладчик не лез по записанным там адресам, которые, в принципе, и не глядели в наш BAR. Отладить отладчик -- дело немыслимое, но вдруг ключ в опциях кто-то нашёл, который выключает "левый интеллект" у него ? В старших MS Студиях я видел оценку времени исполнения следующей строки кода, это как-то заставляет отладчик "помудрить", но и в младших попроще всё падало давно. Какие методы лечения наработаны ? Оно же левое не предусмотрено никакими ТЗ, читает/пишет, что захочет, и нарушает алгоритм функционирования.
  13. Я попробовал ещё одну версию "Xilinx_Vitis_2019.2_1024_1831.tar.gz" из закромов, Alt-Left не полегчало. А была "Xilinx_Vitis_2019.2_1106_2127.tar.gz". Накатывал Xilinx_Vivado_Vitis_Update_2019.2.1_1205_0436.tar.gz, тоже плохо. Решил завязать с "мантрами". Убито времени много и так. Как видно, все требования у Xilinx огульные, если они их потом не проверяют. "Xilinx_Unified_2020.2_1118_1232.tar" точно у меня ставилась на 7-ку, и работала. Видимо, в требованиях пишут то, на чём запускалось и пробовалось немного в самой фирме Xilinx, политически решённое. Ругаться не будем, хоть что-то хоть как-то дышит... С Покровом Пресвятой Богородицы !
  14. Спасибо. Да, шаманство в наших переусложнённых системах, не особо удачно пытающихся объять необъятное, встречается регулярно. Прямой путь отладить им легче, он чаще встречается. Когда начинаешь ставить, оно пишет про необходимость Win 7 64 бита, но не знаю, проверяет ли. Win 7 стоит точно, SP 1. Это же и есть нужная 7. 1 ? Тем более, пускается там всё с первого раза. Но глюки у меня тоньше, тупиковые. У них такое регулярно -- закройте типа все приложения наши, и жмите "дальше", т.е. нет автоопределения запущенности, это тяжело. SSD -- это хорошо, но просто ускорит частоту метаний в поисках Alt-Left. Глюк какой-то более хитрый, если то работает, то пропадает. Глобально первая 2019.2 быстро компилила чужой проект МикроБлэйза, хотя мне обещали полчаса. В реестре я что-то почистил с "Xilinx", "Vivado", "Vitis", хотя есть подозрения, что в Линукс-подобных системах всё в основном лежит в файловой системе. В "C:\Users\я\.Xilinx\" тоже много было остатков, имена каталогов всех былых WS точно сохранялись после деинсталляций, убил всё. Может, и переставляться не надо, если знать, где настройки сидят ? И ".lock" пара была, хотя сообщений о недожидании их не выводилось в больших посмертных логах Java. И 2018.2 тоже находил в именах каталогов, но вроде уже сносил её перед 2019.2. С Альтерой могут не дружить Ксайлинксы ? У меня старые Эклипсы для Ниос так и не запускаются, для них Java не находится, хочет каталог 17-го Квартуса, которого давно нет. Это явно не конфликт с Альтерой, если она сама у себя запротиворечила. ...Вот поставилась после всех чисток в очередной раз 2019.2, проект сразу из примеров создал, Alt-Left не работает, но живое. Наверное, лучшее -- враг хорошего.
  15. Похоже, сносить тоже нельзя, оно уходит в нечистое состояние, что-то помнит после себя. Вчера оба инсталла официально снёс, не запускался из них только 2021.1. Сегодня Vitis 2019.2 заново поставился, и не работает. Висит процесс Eclipse.exe, 25 % кушает, и молчит. Ещё раз пускаешь -- ещё один на 25%... Поначалу бывает и 70 %, но потом ровно 1 проц занят, это на полчаса, потом глобально плачет, что не вышло, имя лог-файла сообщает, но там непонятный стек вызовов Java, общая "!MESSAGE Application error". Похоже, у Xilinx спецы больше по ПЛИС, чем в тестировании установки и удаления. Думаю, какие ещё идеи могут быть, чтобы 2019 ожил...
×
×
  • Создать...