| |
| 2.7, NGAGE13 (ok), 19:23, 28/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
 такое чувство что теперь все принялись кровь из носа писать маленькие высокоэффективные патчи!!=)
| | |
| |
| 3.25, Ян Злобин (ok), 07:14, 29/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
 >такое чувство что теперь все принялись кровь из носа писать маленькие высокоэффективные патчи!!=)
Так это ж здорово!
| | |
| 3.26, Andrey Mitrofanov (?), 12:00, 29/01/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Такое впечатление, что все аж поражены в пятку Великим Открытием, мол, Йо-майО, что ж мы написали!, куда не ткнёшь (50-строчным патчем), оно просто ни с того ни с сего начинает работать вдвое быстрее.
>) | | |
|
| 2.14, funky_dennis (ok), 20:54, 28/01/2011 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Там на самом деле значимых строк всего 20, остальное это sync с измененными структурами. Если пустые строки удалить, и того меньше будя
| | |
|
| 1.2, Аноним (-), 19:10, 28/01/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Объясните кто-нибудь на пальцах - что это значит для конечных пользователей?
И что значит непрямой рендеринг без обращения к dri?
| | |
| |
| 2.11, gkv311 (ok), 19:37, 28/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Это означает что патч бесполезен для _большинства_ пользователей, так как домашние пользователи использую 'прямой' рендеринг, а использование непрямого рендеринга по сети возможно только в узкоспециализированных задачах из-за множества ограничений.
| | |
| |
| 3.19, Andrew Kolchoogin (?), 00:27, 29/01/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Не совсем так: Compiz (даже локальный) не умеет работать через DRI (точнее, не то, чтобы не умеет, архитектурно нельзя так сделать).
Но и через GLX он не работает -- он работает через AIGLX (Accelerated Indirect GLX). А вот ускоряет ли этот патч и AIGLX тоже -- фиг знает...
| | |
|
|
| |
| |
| 3.10, shatsky (?), 19:36, 28/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Угу, NVGLX. Хотя, если это решение действительно свежо и эффективно, они наверняка запилят аналогичное в следующей версии.
| | |
| |
| 4.30, Аноним123321 (ok), 22:58, 31/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
 считайте что уже залепили :-) ... так как ведь сёравно вы никогда не узнаете что там в исходных кодах от этого блоба :-)
| | |
|
|
|
| |
| 2.9, alex789 (?), 19:34, 28/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
например, когда запускаешь 3d приложение по сети (тот же компиз...) - очень полезно для тонких клиентов)))
| | |
|
| 1.12, Аноним (-), 19:52, 28/01/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Эх ..этот патч бы пару лет назад, когда на драйверах интела и r300 не было GLX_EXT_texture_from_pixmap при прямом рендеринге. Т.е. тогда компиз работал с непрямой отрисовкой.
| | |
| 1.13, axe (??), 20:39, 28/01/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
очевидно профилированием кода иксов _никто_ _никогда_ не занимался. А что с другим открытым кодом? Это печально. Иногда я начинаю сомневаться в опенсорсе (на пару микросекунд после чтения таких новостей)
| | |
| |
| 2.15, ананим (?), 21:22, 28/01/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>очевидно профилированием кода иксов _никто_ _никогда_ не занимался. А что с другим открытым кодом? Это печально.
сколько много слов вы знаете, а правильно применять их так и не научились. это печально.
| | |
| |
| 3.16, Толстый (ok), 21:37, 28/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Как будто то что сказал автор исходного сообщения так удивительно, что надо это подвергнуть сомнению и обосрать.
| | |
| |
| 4.18, ананим (?), 22:29, 28/01/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
это не удивительно. это просто тупо.
т.к. никакой профилировщик не датст ответ в стиле "тут необходим кэшь при индексировании результатов операций декодирования GLX-опкода при условии операций непрямого рендеринга".
профилировщик вообще никогда не даёт ответы по лигике работы алгоритмов.
| | |
| |
| 5.20, pavlinux (ok), 01:38, 29/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Он даст ответ на то, что в каком-то месте функцию вызывали 3000 раз за минуту,
тогда как остальные по 500.
| | |
| |
| 6.21, ананим (?), 02:49, 29/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
какие остальные? может так и должно быть? :D
чтобы иметь с чем сравнивать, нужен эталон. другими словами - никто и не догадывался, что может быть <3000. кэширование в коде как раз относится к ручной оптимизации. как и выбор оптимального размера буфера и тд.
профилировщик выдаст только критический участок кода с повышенной нагрузкой на цпу, а оптимизировать его уж будьте любезны сами. опять же, выполнение проги до 1-го такта несоптимизируешь. на каком-то этапе останавливаешься и говоришь - всё, лучше не будет.
вон в висте аеро тормозила из-за 2-ой буферизации. в 7 убрали и можно даже пользоваться.
| | |
|
|
|
|
| 2.17, fr0ster (ok), 21:56, 28/01/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Тут иногда в проприетарном и очень платном софте парой строк увеличивается не слабо производительность. :)
| | |
|
|
