Enter your email address to subscribe to this blog and receive notifications of new posts by email. The default setting is only going to effect 32 bit users. If you are reading this and have a 64 bit OS, this will not avail you as it is not relevant. Specifically this has nothing to do with C++ unless you had previously changed the ini. File and somehow reset it to default with an install. For those not aware of it, this cmd line change is the setting for user space in the application's virtual addressable memory space. Turning up settings, using more resolution, higher numbers of units, or other increases that may cause more resources to be used (including api's that are increasingly complicated and resource heavy in use) all will contribute to using up more user-side addressable space, and the TW series as time has gone forward has used progressively more space. 32 bit systems nominally have this as divided in half between user (read as 'user actuated/decided upon' resource usage for the specific application) and kernel (read as 'system use' for the specific application). The maximum total is ~4g vram+sysram+drivers/headers/etc, so at default settings, 32 bit operating systems are therefor only able to use ~2g for USER addressable resources (that you have chosen to use by application settings and system wide settings). When you force use over ~2g without this ini. File increase, it causes inelegant closing (read as 'crashing') randomly as calls exceed user side addressable virtual memory space. Increasing the limit on 32 bit systems can effectively solve this issue to a limited degree, although stability tends to decrease as one approaches ~3G of user addressable space (which will depend on driver and other system environmental conditions). The command 2800 means you have about ~200M or less more to go before you are around the max user space addressable. 32 bit systems require a minimum of about ~1G for Kernel Space. 64 bit systems by contrast have about ~4G of space as kernel operations are not handled within the applications virtual addressable memory space at all. This means the VA fix, or as it is called here, the 'Mad Boris', is irrelevant to 64 bit users. This of course means a 64 bit user has more addressable virtual memory to address and higher performance/settings are achievable. Of course again to a limited degree - as we already see limiting behaviors that either reduce output quality or output setting choices beyond which 32 bit application processes cannot perform due to architecture even if one HAS the larger 64 bit operating system capabilities. A note to the OP that that system probably has limited setting potential or limited pixel/resolution aiding in the limiting of resource usage, but there is another consideration which should be mentioned if the integrated video solution is the only one on the system. While the 4600 is about the very best outside of Iris-based or related series, it has no dedicated vram in the sense that: There is no physical vram in the system - this is a specific species of memory that is resident on discrete cards only and has specific architecture and behavior quite different from that of system ram. Xilisoft youtube video converter free download for mac. Any ram being used for memory is therefor being siphoned off from the system memory which you have listed as being physical 4G. This is not overmuch given that the OS is using some considerable part of it, and the CPU and other parts of your system are also using system ram for the application separate from the video solution's use. While a 32 bit system is limited to under ~3G, so with not much in the way of background activities going on other than the OS itself, 4G physical is probably enough, the system has very little leeway, and either switching to 64 bit or utilizing other ram-heavy background programs might lead to either significant lag or crash as memory is sought from the swapfile.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |