Большие рисунки в памяти - Форум на исходниках

WWW.ИСХОДНИКИ.РУ cpp.sources.ru

java.sources.ru web.sources.ru soft.sources.ru

jdbc.sources.ru asp.sources.ru api.sources.ru

  Форум на исходниках
  C / C++ / Visual C++
  Большие рисунки в памяти
СПРОСИТЬ  ОТВЕТИТЬ
профайл | регистрация | faq

Автор Тема:   Большие рисунки в памяти

mtdr опубликован 25-12-2001 14:45 MSK
Кинте идею насчет того, как создавать большие рисунки в памяти (10000х15000) глубина около 300dpi!! Завал!!!!!
Vovan опубликован 25-12-2001 14:49 MSK
Нужно что бы рисунок загружался в память не полностью, а динамически из файла, но это будет медленно работать!
Flex Ferrum опубликован 25-12-2001 14:52 MSK
Если самый простой вариант - то filemapping спасет отца русской демократии. Кстати, объем не такой уж и большой - "всего" ~430 mb. Единственное ограничение - одновременно сможешь работать только с двумя (от силы с тремя) такими картинками.
Более продвинутый вариант - организовывать свой механизм свопа. Вариант более правильный, но на реализацию и отладку уйдет уйма времени.
Vovan опубликован 25-12-2001 14:56 MSK
Ну да я тоже про своп говорю! Но нужно набить гиморрой или поставляй вместе с программой модуль 512 Mb оперативы :)
А зачем тебе такие рисунки если больше одного и на CD не влезут?!
Vovan опубликован 25-12-2001 14:58 MSK
А я понял, ты решил написать игру-стратегию, когда я был маленький я тоже думал что там используеться большой рисунок но это не так :(
mtdr опубликован 01-02-2001 11:23 MSK
Всем спасибо. Все гораздо сложнее. Пишу прогу для работы с графикой. На выходе нужен такой документ. Вот я тут и встрял. Перерыл уйму лит-ры, но ...
x опубликован 01-02-2001 22:03 MSK
FileMapping это не очень хороший вариант т.к. дает маздаю возможность свопить
Flex Ferrum опубликован 01-02-2001 23:43 MSK
А так и так будет свопить... Только в случае простой загрузки в память это будет выглядеть как:
File <-(read)-> Memory <-(swap)-> SwapFile
А во втором
File <-(swap)-> Memory.
Разницу чувсвуюешь?
x опубликован 02-02-2001 11:55 MSK
угу=во втором случае я могу ему запретить свопить
SUnteXx опубликован 02-02-2001 00:58 MSK
2x:
запрещай - дело твое:) Программным путем или как будешь запрещать?
А запуск прог или запуск выньды не запретишь!:? Дос форева? Или линух? или юних? Что тебе больше нравится?
Stiff опубликован 02-02-2001 13:40 MSK
А можно попдробнее или ссылку что есть FileMapping а то я не нашел в MSDN :-(
Flex Ferrum опубликован 02-02-2001 14:10 MSK
Stiff:
Позор на мои седины. :))) OpenFileMapping, MapViewOfFile, CreateFileMapping и т. д., и т. п. Или, проще говоря,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/filemap_0583.asp
( MSDN Home > MSDN Library > File Storage > File Mapping > File Mapping Reference )
Flex Ferrum опубликован 02-02-2001 14:13 MSK
x:
Это я к тому, что в первом случае ты копируешь из файла в своп, а во втором - сразу в память. Разница есть? Своппить ты так или иначе будешь (если памяти ни гигабайт).
Student опубликован 02-02-2001 15:07 MSK
А может через DirectX ? Он же "крутой"...
Shader опубликован 02-02-2001 19:34 MSK
Фигу с ДиректХ. Там два типа сурвейсов... одни это в видео памяти ! размером не больше чем тек. разрешение экрана (вроде), а вторые в системной памяти. Но те, вроде больше 2048 на 1024 (где в этих пределах) не создашь. он кончено крут, но для таких изварщений -)
x опубликован 02-02-2001 20:52 MSK
to SUnteXx & Flex Ferrum
механизм страничной адресации работает не быстро,совсем не быстро и если не выделять память самому то маздай ее раскидает как придется в Physical Memory=
сие значит следующее=твой файлец будет сильно или не очень=но фрагментирован в Physicsal Memory
далее значит что чипсет не будет переходить в burst mode при работе с ним
ЭТО ЗНАЧИТ ЧТО ТЫ ПОЛУЧИШЬ НА МЕСТАХ СТЫКА СКОРОСТЬ 100-200MB/Sec вместо 800 при пакетной передаче
я думаю мне не надо объяснять что мы конкретно упираемся в производительность памяти даже при скорости 1GB/Sec
Flex Ferrum опубликован 03-02-2001 00:30 MSK
Правильно ты сказал. Механизм страничной адресации работает не быстро. Но!!! Процессор оперирует страницами по 4 кб. Ему пофигу - расположены они рядом или на расстояении в 128 мб. Шина адреса имеет ширину в 32 бита. Отсюда вывод - с точки зрения процессора, находящегося в режиме страничной адресации линейной памяти абсолютно все равно - на сколько фрагментирована выделенная тобою область памяти. Адресация идет в любом случае через таблицу страниц. И насколько близко или далеко они расположены - не имеет значения. Скорость будет одна и та-же. ИМХО, конечно...
x опубликован 03-02-2001 00:35 MSK
ты знаешь что такое burst mode ?
x опубликован 03-02-2001 01:16 MSK
cудя по всему даже если знаешь то не представляешь насколько она важна
1.процессор и его внешняя шина работают в асинхронном режиме
2.ширина шины проца может и не совпадать с шириной шины памяти
3.отсюда значит и чипсет и/или имеет буфер запросов (обычно это L3/L2) и/или работает в асинхронном режиме RAM<=>CPU (ex KT7A)
4.что есть burst mode=пакетный режим передачи при котором адресная шина инкрементируется не ожидая запроса от CPU и сразу читается новая порция данных
5.при отсутствии burst mode но при последовательном чтении чипсет один такт страдает X потому что ждет адреса
6.при случайном хоть и страничном доступе получается еще хуже= тайминги SDRAM 3-1-1-1
сие значит что на активацию столбца у тебя уйдет не менее 3 тактов=значит в среднем 4-5
7.идем далее=размер строки кэша обычно >32байт =типично 128= и как показывает приктика гнусная железяка ждет ПОЛНОГО заполнения строки L1 прежде чем сможет к ней обратиться
8.L1 крайне мелкий и ты получишь еще FUN вытеснения данных из кэша
как показывает практика такие вот мелочи поднимают скорость демок раза в 2-3
P.S:надеюсь я достаточно ясно выразился?
SUnteXx опубликован 03-02-2001 01:21 MSK
2x:
Картинка 10000х15000х32 = 572.2Mb! Легче самому свопить, а то у меня ограничение на своп стоит (около 256Мб)! И что ты сделаешь в таком случае? А если битмапа на винте не поместится, как быть?
ФотожоП жрет дох места на винте, причем свопит сам, а его кодили не л%хи, так почему не сделать так же? Будет медленновато, но зато будет, чем них ни памяти не будет, ни винта, ни свопа, ни нормально работающей проги...!)

