بیست و پنجمین سمپوزیوم Hot chips امسال به رسم هر سال با نام HC25 برگزار میشه و مایکروسافت در این سمپوزیوم کنفرانسی داره که پیرامون چیپ به کار رفته در کنسول Xbox one هست. محل برگزاری این کنفرانس دانشگاه استنفرد هست و مایکروسافت به همراه AMD و اینتل در این کنفرانس که پیرامون SoC ها هست برنامه ای رو تحت عنوان XBOX One Silicon ارائه میده John Sell و Pat O’Connor از مایکروسافت برگزار کنندگان این کنفرانس هستن مدت این کنفرانس 1 ساعت و نیم هست و در اون به ترتیب AMD با موضوع Kabini APU SoC و مایکروسافت با موضوع XBOX One Silicon و اینتل با موضوع Clover Trail+ – Intel’s Next Atom SoC پیرامون آخرین تکنولوژیها در SoC صحبت میکنن.
این کنفرانس از این جهت جالبه که مدتی قبل کاربری در نئوگاف که لینک پروفایلش در Linkedin تایید میکنه که طراح GPU در AMD هست ادعا کرده که APU/dGPU رو در Xbox one تست میکرده هنوز مشخص نیست منظور این شخص از dGPU چی بوده به همین دلیل ممکنه در این کنفرانس مایکروسافت بخشی از مشخصات سخت افزاری Xbox one رو به صورت واضح تری تشریح کنه.
تو یکی از مقاله ها که الان لینکش را ندارم فکر کنم یکی خبرش را تو همین سایت گذاشت move engine های داخل x1 میتونن مقدار 8 و 9 گیگ تکسچر را تو 16 مگ فشرده کنن .
تو یکی از مقاله ها که الان لینکش را ندارم فکر کنم یکی خبرش را تو همین سایت گذاشت move engine های داخل x1 میتونن مقدار 8 و 9 گیگ تکسچر را تو 16 مگ فشرده کنن .
و اتفاقا تو مقاله ای نوشته شده بود که این سخت افزار مایکرو همون چیزی که جان کارمک سالها دنبالش بوده !
حتی اگرم یکی از ویژگیهای DX11.2 باشه بازم برای مایکروسافت هست ! چیزی که برام جالبه صفحه قبل گفته میشه ESRAM بدرد مگاتکسچر نمیخوره ولی همین LIONHEAD داره تو انجین جدیدشون از مگاتکسچر استفاده میکنه !
مقاله دوم در مورد سخت افزار و توضیحات در مورد MOVE ENGINE که تو مقاله هم ذکر شده که این همون چیزیه کارمک سالها دنبالش بوده !
پستیه که خودم تو تاپیک قرار داده بودم و توضیحات خیلی عالی هم در موردش داده !
اطلاعت جدید دیگه و دلایل انتخاب DRR3 بجای GDDR5 و استفاده از چیپ esram و Data Move Engines و.................. اطلاعات واقعا جالبیه که نشون میده مایکروسافت چگونه میتونه بازدهی 100 درصد از سخت افزار بگیره و پهانی باند خودش را کاملا مورد استفاده قرار بده و همچین جای پای تکنیک های جانکارمک مثل Virtual Texturing و...........
First of all, sorry for the delay on this issue, I wanted to do the right thing in this case and I think that once you read the entry will understand it.
A few days ago in VGLeaks they leaked part of the descriptive of the following Xbox GPU documentation, which is a variation of the GCN architecture with some additives, to the naked eye the part "no on measure" can lead to some confusion since Microsoft has made use of a nomenclature that is completely different from that used by AMD. In the following table have names equivalents, so that we can move directly to the part that interests us is that really defines a Xbox 8/Durango.
But to better understand the parties "as" we must take the DeLorean. First trip with the Delorean: a journey to the past
In terms of custom parts, the system's GPU is reminiscent a graphics processor professional not very known to the public given that was not very popular in the domestic sphere, but which, in 2002, included a technology that had never been integrated into a graphics card and would not see integrated hardware level again until the arrival of the GCN architecture, I'm talking about the P10 from 3D Labs.
Beyond the memory bus hardware implementation, 3Dlabs believes that the "Virtual memory" system used in the P10 has much more meaning and potential impact on the 3D market, in fact, is something that John Carmack of id has been asking for a long time in the hardware. The concept of Virtual memory is very similar to used in the CPU memory system: removes the barriers between the different subsystems of memory in the computer, such as the buffer's local, the RAM image main or even the hard disk space, and allows 3 processor access them freely.
In the Virtual memory of the P10 system there is a space of logical addressing of up to 16 GB which is completely divided in 4 KB pages. The RAM on the card essentially becomes a huge cache L2 for the chip, a system which is easy to understand for the compilers.
Not in vain Carmack already had years pushing for the implementation of Virtual memory on the GPUs for some time, in a letter of March 7, the year 2000, he already explained the need for the passage of a virtual memory system, the reason for this was to avoid the so-called "Texture Trashing", Carmack described the problem in the following way:
Almost all of the drivers made a purely LRU memory management. This works correctly while total textures need in a frame to fit into memory once have been loads. The minimum you need a little more than memory that fits into the card, you will see how performance falls sharply. If you have 14 MB of textures to render a frame, your graphics card and it has only 12 MB of available buffers of image, instead of having to upload 2 MB that do not fit. You will have to make the CPU to generate 14 MB of command of traffic that can make to the frame rate of a single digit in many drivers.
His idea to solve the problem already the know all, Virtual Texturing, Carmack once described it as well, keep in mind that this is the year 2000:
Problems with large textures can be solved by simply not using large textuas. Losses, both the texels not referenced can be reduced by cutting all textures of 64 × 64 or 128 × 128. This requires pre-processing, adds geometry, and requires a messy overlap of textures to adjust the seams between these.
Currently it is possible to make an estimate of which are the necessary levels of Mip Map and only to exchange those. An application cannot be exactly calculated levels of Mip Map that will be referenced by the hardware, because of this there are a few small variations between chips and the calculation of the slope can lead to a significant overhead in processing. A bound top conservative may be looking at the normal minimum distance from any reference to the vertex and texture in a foograma. This over-etimaria the necessary textures in a 2 X and it would still leave a great impact when the top level of the Mip Map will load for large textures, but can enable the setting for scenes great style Cathedral unless there is an Exchange.
Smart developers can always work hard to overcome the obstacles, but in this case, there is a clear solution for hardware that simply gives more performance than anything else possible for software and makes life easier each: virtualizing the vision that has its virtual memory card.
With pages of tables, the fragmentation of the addressing is not a problem, and with the rasterizer graphic to having to reload a page when exact 4 KB block is necessary, the levels of the mip maps and textures hidden problems simply disappear. You don't have to do anything sneaky by application or driver, only to manage the indexes of the pages.
The hardware requirements are not very heavy. You need graphic card, the ability to load automatically the TLB buffers (TLB) translation from the pages of tables in local memory, and the ability to move a page through the AGP or PCI graphics memory and update the pages of tables and reference counter. Don't even have several TLB, since access patterns are not jumping po all coo memory can the CPU. Even with a single TLB for each unit of textures, refills would have only 1/32 of the memory access if the textures were blocks of 4 KB. Everything you want is that the limit superior outside a TLB large enough so that each texture covers the texels referenced in the typical raster by scanline.
Some developers will say "I do not want the system to handle textures, wants total control" there are a couple of answers to this, first the management pages have the flexibility you don't get by a scheme by software, so you have new capabilities. Second, you can still continue to treat as if it were a fixed texture buffer and do your mimo with updates. Third parties, even if this were slower than the scheme possible to outsmart software (which I seriously doubt), will exchange development time by something that is theoretically more efficient and faster. We not already code in Assembly language overlays!
Some hardware designers will say something that the graphics engine is in waiting while they getting obtaining data from a page from the CPA. Sure, it will always be better to have enough space for textures and not have to always make the Exchange, and this feature would not allow you to talk more about megapixels, or millions of triangles, but each card ends up not having enough memory at a given point. Ignore these cases from the real world does not help to your customers. In any case, infernal waiting for this is much less than if these loading texture learns from the command FIFO.
It is assumed that 3Dlabs will have some form of virtual memory management on the permedia 3, I'm not familiar with the details (Yes someone from 3D labs can send me the latest registered specifications, it detects it!).
P10 = Permedia 3. Later comments on the use of RAM embedded for this concept:
Embedded DRAM should be a driving force. It is possible to place a large amount of megabytes of high bandwidth on a chip with a video driver, worse it will not be possible (for now) to put the 64 MB of a GeForce there. With the virtualized texturing, pressure on the memory is drastically reduced. Even with a 8 MB card would be enough for game to 1024 × 768 and 16-bit or 32-bit and 800 × 600, no matter whatever the burden of textures.
Second trip with the Delorean: a near present. In one of the entrances on Durango talk precisely of the same item, the implementation of Virtual Texturing but related to a patent on behalf of Mark S. Grossman and Microsoft, are what comes now is a Deja Vu, but is helping to connect the dots between the past and the future.
________________________________________________________________________________________________________________________
On the other hand, there is an element that makes me think that this is the architecture chosen by Microsoft is the 7 HD × 00/GCN and is partially resident textures -
As you can see the Texture Unit in this diagram, not only you can read the main RAM for texture, you can also read a map tiles, the patent reads as follows:
Map of Tiles can specify the Tiles that are stored in the memory for textures. In one application, the map Tiles may contain one or more tables that can be used to determine the level of detail (if any) available for each Tile, so the map Tiles can reside on a memory unit.In some applications the map Tiles can be found in the memory for textures, but it is not required.
A map or table Hash, is a data structure that associates a particular key with a value index, so the keys stored within the map Tiles correspond each to a memory address concrete and the address of memory contains data. The patent says that the map of Tiles is in another memory which is not memory where are stored the textures but another... and another memory we have a map of Tiles available and accessible by all the TMU? Because the cache second-level GPU, which means that in the case of Xbox 8 and given that would the CPU and the GPU is communicated through the cache that the CPU could write GPU where textures in the same cache L2 so that the GPU can read it. On the other hand the expression that the map of Tiles is in memory for textures, does not mean only that the map Tiles can insert into main memory but also can include textures in the same memory that is the map Tiles, which entails the use of a memory embedded in the GPU. All textures within the eDRAM memory obviously cannot be placed, nor even the whole scene would take, it can be pulled by a Tile Rendering similar to which there is in the PowerVR and Xbox 360, which would also mean the use of this memory as an accumulation buffer.
The accumulation buffer, known as FrameBuffer Object in the jargon of OpenGL is a section of memory where you can calculate a frame with the peculiarity that will not be the final frame and on the same data is calculated several times. It is used in techniques such as the Tile Rendering and effects of post-processing based on manipulating the final image. You can work with it using a full-frame or otherwise making use of small pieces of the frame, much easier to store in buffers. Effects such as Alpha Blending, Motion Blur, the different types of AA... are effects that depend on much, but lot of bandwidth when calculating it, is for this reason that dividing the frame into fragments and go running with them memories closer to the processor, as in the case of Xbox 8/Durango would be the caches. For most loop the loop, if we take into consideration the filtrate in VG Leaks on the alpha of the next Xbox kits:
Kit Alpha uses a separate graphics card similar in capacity and speed to the GPU to be include in the final design. Card does not have the ESRAM which will take the final GPU design.
_________________________________________________________________________________________________________________________
Looking a bit more documentation I have found information about a technique presented by Sean Barrett in the 2008 GDC calledSparse Virtual Texturing or SVT, which is the same as the PRT of AMD.
Sparse Virtual Texturing is a form of simulation of large textures using much less memory than would be required to loading only the data when they are needed, and using a pixel shader to map from a huge virtual texture made the current physical texture.
The technique can be used for very large textures, or simply for large amounts of small textures (grouping all of them in a huge texture, or using multiple table pages).
It has been inspired by the descriptions of the MegaTexturing of John Carmack in several private forums and emails. It is not exactly the same as the MegaTexture but is approached.
In full year 2008, the management of memory in GPUs remained virtual memory hardware-level support and therefore had to make an implementation of the idea software, recently with GCN architecture AMD has implemented all this hardware.
The problem with this implementation is not part neither of the current version of DX or OpenGL, so it is not a completely standardized technology, on the other hand some... you say that does this special if it is proper of the GCN architecture that will be used by PS Orbis? Well, keep in mind that aside from Xbox 8/Durango have not yet arrived, but this previous part is necessary to understand the architecture of the new system. Third trip with the Delorean: Durango
There are three elements of the following console from Microsoft that are interesting, are as follows:
Virtual Texturing
ESRAM
Data Move Engines
All these parties revolve around the same concept, the implementation of Virtual Texturing hardware. ESRAM
Durango has no video memory (VRAM) in the traditional sense, but the GPU does contain 32 MB of fast embedded SRAM (ESRAM). ESRAM on Durango is free from many of the restrictions that affect EDRAM on Xbox 360. Durango supports the following scenarios:
Durango has no memory (VRAM) video from the traditional point of view, but the GPU contains 32 MB of embedded SRAM (ESRAM). The ESRAM in Durango, is free of many of the restrictions that affect the EDRAM on Xbox 360. Durango supports the following scenarios:
Texturing from the ESRAM
Render surfaces in the main RAM
Read from a render target without having to make a decision (in certain cases)
The difference in flow between the ESRAM and main RAM is moderate: 102.4 GB/sec front 68 GB/sec. The advantages of the ESAM is a lower latency and a lack of restraint by other customers of the memory, e.g. CPU, I/O, output to screen. Low latency is particularly important to maintain the performance of the color blocks (CB) and the depth blocks (DB).
By strange and surprising that it seemed to a next generation console: Xbox 8/Durango has "only" 32 MB of video memory. do you understand the reason why I have made reference to the 3DLabs Permedia 3 now? 3DLabs card included memory did the same work that makes the ESRAM next Microsoft console, this means that the L2 cache of the GPU and memory controllers that a traditional configuration would be connected to the external memory here are directly connected to the ESRAM. The current APU from AMD on the PC to communicate with the external memory GPU makes use of the Radeon Memory Bus, which has a bandwidth of 256 bits in each direction per channel memory (256-bit of reading) and 256-bit of writing, in the case of Kryptos we find that bandwidth is 1024 bits in total, so added a dual controller or the existing width has been increased.
This is the first part of the puzzle, we are still missing the other two parties. Virtual routing
All access to the GPU in Durango memory using virtual addresses, and therefore pass through a translation table before working out in the form of physical address. This layer of indirection solves the problem of fragmentation of memory hardware resources, a single resource can occupy several non-contiguous pages of physical memory without penalty.
Virtual addresses can take aim pages in the main RAM, the ESRAM, or can not be mapped. The Shader read and writes the pages not mapped in well defined results, including optional error codes, rather than block the GPU. This ability is important for the support of resources in "tiles", which are partially resident in physical memory.
The benefits of the face graphics Virtual address does not need to repeat again as above, but above all what's noteworthy is the use of the same for Virtual Texturing, which is its main function, the most direct utility is to break the direct link between the information available on each frame and the bandwidth of the memorythe reason for this is simple, in the traditional method, you have to load the entire page of textures full through the bandwidth, here only loads what is needed in each frame, but this is something that has been commented more above.
But of course, as we are at this level of the last piece of the puzzle still missing description, is worth that the GPU will see all of the main memory, but... do as accessed if their memory controllers are directed towards the ESRAM? Hence through DME or Data Move Engines are the third and final part of the puzzle. Data Move Engine
The Data Move Engines are something that can initially cause headaches but fully understand when you consider that their function is the same as the the PCI Express on the PC, while thanks to unify into a single chip CPU and GPU seems to be that the PCI Express already loses all its raison d'etre, actually has a less known function for being less used to it is the provide direct access to the main system memory for different devices, connected to the PCI Express port, so the GPU has access to 8 GB of DDR3 system memory.
But the DME beyond, is the problem of virtual memory in the GCN architecture support is not complete and does not support 100% hardware, but that is a combination between software through Shaders and hardware, the idea of the DME is that virtual memory management can be performed automatically by these or alternatively give freedom to the developer not to use this type of memory management according to see it suitable.
The concept is as follows, Shaders memory management sucks by these cycles, which despite the theoretical peak is higher, real available bandwidth may be lower and if you read the summary of the text written by Carmack above you will see that it refers to the waiting time that data arrive from main memory to the memory of video through the DMA's turn, as well, the DME eliminated this problem downloading this task of Shaders and making it work in parallel computing of the scene.
The advantage of the Move Engines lies in the fact that can operate in parallel with the computer. During the times when the GPU is attached by the computer, the Move Engine operations are effectively free. Even when the GPU is limited by bandwidth, the engines move can use different paths. For example, a move engine which copy of the RAM to RAM will not be impacted by a shader that only accesses the ESRAM.
With DME the puzzle is completed and this full hardware support to 100%, the management of virtual texturing does not have to be implemented within each graphic engine and therefore it is possible to use all the graphics engines and therefore on all games. The advantage of this is that the "FLOPS" which would be spent on memory management can be directed to other tasks allowing greater use of the GPU for computer graphics, but the use of not only DME is limited to Virtual Texturing, keep in mind that they can load any data in the ESRAM and that this charge them directly in the caches of the GPU. Do you think for example loading an Octree node for example? Use goes beyond Virtual Texturing.
But this can be applied in PS Orbis? Basically to implement virtual memory management it is not necessary that there are two levels of memory, taking the top sufficient storage capacity for the image (color, depth, and stencil) buffers and textures needed for the scene and there is a lower level. For PS Orbis the caches of the GPU do not have enough storage capacity for this and the GDDR5 is a single level of memory for all of the GPU. Obviously the ESRAM and all the mechanism implementation costs in the space that is a sacrifice in terms of computation capability. But the biggest advantage comes from the fact that this allows access to large amounts of memory per frame without having to rely on huge band widths from expensive high-wattage as the GDDR5 memory. The reason why Xbox 8/Durango uses GDDR5 is not by the fact that then the thing would be completely redundant, the GDDR5 exists on the GPUs of face to avoid the Texture Trashing by the use of a higher bandwidth, the use of virtual memory on the GPU and Virtual Texturing are another solution to the same problem that both come into conflict within a system.
I hope that the article has left things clear and clarified any confusion.
اصلا Xbox نه هرچی! 9 گیگ چجوری میشه 16 مگ؟ من الان که به گذشته نگاه میکنم میبینم هرچی تا الان گفتید رو میتونم قبول کنم، از تحول بودن GeoW تا آبرنگی بودن گرافیک UC2 اما این یه مورد رو نه! یه لینک بدید به من خودم برم مقاله رو بخونم! یارو علفیم باشه نباید همچین توهمی بزنه!
جوابت را بالا دادم این تکنیک انحصاریه وین 8 و x1 هست که با esram هم فوق العاده تاثیر گذار هست مقاله پایین را که دادم بخون در مورد move engine ها که کار خودشون فشرده سازیه . خلاصه در مورد حجم سنگین تکسچرها مایکروسافت کوچکترین مشکلی نداره از اونجایی هم که این esram میزان latency بسیار پاینی داره و پهنای باند بسیار سریع داره و تبادل اطلاعات بین gpu بسیار بالاست و از اونجایی که مگاتکسچر نیاز به رم بالا نداره این تکنیک ها خوراک جانکارمک هست !
اصلا Xbox نه هرچی! 9 گیگ چجوری میشه 16 مگ؟ من الان که به گذشته نگاه میکنم میبینم هرچی تا الان گفتید رو میتونم قبول کنم، از تحول بودن GeoW تا آبرنگی بودن گرافیک UC2 اما این یه مورد رو نه! یه لینک بدید به من خودم برم مقاله رو بخونم! یارو علفیم باشه نباید همچین توهمی بزنه!
پس اینطور که شما میفرمایی حتما DME نسبت نزدیکی با حضرت موسی داره! لطفا لینکش رو بده منم ببینم. اصلا برام قابل باور نیست چجوری 9 گیگ فشرده میشه، میشه 16 مگ!:-b با عقل من جور در نمیاد! اصلا منظورم این نیست که DME بده یا ESRAM کاربردی نیستا! الکی گیر ندی بهم! همین یه مورد که گفتی باعث شد رسما بریزه!
فرخ با این اشتباه گرفته. :d
Move Engine نیست. فیچر DX 11.2 هست که باعث میشه موقع انتقال 3 گیگ تکسچر فقط از 16 مگ مموری ـه GPU استفاده کنه. روی One و Windows 8.1 اجرا میشه و توی کنفرانس Windows 8.1 به طور رسمی با اسم Tiled Resources معرفی و اجرا شد:
اگه esram یه چیزی تو مایه های cashe پردازنده باشه احتمال افزایش پهنای باند به این مقدار هست!
در cashe پردازنده ها آدرس اطلاعات موردنیاز موجود در رم ذخیره میشه و این باعث افزایش کارایی میشه و در هر سیکل پردازنده نیاز نداره که کل رم رو سرچ کنه و اینطوری باعث کاهش وقت میشه!
و اگه آدرسی در cashe نبود اون ادرس رو به cashe اضافه میکنه و یک مشت عمیات ریاضی و پیچیده که نهایتا نتیجش این میشه که برای انجام یه عملیات تا آخرین حد ممکن کمتر نیاز به گشتن کل رم باشه و آدرسش تو همون cashe پیدا بشه!البته 32 مگ خیلی زیاده!نیاز به این همه نیست!
من ندیدم جایی بنویسه 9 گیگ رو به 16 مگ تبدیل کردن ! کلا یه تکنیک تکسچرینگ جداست که با حافظه خیلی کم انجام میشه نه اینکه 9 گیگ رو فشرده کردن شده 16 مگ !
من ندیدم جایی بنویسه 9 گیگ رو به 16 مگ تبدیل کردن ! کلا یه تکنیک تکسچرینگ جداست که با حافظه خیلی کم انجام میشه نه اینکه 9 گیگ رو فشرده کردن شده 16 مگ !
همون روش نرماله. هیچ جا هم نگفته یه تکنیک جدای تکسچرینگ هست. روی GPU و معموریش کار میکنه و تغییر میده. قرار نیست کلا تکنیک تکسچر زدن تغییر کنه که بگیم یه چیزه چداس با حافظه کم:
"Tiled Resources" allows for significant enhancement of in-game textures by making it possible to simultaneously access GPU and traditional RAM memory and create a single large buffer where large textures can be stored.
حالا اون 9 گیگ اشتباه فرخ بوده. 3 گیگ تکسچر که از 16 مگ استفاده کرده
جا دادن 3 گیگ تکسچر تو 16 مگ حافظه یه جور طرفنده اینجوری نیست که 3 گیگ داده رو اینقدر فشرده کنن که بشه 16 مگ چون این داده موقع پردازش باید آنکامپرس باشه مثل یه ایمیج بیت مپ که شما روی کامپیوترتون دارید.
اینکار با طرفندی به اسم Tiled resources انجام میشه و اتفاقا از ملزوماتش داشتن یه حافظه فوق العاده سریع هست چون باید یه بافر اختصاصی برای اون تکسچر به وجود بیارن.اساس کارشم اینه که از یه تکسچر بزرگ فقط اون قسمتی تو معرض دیده روی حافظه قرار میگیره.
تو Xbox one اینطور که بعضی جاها نوشتن نقش کیلیدی بازی میکنه احتمالش زیاده مایکروسافت یا چندتا 1st party تو انجین بازیاشون از این طرفند استفاده کنن.
آقای کارشناس اصلا یکبار هم لینکی که دادی رو خوندی؟ اصلا میدونی تکسچرها تو بازیا چجوری استفاده میشن؟ تو این لینک دقیقا کجاش گفته شده 9 گیگی فشرده میشه، میشه 16 مگ؟
فرخ و بابک عزیز، من اصلا با پلتفرم کار ندارم،چه DX و چه X1 (چون در هر صورت فکر میکنم مایکرو از این تکنیک تو X1 هم استفاده میکنه) اصلا قابلیتی که 9 گیگ رو فشرده کنه بشه 16 مگ نداریم! اینی که شما لینکش رو دادید و شرط میبندم حتی نگاهش هم نکردید و نمیدونید جیه (وگرنه همچین حرفی نمیزدید که مجبور بشید سریع پست رو پاک کنید!) درباری تکنیک لود تکسچرهای حجیم هست! متاسفانه این چیزی که دست گذاشتید روش تخصص و کار منه. توی بازی ها همه مدل ها لوپولی هستن. یعنی وقتی میخوای UVW مپشون رو باز کنی مجبوری همه تکسچرهات نورمال مپ و دیفیوز مپ باشن و کلا دیتیل رو اینجوری بدی. منتها ایراد اینه که اگه بخوای حجم دیتیلی که میدی بالا باشه باید رزولوشن تکسچرهارو ببری بالا که حجمشون میره بالا. تو این تکنیک نمیان کل تکسچرها و لایه های نرمال مپ و دیفیوز رو باهم بیارن تو رم تا حجم زیادی رو اشغال کنه، بلکه همه این تکسچرهارو به اندازه های کوچیک قسمت میکنن و بر حسب میدان دید همونی که لازمه هی میاد تو رم و هی میره بیرون. اینجوری میشه مثلا یه تکسچر 3 گیگی رو تنها با 16 مگ رم نشون داد! منتها تنها چیزی که هست اینه که اینکار سرعت خیلی بالای رو میطلبه که DDR3 نداره اما ESRAM به راحتی اینکارو میکنه. (من الان بیشتر تحقیق کردم و دیدم اشتباه میگفتم و اتفاقا ESRAM خراکه مگا تکسچره)
یه همچین سیستمی رو هم انجین UC داشت و یادمه تو UC2 میگفتن ازش استفاده میکردن. البته تکنیک اجرای ان کاملا فرق داشت و اینکارو کرده بودن تا علی رغم رم داغون PS3 بتونن تکسچرهای باکیفیت رو تو بازی بیارن.
بهتره قبل از اینکه ادعایی بکنید و یه سری لینک پشت سر هم ردیف کنید خودتون یه سر بهش بزنید و ببینید چیه. بد نیست.
آقای کارشناس اصلا یکبار هم لینکی که دادی رو خوندی؟ اصلا میدونی تکسچرها تو بازیا چجوری استفاده میشن؟ تو این لینک دقیقا کجاش گفته شده 9 گیگی فشرده میشه، میشه 16 مگ؟
فرخ و بابک عزیز، من اصلا با پلتفرم کار ندارم،چه DX و چه X1 (چون در هر صورت فکر میکنم مایکرو از این تکنیک تو X1 هم استفاده میکنه) اصلا قابلیتی که 9 گیگ رو فشرده کنه بشه 16 مگ نداریم! اینی که شما لینکش رو دادید و شرط میبندم حتی نگاهش هم نکردید و نمیدونید جیه (وگرنه همچین حرفی نمیزدید که مجبور بشید سریع پست رو پاک کنید!) درباری تکنیک لود تکسچرهای حجیم هست! متاسفانه این چیزی که دست گذاشتید روش تخصص و کار منه. توی بازی ها همه مدل ها لوپولی هستن. یعنی وقتی میخوای UVW مپشون رو باز کنی مجبوری همه تکسچرهات نورمال مپ و دیفیوز مپ باشن و کلا دیتیل رو اینجوری بدی. منتها ایراد اینه که اگه بخوای حجم دیتیلی که میدی بالا باشه باید رزولوشن تکسچرهارو ببری بالا که حجمشون میره بالا. تو این تکنیک نمیان کل تکسچرها و لایه های نرمال مپ و دیفیوز رو باهم بیارن تو رم تا حجم زیادی رو اشغال کنه، بلکه همه این تکسچرهارو به اندازه های کوچیک قسمت میکنن و بر حسب میدان دید همونی که لازمه هی میاد تو رم و هی میره بیرون. اینجوری میشه مثلا یه تکسچر 3 گیگی رو تنها با 16 مگ رم نشون داد! منتها تنها چیزی که هست اینه که اینکار سرعت خیلی بالای رو میطلبه که DDR3 نداره اما ESRAM به راحتی اینکارو میکنه. (من الان بیشتر تحقیق کردم و دیدم اشتباه میگفتم و اتفاقا ESRAM خراکه مگا تکسچره)یه همچین سیستمی رو هم انجین UC داشت و یادمه تو UC2 میگفتن ازش استفاده میکردن. البته تکنیک اجرای ان کاملا فرق داشت و اینکارو کرده بودن تا علی رغم رم داغون PS3 بتونن تکسچرهای باکیفیت رو تو بازی بیارن.
بهتره قبل از اینکه ادعایی بکنید و یه سری لینک پشت سر هم ردیف کنید خودتون یه سر بهش بزنید و ببینید چیه. بد نیست.
یعنی تو از مایکروسافت پیش تر بودی و این تکنیک را قبل از اینکه مایکرو تو dx11.2 اماده کرده ازش استفاده میکردی ؟!
چه عجب به اشتبهاهت اعتراف کردی ! مگاتکسچر هم میدونی دیگه کلا یه نوع تکنیک تکسچر ایندست که یواش یواش میرن طرفش ؟ پس ببین مایکرو چطوری اینده را حساب و کتاب کرده !
آقای کارشناس اصلا یکبار هم لینکی که دادی رو خوندی؟ اصلا میدونی تکسچرها تو بازیا چجوری استفاده میشن؟ تو این لینک دقیقا کجاش گفته شده 9 گیگی فشرده میشه، میشه 16 مگ؟
فرخ و بابک عزیز، من اصلا با پلتفرم کار ندارم،چه DX و چه X1 (چون در هر صورت فکر میکنم مایکرو از این تکنیک تو X1 هم استفاده میکنه) اصلا قابلیتی که 9 گیگ رو فشرده کنه بشه 16 مگ نداریم! اینی که شما لینکش رو دادید و شرط میبندم حتی نگاهش هم نکردید و نمیدونید جیه (وگرنه همچین حرفی نمیزدید که مجبور بشید سریع پست رو پاک کنید!) درباری تکنیک لود تکسچرهای حجیم هست! متاسفانه این چیزی که دست گذاشتید روش تخصص و کار منه. توی بازی ها همه مدل ها لوپولی هستن. یعنی وقتی میخوای UVW مپشون رو باز کنی مجبوری همه تکسچرهات نورمال مپ و دیفیوز مپ باشن و کلا دیتیل رو اینجوری بدی. منتها ایراد اینه که اگه بخوای حجم دیتیلی که میدی بالا باشه باید رزولوشن تکسچرهارو ببری بالا که حجمشون میره بالا. تو این تکنیک نمیان کل تکسچرها و لایه های نرمال مپ و دیفیوز رو باهم بیارن تو رم تا حجم زیادی رو اشغال کنه، بلکه همه این تکسچرهارو به اندازه های کوچیک قسمت میکنن و بر حسب میدان دید همونی که لازمه هی میاد تو رم و هی میره بیرون. اینجوری میشه مثلا یه تکسچر 3 گیگی رو تنها با 16 مگ رم نشون داد! منتها تنها چیزی که هست اینه که اینکار سرعت خیلی بالای رو میطلبه که DDR3 نداره اما ESRAM به راحتی اینکارو میکنه. (من الان بیشتر تحقیق کردم و دیدم اشتباه میگفتم و اتفاقا ESRAM خراکه مگا تکسچره)
یه همچین سیستمی رو هم انجین UC داشت و یادمه تو UC2 میگفتن ازش استفاده میکردن. البته تکنیک اجرای ان کاملا فرق داشت و اینکارو کرده بودن تا علی رغم رم داغون PS3 بتونن تکسچرهای باکیفیت رو تو بازی بیارن.
بهتره قبل از اینکه ادعایی بکنید و یه سری لینک پشت سر هم ردیف کنید خودتون یه سر بهش بزنید و ببینید چیه. بد نیست.
فرخ منظورش رو بد رسوند
این تکنیک فقط مقداری که نیاز هست رو میاره روی رم ولی مشکل قبلا اینجا بوده که با حر حرکتی تو دنیا بازی اون مقدار نیاز فوری باید جابجه بشه که پهنای باند رم های معمولی این سرعت رو نداشتن و باعث افت فریم یا دیر لود شدن تکستچر میشه (بلای بازی RAGE) ولی الان با پهنای باند فوق سریع ESRAM این مشکل برطرف شده..
در کل فکر کنم این ESRAM یک چالش بزرگ برای بازی سازها باشه و کار کردن باهاش بسیار سخته..
پستم رو پاک کردم چون قبلش امیرعلی لینک + توضیحات رو داد. تو اول خودت رو درست کن که بدون تحقیق ملت رو مسخره نکنی
اینکار با طرفندی به اسم Tiled resources انجام میشه و اتفاقا از ملزوماتش داشتن یه حافظه فوق العاده سریع هست چون باید یه بافر اختصاصی برای اون تکسچر به وجود بیارن.اساس کارشم اینه که از یه تکسچر بزرگ فقط اون قسمتی تو معرض دیده روی حافظه قرار میگیره.
Google