1. C++ / Говнокод #7760

    +169

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    inline float _read_zbuf(int x, int y){
  float v;
  glReadPixels(x,screen.height-y+1,1,1,GL_DEPTH_COMPONENT,GL_FLOAT,&v);
  return v;
}

    >Для определения жизни под мышкой решил использовать изменение значений в буфере глубины, но glGetPixels уронил мне фпс на 300, и это один вызов финальной проверки, а что будет когда объекты проверятся начнут подумать страшно.
    Неужели все так плохо ??? 

    http://www.gamedev.ru/code/forum/?id=151921

    Запостил: CPPGovno, 03 Сентября 2011

    Комментарии (18) RSS

    • ava CPPGovno 03.09.2011 16:49 # +1

      Когда увидел этот код, то уржался...
      Традиционно видеокарты рендерят сцену параллельно с процессором. Процессор готовит данные на несколько кадров вперёд, а видяха судорожно рисует в это время.
      А тут чел один пиксель решил после рендеринга прочитать.
      Проц, естественно, теперь ожидает окончания рендеринга текущего кадра, вместо того, чтобы готовит данные для следующих кадров.
      И это при том, что пока видяха не предназначена для обратной пересылки данных от неё в RAM или CPU. Тк обычно ей приходится отправлять только на VGA выход и такое применение пока не предусмотрено.
      Естественно, чтение из видеопамяти, CPU'шкой происходит без кеширования.
      Ответить

      • ava Esper 03.09.2011 18:46 # +1

        Пара заметок по последним двум абзацам. Память видеокарты - обычная PCI-память, доступная процессору по чтению и записи. Извращенное применение этому см там -> http://en.gentoo-wiki.com/wiki/Using_Graphics_Card_Memory_as_Swap. Записать в оперативную память видеокарты вроде тоже способны. ЕМНИП относительно недавние мобильные решения отбирают кусок оперативки для своих нужд: своей памяти у них было мало.
        Если бы доступ процессора в видеопамять происходил кэшируемо, то нужен бы был протокол поддержки согласованности кэшей процессора с видеопамятью, а это - танцы с присиданиями, которые кушают пропускную способность шины, на которой сидит видюха, и замедляют ее доступ в видеопамять. Также если бы таковой протокол был поддержан, то данные в кэшах процессора оказались бы полезны только если "кадр" лёг по старым адресам и старые данные не были перезаписаны видюхой. В противном (и наиболее вероятном) случае - промах по кэшу и сбор latency от CPU до видеопамяти. Кэширование тут бесполезно.

        А код - пример закручивания гвоздей отверткой.
        Ответить

    • ava CPPGovno 03.09.2011 22:10 # +5

      >Поднял свою мышку, разумную жизнь под ней не обнаружил. :(
      Ответить

      • ava jokz 04.09.2011 23:50 # +5

        я обнаружил:(
        Ответить

        • ava ctm 05.09.2011 06:48 # +1

          а как же ее надо искать? я 30 раз поднимал мышку и ничего там нет!
          что я делаю неправильно?((
          Ответить

        • ava CPPGovno 05.09.2011 22:31 # 0

          >я обнаружил:(
          И как? Разумная?
          Ответить

      • ava Lure Of Chaos 05.09.2011 12:24 # +1

        В микроскоп видна такааая жизнь.... Что аж стыдно :)
        Ответить

      • ava roman-kashitsyn 05.09.2011 12:54 # +4

        Думается, под внутри клавиатуры разумной жизни должно быть больше - там хотя бы есть чем питаться...
        Ответить

    • ava CPPGovno 29.09.2011 23:54 # 0

      Приятно видеть, что на говнокоде есть люди, знающие не только верхний уровень, но и способные понять шутку с нижнего.
      Ответить

    • ava carsten 01.10.2011 23:58 # 0

      glReadPixels известна тем, что очень тормозная, как было сказано выше товарищем Говном, из-за того, что процессор простаивает, ожидая ответа видеокарты, чего обычно не случается при обычном рендеринге, т.к. драйвер кеширует команды отрисовки внутри себя без ожидания ответа карты, и отсылает их видеокарте скопом изредка лениво так. Курить ман по glFlush.
      Ответить

    • ava guest8 09.04.2019 11:27 # −999

      показать все, что скрытоvanished
      Ответить

    Добавить комментарий