вында7 ругается на недостаток памяти
Коротко — потому что 32 бит. А длинно, потому что ряд адресов виртуальной памяти для 32 бит (которая при объеме физической в 4 Гб мэппится на физическую 1:1) оказывается зарезервированным под адреса ввода-вывода устройств.
своп-файл нужно завести наверное
нда, поставил для пробы 200 мб, наблюдаю
нормальный надо поставить думаю, а не маленький
4Гб для семерки мало, надо 8
4Гб для семерки мало, надо 8неверное утверждение
сильно зависит от профиля использования
мне хватает 4 гига
мне хватает 4 гига
для комфортной работы надо больше 4Гб
оно конечно и на 1Гб будет работать, но это нельзя назвать комфортной работой без тормозов
оно конечно и на 1Гб будет работать, но это нельзя назвать комфортной работой без тормозов
не понял, тут же пишут, что 32битная и 4гб неадекватно уваривает
больше гигабайта в никуда ушло - или на встроенную видеокарту?
для комфортной работы надо больше 4Гбоно конечно и на 1Гб будет работать, но это нельзя назвать комфортной работой без тормозовКапитан спешит на помощь и докладывает, что у разных людей абсолютно разные задачи крутятся на домашнем компе, поэтому оценивать потребности в памяти для всех сразу - заведомо неверно.
У меня на ноуте 2 гига, на десктопе - 8 гб, разницы не чувствую
ну, я на ноуте различаю 2 и 4 гига - на 4 гигах можно своп нафиг вырубить
ну это да 
так поставь 64битную и докупи памяти
У меня на ноуте 2 гига, на десктопе - 8 гб, разницы не чувствуюу меня на ноуте 1, на домашнем 4 и на рабочем 8, разница чувствуется между всеми
у меня на ноуте 1выкинь это
не, правда выкинь
больше гигабайта в никуда ушло - или на встроенную видеокарту?у меня встроенная хавает очень немного
у меня встроенная хавает очень немногопо идее да, динамическое выделение должно быть, но мало ли чего её переклинило
по идее да, динамическое выделение должно быть, но мало ли чего её переклинилоДинамическое выделение тут ни при чем, системные адреса "хаваются" и дискретными картами с собственной набортной памятью. Тут все определяется величиной GART
интересно мне насколько это верно в настоящее время
потому как то, для чего задумывался изначально GART, похоже, в последнее время (не менее 5 лет по моим наблюдениям длящееся) нафиг не нужно видеокартам с их объёмами памяти
например, у меня щас на долю "зарезервировано оборудованием" пишет 2 мегабайта, что больше похоже на "bios shadow"
то же, что жрут встроенные видеокарты, определяется никак не GART.
потому как то, для чего задумывался изначально GART, похоже, в последнее время (не менее 5 лет по моим наблюдениям длящееся) нафиг не нужно видеокартам с их объёмами памяти
например, у меня щас на долю "зарезервировано оборудованием" пишет 2 мегабайта, что больше похоже на "bios shadow"
то же, что жрут встроенные видеокарты, определяется никак не GART.
потому как то, для чего задумывался изначально GART, похоже, в последнее время (не менее 5 лет по моим наблюдениям длящееся) нафиг не нужно видеокартам с их объёмами памятиКак "ненужно"? А как ты видеопямять в системную отображать будешь? Нужно "окно" адресов, причем, чем более крупное, тем меньше операций копирования нужно делать.
AFAIK, современные биосы умеют как-то маппировать эти адреса используя виртуальное адресное пространство >32bit даже для 32-битных систем, но не все и не для всех устройств. Вот, можно почитать, в частности про memory remapping: http://en.wikipedia.org/wiki/3_GB_barrier
например, у меня щас на долю "зарезервировано оборудованием" пишет 2 мегабайта, что больше похоже на "bios shadow"серверную винду на десктопе юзаешь?
то же, что жрут встроенные видеокарты, определяется никак не GART.
Ещё раз. Для чего нужен GART:
То есть как альтернативный собственной видеопамяти способ хранения текстур в системной. Поэтому вопрос:
у меня вызывает некоторое недоумение вида "нафига козе баян?" По-моему адресацией видеопамяти должен заниматься видеопроцессор, мб за исключением окончательного кадрового буфера (то есть то что видно на экране и то не факт. Потому что бОльшая часть этой памяти используется отнюдь не как кадровый буфер, но как оперативка для GPU.
The GART allows the graphics card direct memory access to the host system memory
То есть как альтернативный собственной видеопамяти способ хранения текстур в системной. Поэтому вопрос:
А как ты видеопямять в системную отображать будешь?
у меня вызывает некоторое недоумение вида "нафига козе баян?" По-моему адресацией видеопамяти должен заниматься видеопроцессор, мб за исключением окончательного кадрового буфера (то есть то что видно на экране и то не факт. Потому что бОльшая часть этой памяти используется отнюдь не как кадровый буфер, но как оперативка для GPU.
серверную винду на десктопе юзаешь?чиво?
7-64 у меня
меня удивило что у топикстартера "зохавано на нужды системы" более 1 гига, обычно на 32-битной системе что-то порядка 700 мегов на нужды всяких шин уходит.
То есть как альтернативный собственной видеопамяти способ хранения текстур в системной.Ты неверно понимаешь написанное. Кури memory-mapped io
Ещё как верно. Также я помню _когда_ появилась эта хрень и для чего. И точно так же я вижу что эта хрень осталась только на страницах педовикии да в недрах документации xorg. Видимо, очень важная хрень.
ОК, не могу спорить со специалистом.
серверную винду на десктопе юзаешь?у меня вообще 1MB на две видяшки суммарно несущих 3,5Гб памяти
у меня вызывает некоторое недоумение вида "нафига козе баян?" По-моему адресацией видеопамяти должен заниматься видеопроцессор, мб за исключением окончательного кадрового буфера (то есть то что видно на экране и то не факт. Потому что бОльшая часть этой памяти используется отнюдь не как кадровый буфер, но как оперативка для GPU.А как тогда обмениваться данными между CPU и GPU, если данных много? Копировать через окошко?
Там поток чаще всего однонаправленный, текстуры надо сливать из CPU RAM в GPU RAM, обратный же поток мал. Ну и таки да, их придётся залить. Непосредственно в оперативной памяти CPU с ними хреново работать - но можно было бы с помощью GART если бы кто-то в здравом уме этим способом пользовался бы.
Там поток чаще всего однонаправленный, текстуры надо сливать из CPU RAM в GPU RAM, обратный же поток мал. Ну и таки да, их придётся залить.Сейчас же ещё в моде расчёты на GPU, там уже не текстуры.
Ну короче насколько я знаю, видеопамять обычно отображается в адресное пространство CPU - винда этого не показывает, поскольку системная память на это не тратится.
Сейчас же ещё в моде расчёты на GPUМой видеопроц такого не умеет.
Ну короче насколько я знаю, видеопамять обычно отображается в адресное пространство CPU
Ссылочку можно? А то в меня пока что ткнули эпитафией на GART и какими-то общими словами. Насколько меня просветил беглый гуглинг, у CPU нету прямого доступа к видеопамяти. В отличие от GPU, которому дозволен DMA для копирования чего-нить оттуда. Ну, если суметь им воспользоваться.
Хотя, учитывая это (если это не прикол конечно какой-то похоже что действительно отображается. Интересно мне как это выглядит под управлением 32-битной ОС с системной памятью в 4 гига и с видеокартой о 4х гигах. Если это конечно не из серии "некуда отображать - ну и хер с ним".
ну наверное вся видеопамять не будет доступна без PAE
GARTну типа IOMMU называется
GART - это вроде частный случай
в линуксе /proc/iomem показывает чья память где, у меня нет видеокарт с кучей памяти, чтоб посмотреть, что бывает в таких случаях
а не
iommu это для другого, как gart
iommu это для другого, как gart
Сейчас же ещё в моде расчёты на GPUтам обмен данными редок
ну наверное вся видеопамять не будет доступна без PAEну уж GPU-то её должен видеть
насколько я понимаю, забота о GART лежит полностью на операционке, поэтому в "серой" области оно учитываться не должно
для GART резервируется адресное пространство (апертура а физическая память выделяется динамически и отображается туда
видеопамять отображается отдельно
что бывает в случае видеопамяти больше гигабайта на 32-битных системах, мне найти не удалось
видеопамять отображается отдельно
что бывает в случае видеопамяти больше гигабайта на 32-битных системах, мне найти не удалось
для GART резервируется адресное пространство (апертура а физическая память выделяется динамически и отображается тудаВот именно. Размер апертуры это и есть "потерянная" память. Просто для 64-бит системы она находится где-то в далеких эксабайтах, докуда физической расти и расти, а в 32-битном адресном пространстве в силу 1:1 отображения физических адресов на виртуальные (при объеме оперативы 4Гб) она реально делает недоступным часть памяти, если только не делать всякие bounce buffers, что вообще-то чревато накладными расходами на копирование данных туда-сюда. Костыль PAE в комбинации с костылями в BIOS как-то позволяет это обходить, но для "настольных" операционок от МС этот костыль отломали, так что пользователям остается либо жрать кактус, либо использовать нормальную 64-бит операционку.
для GART резервируется адресное пространство (апертура)выделение апертуры вроде как сдохло вместе с AGP (по крайней мере даже в настройках кажись такого не осталось теперь GART нужна лишь для обеспечения DMA, если ничего не путаю, и осуществляется силами операционки/драйверов.
Не, размер апертуры в биосе выставляется, и не больше 256 обычно же
Я думаю, там просто решили, что это незачем настраивать, так как этот способ сейчас не основной, и вообще с виртуализацией не дружит
Гуглинг меня всё же убеждает в том что апертура для pcie не предусмотрена.
теперь GART нужна лишь для обеспечения DMAпогоди-погоди, а для DMA область системной памяти (буфер значит не нужна уже? И что-то мне подсказывает, что резервирование этого буфера делается явно на этапе загрузки, иначе что бы это тогда было?
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
BIOS-e820: 0000000000100000 - 000000007f7d1800 (usable)
BIOS-e820: 000000007f7d1800 - 0000000080000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0007000 (reserved)
BIOS-e820: 00000000f0008000 - 00000000f000c000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fed20000 - 00000000fee10000 (reserved)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
биос резервирует адресное пространство, как ему кажется правильным, драйвера потом могут переделать это
Ещё погуглил. Оказывается, щас GART встроен в видеочип. То есть из системного биоса эта хрень естественным образом не видна. А как она будет работать на видеокарте - зависит от драйвера видеокарты. Так как эта хрень работает не автоматически, иногда это у неё получается плохо.
биос резервирует адресное пространство, как ему кажется правильным, драйвера потом могут переделать этоОК, но разве для DMA-обмена с устройством не требуется зарезервированная (биосом или драйвером) область памяти, ну, точнее, кусок адресов? Как я понимаю, для обмена с видеопамятью нужно иметь достаточно большой буфер, чтобы копировать как можно большими блоками.
ну... 64 мегабайта - большой буфер?
ОК, но разве для DMA-обмена с устройством не требуется зарезервированная (биосом или драйвером) область памяти?Не памяти, а адресного пространства.
И пишут, что резервировать необязательно, можно динамически выделять. Типа в DX10 для каждого процесса выделяется отдельно например.
ну понятно вроде, что прямой доступ процессора к видеопамяти будет быстрее - нет лишнего копирования
64 мегабайтаДля видеокарт карт с гигом набортной? Оооой, слабо что-то верится мне. Больше похоже на буфер dma для какого-нибудь sata. Даже для сраной AGP апертура была 128-256 Мб.
Кстати, господа с виндой: откройте девайс-менеджер, выберите видеоадаптер и в свойствах посмотрите, какой диапазон адресов зарезервирован для него?
нет лишнего копирования
тем не менее, это оказывается не обязательная практика обращения с текстурами
Даже для сраной AGP апертура была 128-256 Мб.
Потому что выполняла совершенно другие функции. Странно иметь для видеокарты с памятью в 16 мегов кэш такого объёма, не находишь?
Для видеокарт карт с гигом набортной?Да они с жёсткого диска с такой скоростью грузиться не успеют с какой ты их в видеопамять писать хочешь. Скорость PCI-E 16x представляешь себе? Так она чаще всего и избыточна.
может я их процедурно CPU генерю, а не с диска читаю
может я их процедурно CPU генерю, а не с диска читаювспоминая о видеороликах на 64 килобайта, ждал такого комментария
должен заметить, весьма "распространённое" явление, ага
в любом случае, даже если ты их генеришь, ты не обновляешь их в видеопамяти настолько часто, чтоб не хватало пропускной способности шины, а если обновляешь, то, простите, что пользователь видит?
в общем, для всяких там gpu-вычислений я думаю быстрый и ёмкий канал cpu-gpu весьма важен, хотя тут пусть специалисты по gpu высказываются, но заведомо ясно, что архитектурно закладываться на то, что поток cpu-gpu мал, довольно недальновидно
в общем, для всяких там gpu-вычислений я думаю быстрый и ёмкий канал cpu-gpu весьма важен
всегда лучше больше, чем меньше, для этого уже аж до PCIe 3.0 добрались
архитектурно закладываться на то, что поток cpu-gpu мал, довольно недальновидно
"не настолько велик" != "мал", я никогда не говорил что он мал
тут вопрос в том зачем такой шине как PCI-E большой буфер (применительно к видеокарте конечно если вспомнить с чего всё началось - скорость высокая, задержки низкие, проблем с произвольностью нет... так нафига буфер? тем более что GART не о буферизации вообще, но о непрерывности
через 32-битный io-порт
в общем, для всяких там gpu-вычислений я думаю быстрый и ёмкий канал cpu-gpu весьма важензачем он нужен, если задание считается на GPU, а новое задание и соответственно обмен с CPU происходит не часто
в линуксе /proc/iomem показывает чья память где, у меня нет видеокарт с кучей памяти, чтоб посмотреть, что бывает в таких случаях10GiB физической памяти, видюха GeForce 9600GT c 512 MB, ядро с pae
~ $ cat /proc/iomem
00000000-0000ffff : reserved
00010000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000a0000-000bffff : Video RAM area
000c0000-000cddff : Video ROM
000d0000-000dffff : PCI Bus 0000:00
000e4000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-cff7ffff : System RAM
00100000-005fa659 : Kernel code
005fa65a-0085b907 : Kernel data
00913000-009ff6db : Kernel bss
02000000-09ffffff : Crash kernel
cff80000-cff8dfff : ACPI Tables
cff8e000-cffcffff : ACPI Non-volatile Storage
cffd0000-cfffffff : reserved
d0000000-ffffffff : PCI Bus 0000:00
d0000000-dfffffff : PCI Bus 0000:01
d0000000-dfffffff : 0000:01:00.0
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
e0000000-efffffff : pnp 00:0d
f0000000-f03fffff : PCI Bus 0000:03
f8e00000-f8efffff : PCI Bus 0000:02
f8ee0000-f8eeffff : 0000:02:00.0
f8ee0000-f8eeffff : r8169
f8eff000-f8efffff : 0000:02:00.0
f8eff000-f8efffff : r8169
f8f00000-f8ffffff : PCI Bus 0000:03
f9ff8000-f9ffbfff : 0000:00:1b.0
f9ff8000-f9ffbfff : ICH HD audio
f9fff400-f9fff4ff : 0000:00:1f.3
f9fff800-f9fffbff : 0000:00:1d.7
f9fff800-f9fffbff : ehci_hcd
f9fffc00-f9ffffff : 0000:00:1a.7
f9fffc00-f9ffffff : ehci_hcd
fa000000-fe9fffff : PCI Bus 0000:01
fa000000-fbffffff : 0000:01:00.0
fb000000-fb12ffff : vesafb
fd000000-fdffffff : 0000:01:00.0
fd000000-fdffffff : nvidia
fe980000-fe9fffff : 0000:01:00.0
fea00000-feafffff : PCI Bus 0000:02
feaf0000-feafffff : 0000:02:00.0
feb00000-febfffff : PCI Bus 0000:04
febd0000-febdffff : 0000:04:02.0
febd0000-febdffff : 0000:04:02.0
febe0000-febeffff : 0000:04:00.0
febffc00-febffcff : 0000:04:00.0
febffc00-febffcff : 8139too
fec00000-fec003ff : IOAPIC 0
fed00000-fed003ff : HPET 0
fed08000-fed08fff : pnp 00:07
fed14000-fed19fff : pnp 00:01
fed1c000-fed1ffff : pnp 00:07
fed20000-fed3ffff : pnp 00:07
fed50000-fed8ffff : pnp 00:07
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
fee00000-fee00fff : pnp 00:0b
ffc00000-ffefffff : pnp 00:0a
fff00000-ffffffff : reserved
100000000-2afffffff : System RAM
у тебя 2 блока по 256МB
один я так думаю для DMA, а другой для отображения видеопамяти - отображается походу только часть
у меня ровно то же самое на встроенном адаптере Intel - я даже не в курсе, есть ли у него своя видеопамять
один я так думаю для DMA, а другой для отображения видеопамяти - отображается походу только часть
у меня ровно то же самое на встроенном адаптере Intel - я даже не в курсе, есть ли у него своя видеопамять
у меня ровно то же самое на встроенном адаптере Intel - я даже не в курсе, есть ли у него своя видеопамятьон отгрызает себе кусок системной и делает вид что это его собственная. для системы память становится потерянной.
а вообще может оказаться что MMCONFIG - это не привязано ни к какому устройству, тогда правда непонятно, зачем целых 256MB
в MMCONFIG замаплены pci configuration space-ы всех pci устройств.
например, в 0xe0000000 доступен pci vendor id северного моста.
ds:0xe0000000 8680
например, в 0xe0000000 доступен pci vendor id северного моста.
ds:0xe0000000 8680
2.92 Гб доступно (кстати почему не вся доступна?)вроде до 3.2 можно довести правя реестр.
кстати, упомянутая установка маленького свопа вроде бы решила проблему
а ты загрузи ещё пару игр, и увидишь ещё раз это сообщение.
нигамаю
Оставить комментарий
reallyjust
часто. требует выгрузить фаерфоксмонитор ресурсов выглядит так, это нормальная картина?
установленная память 4Гб, 2.92 Гб доступно (кстати почему не вся доступна?)