2mtdr:
А сколько там цветов в битмапе? Может если строчки как-нить совмещать (к примеру, если 15, 17, 281 и 293 строчки совпадают, то савкать в своп в своем формате, что в начало новой строки савкается похожесть на одну из строк... или что-нить вроде того, или с кусками строк, ...?)
ЗЫ
Лучше всего, имхо, савкать на винт самому, а потом просто считывать нужный кусок битмапы, иначе заебе%%ся (с мягким знаком)!
x опубликован 03-02-2001 02:01 MSK
собственно что свопить надо самому я считал очевидным
wizzy опубликован 03-02-2001 18:28 MSK
Мне пришлось как-то печатать в файл битмапы и побольше. Очень выручает печать по частям. БМП так устроен, что если его печатать хитро по частям в обратном порядке, то получится правильное изображение. Так что выделяешь стандартный 32м битмап, "сканишь" им все изображение и дописываешь в файл.
Flex Ferrum опубликован 03-02-2001 22:45 MSK
x:
Все это интересно, если ты пишешь демку. В демке картинки по 500Мб врядли используются. И потом - эти 500 Мб ты не уложишь в память без фрагментации - система возьмет свое. Приложение не одно, все они свопятся и т. д. и т. п. Отсюда вывод - либо организовывать "системный" своп через FileMapping, либо свой собственный. Я в свое время пошел по второму пути. Это в данном случае более грамотно. У больших картинок есть своя специфика хранения. Практически все они хранятся тайлами определенного размера (обычно выбираются степени двойки). Пример таких форматов - TIFF, JFIF. В последнем случае каждый тайл жпегуется. Формат BMP для таких картинок практически не применятся (из за своей специфики хранения).
Так вот, в этом случае очень удобно организовывать кольцевые буфферы, в которых изображение подкачивается так-же, как и в описанном x'ом режиме burts mode - то есть с предсказанием.
Manyak опубликован 03-02-2001 23:27 MSK
ну уж чего я непонимаю, так если у тебя файл на выходе ну и пиши ты его целиком на хард. А дальше с харда подгружай только тот кусочек который тебе надо. Если еще в правильном формате будешь писать, а не bmp, то вообще все должно неплохо работать. А реализация в принципе не очень сложна если уж так подходить...
x опубликован 06-02-2001 06:40 MSK
я собственно не настаиваю
просто изложил специфику данного вопроса как я сам ее знаю
все факты изложены=пусть дальше сам решает что и как делать
вот наверное и все
СПРОСИТЬ  ОТВЕТИТЬ
Перейти:

