Свежие комментарии

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

А я вот думаю, выполняем мы контекстное переключение, ну там всё сохранили, регистры там дескрипторы памяти, а вот восстановить мы же можем на любом ядре, например с хорошим кэшем (который эту область закрывает) и типа они так все по кучам и расползутся, это наверно из области фантастики, или нет?

Хм...

в таком случае, не может ли ей не хватать в тенях точности?

Знаете, я ничего не настраивал и не изучал, оно как-то само заработало. Хотя, да, если слетел видеорежим - то никакого решения, кроме подъема из бэкапа - я не знаю.

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

Потом я не говорю, что что-то у меня не работает просто хочется использовать время на работу, а не на настройку и глубокое изучение системы.

Кстати, я тут всё анализирую текст libraw, и вот увидел, что интерполяция производится после гамма коррекции.

Что, конечно, огорчает - получается, что полная энергия снимка не сохраняется, и линейность ползёт.

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

Там еще остается непонятность с FPU.
Было - 3 универсальных юнита (x87, integer SSE, float SSE) на ядро.
Стало 2 целочисленных + 2 FPU юнита на "HT-процессор".

Т.е. задачи FPU-only или int-SSE-only должны заметно просесть, даже если нормировать не на число формальных ядер (2 на модуль), а на число модулей.

эх, когда уже apple сподобится сделать, что-то не такое дорогое, как mac pro думаю с такой концепцией никогда :(

Я же вот беру арстехнику, там схема: на два ALU есть 2 MMX-модуля и 2 128-битных float.

Если считать это за "два FPU" (на два ALU), то в предыдущих оптеронах их было три (на один ALU). Собственно, вот цитата

Each K10 core had three 128-bit floating point units. These could perform x87 scalar floating point, 128-bit SSE vector floating point, 64-bit MMX vector integer, and 128-bit SSE vector integer operations. Bulldozer has four units in its floating point pipeline. Two are for integer operations (64-bit MMX and 128-bit SSE); the other two are for floating point. In addition to the scalar x87 and vector SSE instructions, the two floating point units can be ganged together, to perform new 256-bit Advanced Vector Extensions (AVX) floating point instructions. Given that this pipeline is now shared between two threads, it's a big reduction in per-thread execution resources.

Как это еще понимать то?

Ну да, но там нужна поддержка бульдозера, чтобы это было правильно.

Тут есть нюанс: пропадает возможность выбрать наиболее удобное/резкое субпиксельное смещение, в результате придётся выбирать между размытием и артефактами.

На самом деле нужна - 50% масштабирование бикубиком из VCD сильно лучше чистого Half по большинству параметров (больше деталей, меньше ореолов). Очень хотелось бы увидеть исследования в области демозаики изображения с уменьшением, т.е. алгоритм который производит нечто между 50% и 75% изначально и выдает разрешение которое гораздо ближе к истинному чем мифические 100%.
А что до "не парятся" - это отдельный вопрос как мне кажется. У меня сложилось впечатление что в любой индустрии вообще париться не принято. Очень много усилий уходит на поддержания паритета с конкурентами и попыток сделать что-то радикально лучшее никто особо не предпринимает - все равно враги скопируют очень быстро и все вернется на круги своя :)

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