3D for Pistorm: Nuevos e importantes  avances.

El proyecto 3D for PiStorm, impulsado por Steffen Haeuser y con desarrollo técnico a cargo de Dennis, continúa avanzando con el objetivo de dotar a los Amiga equipados con PiStorm (Pi 4 o CM4) de una biblioteca 3D capaz de ser aprovechada por juegos y software compatibles. Tras un periodo prolongado sin novedades, la actualización más reciente confirma progresos importantes pese a los desafíos técnicos encontrados.
A diferencia de la GPU del Raspberry Pi 4, el chip gráfico VideoCore VI carece de documentación oficial completa. Aunque existe abundante código de ejemplo, especialmente procedente del proyecto Gallium3D, su complejidad obliga a desentrañar el funcionamiento interno mediante experimentación. Este factor ha condicionado el ritmo del desarrollo.
El equipo espera disponer en unas semanas de un primer ejemplo funcional. No se tratará aún de una biblioteca completa, sino de una prueba técnica capaz de generar binning lists y rendering lists, compilar código GPU en shaders y mostrar un resultado básico en pantalla, previsiblemente un triángulo coloreado. Alcanzar este hito confirmaría que la cadena de renderizado funciona correctamente.
Entre los principales obstáculos superados figuran diferencias en la organización de memoria entre generaciones VideoCore, cambios en el funcionamiento de la MMU, ya que VC6 utiliza direcciones físicas en lugar de direcciones de bus, problemas derivados del endianness frente al sistema big endian del Amiga y complicaciones relacionadas con el ensamblador QPU utilizado para shaders.
En el estado actual, el driver 3D genera pseudocódigo que se traduce a instrucciones ejecutables por la GPU, y la inicialización del driver ya está implementada, un proceso especialmente complejo debido a la escasez de documentación. El desarrollador estudia simplificar el flujo de compilación para adaptarlo a un único hardware, lo que podría reducir complejidad y mejorar el rendimiento.
Actualmente el trabajo se centra en las binning lists, cuyo código para el ejemplo está completado en torno al 90 %. Una vez finalizadas, se abordará la implementación de las rendering lists. Si no surgen nuevas complicaciones, este primer ejemplo funcional podría llegar en pocas semanas, marcando un paso decisivo hacia la aceleración 3D moderna en sistemas Amiga equipados con PiStorm.

Visita la página del proyecto <<—-

What kind of mishegus is this?
"There are ARM processors that have mixed-endian floating-point representation for double-precision numbers: each of the two 32-bit words is stored as little-endian, but the most significant word is stored first."

#floatingpoint #endianness

[Перевод] Переносимый код: Fighting the Lemmings

Сергей Каличев, старший разработчик, Angie Software Однажды, давным-давно, я наткнулся на одну хорошую статью по разработке переносимого кода и решил её перевести. Когда же это было... ё-моё, в 2008 году, 17 лет назад! Обалдеть, как время летит. Статья называлась "Fighting the Lemmings", автор Martin Husemann. Выложил перевод на LOR . С тех пор много воды утекло и, когда я попытался поискать статью в Интернете, то обнаружил, что ни оригинальной статьи, ни перевода, найти практически невозможно. Перевод ещё сохранился в глубоких закромах OpenNet , а оригинал только в архиве Интернета . Ссылки на PDF-ки тоже протухли и больше не работают. Обидно, это ведь такая нетленка для системщиков. Понятно, что переносимость уже сто раз пережёвана в других статьях и книгах, но тут всё было сконцентрировано и написано доходчиво. При этом актуальность до сих пор не потеряна. Ну а что, собственно, кардинально поменялось в разработке переносимого кода на C с тех пор? Если не обращать внимание на упоминания некоторых архитектур и ОС, которые сейчас, да и во времена перевода, звучат, как придания старины глубокой, то в остальном, обо всех особенностях разработки переносимого кода, описанных в статье, надо помнить и сегодня. Выкладываю текст, как он есть, без каких-либо современных правок. Для тех, кому удобнее читать в PDF, вот ссылки: PDF оригинальной статьи PDF перевода А теперь сама статья.

https://habr.com/ru/articles/890530/

#C #code #portability #переносимость #unix #linux #endianness #align #выравнивание #lemmings

Riding in this car across the countryside in Oman, I just had an insight that is a new argument in the little-endian / big-endian discussion:

Arabic numerals are little-endian!

A question I sometimes ask myself: why are our written numbers big-endian? That is, why start with the larger valued numbers on the left?

I confess, network byte order notwithstanding, that little-endian seems more natural for information processing because, if the number is written in a decimal-coded array, the array index corresponds to the power-of-10 (starting with zero, as God and Dennis Ritchie intended).

Our numbering system is sometimes called Arabic numerals, and this is because base-10 numbers were invented in Arabia.

What direction is Arabic script? Right to left! In the context of western script, our numbers are written backwards!

#endianness #arabic #oman

Little vs. Big: The Endianness War in Computing

#ComputerScience #Programming #SoftwareDevelopment #SoftwareEngineering #Endianness

https://link.intelligentcodecraft.com/56r9f

Address spaces are in ascending order, but for writing numbers, place value is in *descending* order. In my opinion, the little-endian byte order gets it technically right by having a consistent and logical order, just ascending. The big-endian byte order mixes the two, with addresses increasing but byte "place-value" descending.

#endianness #computing #ISA

Word for the weekend: #endianness

https://majornetwork.net/2024/06/endianness/