E-mail | WWW.ИСХОДНИКИ.RU

Powered by: Ultimate Bulletin Board, Freeware Version 5.10a
Purchase our Licensed Version- which adds many more features!
© Infopop Corporation (formerly Madrona Park, Inc.), 1998 - 2000.

Автор	Тема: Большие рисунки в памяти
mtdr	опубликован 25-12-2001 14:45 MSK Кинте идею насчет того, как создавать большие рисунки в памяти (10000х15000) глубина около 300dpi!! Завал!!!!!
Vovan	опубликован 25-12-2001 14:49 MSK Нужно что бы рисунок загружался в память не полностью, а динамически из файла, но это будет медленно работать!
Flex Ferrum	опубликован 25-12-2001 14:52 MSK Если самый простой вариант - то filemapping спасет отца русской демократии. Кстати, объем не такой уж и большой - "всего" ~430 mb. Единственное ограничение - одновременно сможешь работать только с двумя (от силы с тремя) такими картинками. Более продвинутый вариант - организовывать свой механизм свопа. Вариант более правильный, но на реализацию и отладку уйдет уйма времени.
Vovan	опубликован 25-12-2001 14:56 MSK Ну да я тоже про своп говорю! Но нужно набить гиморрой или поставляй вместе с программой модуль 512 Mb оперативы :) А зачем тебе такие рисунки если больше одного и на CD не влезут?!
Vovan	опубликован 25-12-2001 14:58 MSK А я понял, ты решил написать игру-стратегию, когда я был маленький я тоже думал что там используеться большой рисунок но это не так :(
mtdr	опубликован 01-02-2001 11:23 MSK Всем спасибо. Все гораздо сложнее. Пишу прогу для работы с графикой. На выходе нужен такой документ. Вот я тут и встрял. Перерыл уйму лит-ры, но ...
x	опубликован 01-02-2001 22:03 MSK FileMapping это не очень хороший вариант т.к. дает маздаю возможность свопить
Flex Ferrum	опубликован 01-02-2001 23:43 MSK А так и так будет свопить... Только в случае простой загрузки в память это будет выглядеть как: File <-(read)-> Memory <-(swap)-> SwapFile А во втором File <-(swap)-> Memory. Разницу чувсвуюешь?
x	опубликован 02-02-2001 11:55 MSK угу=во втором случае я могу ему запретить свопить
SUnteXx	опубликован 02-02-2001 00:58 MSK 2x: запрещай - дело твое:) Программным путем или как будешь запрещать? А запуск прог или запуск выньды не запретишь!:? Дос форева? Или линух? или юних? Что тебе больше нравится?
Stiff	опубликован 02-02-2001 13:40 MSK А можно попдробнее или ссылку что есть FileMapping а то я не нашел в MSDN :-(
Flex Ferrum	опубликован 02-02-2001 14:10 MSK Stiff: Позор на мои седины. :))) OpenFileMapping, MapViewOfFile, CreateFileMapping и т. д., и т. п. Или, проще говоря, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/filemap_0583.asp ( MSDN Home > MSDN Library > File Storage > File Mapping > File Mapping Reference )
Flex Ferrum	опубликован 02-02-2001 14:13 MSK x: Это я к тому, что в первом случае ты копируешь из файла в своп, а во втором - сразу в память. Разница есть? Своппить ты так или иначе будешь (если памяти ни гигабайт).
Student	опубликован 02-02-2001 15:07 MSK А может через DirectX ? Он же "крутой"...
Shader	опубликован 02-02-2001 19:34 MSK Фигу с ДиректХ. Там два типа сурвейсов... одни это в видео памяти ! размером не больше чем тек. разрешение экрана (вроде), а вторые в системной памяти. Но те, вроде больше 2048 на 1024 (где в этих пределах) не создашь. он кончено крут, но для таких изварщений -)
x	опубликован 02-02-2001 20:52 MSK to SUnteXx & Flex Ferrum механизм страничной адресации работает не быстро,совсем не быстро и если не выделять память самому то маздай ее раскидает как придется в Physical Memory= сие значит следующее=твой файлец будет сильно или не очень=но фрагментирован в Physicsal Memory далее значит что чипсет не будет переходить в burst mode при работе с ним ЭТО ЗНАЧИТ ЧТО ТЫ ПОЛУЧИШЬ НА МЕСТАХ СТЫКА СКОРОСТЬ 100-200MB/Sec вместо 800 при пакетной передаче я думаю мне не надо объяснять что мы конкретно упираемся в производительность памяти даже при скорости 1GB/Sec
Flex Ferrum	опубликован 03-02-2001 00:30 MSK Правильно ты сказал. Механизм страничной адресации работает не быстро. Но!!! Процессор оперирует страницами по 4 кб. Ему пофигу - расположены они рядом или на расстояении в 128 мб. Шина адреса имеет ширину в 32 бита. Отсюда вывод - с точки зрения процессора, находящегося в режиме страничной адресации линейной памяти абсолютно все равно - на сколько фрагментирована выделенная тобою область памяти. Адресация идет в любом случае через таблицу страниц. И насколько близко или далеко они расположены - не имеет значения. Скорость будет одна и та-же. ИМХО, конечно...
x	опубликован 03-02-2001 00:35 MSK ты знаешь что такое burst mode ?
x	опубликован 03-02-2001 01:16 MSK cудя по всему даже если знаешь то не представляешь насколько она важна 1.процессор и его внешняя шина работают в асинхронном режиме 2.ширина шины проца может и не совпадать с шириной шины памяти 3.отсюда значит и чипсет и/или имеет буфер запросов (обычно это L3/L2) и/или работает в асинхронном режиме RAM<=>CPU (ex KT7A) 4.что есть burst mode=пакетный режим передачи при котором адресная шина инкрементируется не ожидая запроса от CPU и сразу читается новая порция данных 5.при отсутствии burst mode но при последовательном чтении чипсет один такт страдает X потому что ждет адреса 6.при случайном хоть и страничном доступе получается еще хуже= тайминги SDRAM 3-1-1-1 сие значит что на активацию столбца у тебя уйдет не менее 3 тактов=значит в среднем 4-5 7.идем далее=размер строки кэша обычно >32байт =типично 128= и как показывает приктика гнусная железяка ждет ПОЛНОГО заполнения строки L1 прежде чем сможет к ней обратиться 8.L1 крайне мелкий и ты получишь еще FUN вытеснения данных из кэша как показывает практика такие вот мелочи поднимают скорость демок раза в 2-3 P.S:надеюсь я достаточно ясно выразился?
SUnteXx	опубликован 03-02-2001 01:21 MSK 2x: Картинка 10000х15000х32 = 572.2Mb! Легче самому свопить, а то у меня ограничение на своп стоит (около 256Мб)! И что ты сделаешь в таком случае? А если битмапа на винте не поместится, как быть? ФотожоП жрет дох места на винте, причем свопит сам, а его кодили не л%хи, так почему не сделать так же? Будет медленновато, но зато будет, чем них ни памяти не будет, ни винта, ни свопа, ни нормально работающей проги...!) 2mtdr: А сколько там цветов в битмапе? Может если строчки как-нить совмещать (к примеру, если 15, 17, 281 и 293 строчки совпадают, то савкать в своп в своем формате, что в начало новой строки савкается похожесть на одну из строк... или что-нить вроде того, или с кусками строк, ...?) ЗЫ Лучше всего, имхо, савкать на винт самому, а потом просто считывать нужный кусок битмапы, иначе заебе%%ся (с мягким знаком)!
x	опубликован 03-02-2001 02:01 MSK собственно что свопить надо самому я считал очевидным
wizzy	опубликован 03-02-2001 18:28 MSK Мне пришлось как-то печатать в файл битмапы и побольше. Очень выручает печать по частям. БМП так устроен, что если его печатать хитро по частям в обратном порядке, то получится правильное изображение. Так что выделяешь стандартный 32м битмап, "сканишь" им все изображение и дописываешь в файл.
Flex Ferrum	опубликован 03-02-2001 22:45 MSK x: Все это интересно, если ты пишешь демку. В демке картинки по 500Мб врядли используются. И потом - эти 500 Мб ты не уложишь в память без фрагментации - система возьмет свое. Приложение не одно, все они свопятся и т. д. и т. п. Отсюда вывод - либо организовывать "системный" своп через FileMapping, либо свой собственный. Я в свое время пошел по второму пути. Это в данном случае более грамотно. У больших картинок есть своя специфика хранения. Практически все они хранятся тайлами определенного размера (обычно выбираются степени двойки). Пример таких форматов - TIFF, JFIF. В последнем случае каждый тайл жпегуется. Формат BMP для таких картинок практически не применятся (из за своей специфики хранения). Так вот, в этом случае очень удобно организовывать кольцевые буфферы, в которых изображение подкачивается так-же, как и в описанном x'ом режиме burts mode - то есть с предсказанием.
Manyak	опубликован 03-02-2001 23:27 MSK ну уж чего я непонимаю, так если у тебя файл на выходе ну и пиши ты его целиком на хард. А дальше с харда подгружай только тот кусочек который тебе надо. Если еще в правильном формате будешь писать, а не bmp, то вообще все должно неплохо работать. А реализация в принципе не очень сложна если уж так подходить...
x	опубликован 06-02-2001 06:40 MSK я собственно не настаиваю просто изложил специфику данного вопроса как я сам ее знаю все факты изложены=пусть дальше сам решает что и как делать вот наверное и все