📜 ⬆️ ⬇️

Stress test teams: how to make a GPU benchmark and do not overheat

Hi, Habr! We returned to the blog with a story about the latest release. UNIGINE team released a new GPU-benchmark Superposition with VR features in April. We filled new bumps, invented a couple of dozen sudden rescue solutions and a new technology in 3D graphics.

Inside the post there are many beautiful renderers, several dramas with a technical slant, 4.5 artists, evil Valve moderators, upset AMD, NVIDIA and Intel and commits from the operating room. Come on in!



In the beginning there was a demo


We released our first benchmark 10 years ago, in 2007. Then we made another 3D demo, which turned out to be so demanding that it only worked on top-end video cards at that time, the rest did not cope, braked and overheated. Began to think what to do with it? And they decided: since the demo loads iron so much, why not use it? What can it be useful for? Thus, the first benchmark Sanctuary emerged from the by-product, and at UNIGINE - one more direction.
')

Graphics in 2007 is no longer impressive, but it is nostalgic.

Who and why do we need benchmarks?


GPU benchmarks have a rather specific, but constant audience. Basic free versions diverge in tens of millions. Overclockers need them to compete in squeezing performance out of iron. For gamers, assess whether their video card will pull the latest hit toy. Iron manufacturers need benchmarks as a “ruler”, which can measure the results during development. Computer stores and repair shops benchmark is useful as a tool for output control of the stability of the computer assembly.


We released the third benchmark (Heaven) in 2009, and it is still used by millions of people around the world.

And why do they need us? Since the benchmark task is to load iron to the maximum, we, without being embarrassed in the media, show the level of graphics that can be done on the UNIGINE engine, and what will become the standard in 3D graphics tomorrow and the day after tomorrow. So benchmarks are also a very clear demonstration of technology, and additional marketing. The most frequent phrase of customers who came for the engine: "And, I know your benchmarks, I use them all my life!" However, there is a minus: some people think that the benchmark is just an application on the brake engine (and this is far from it). We have to explain that extreme load is so conceived.

And thanks to the benchmarks, we work closely with the manufacturers of graphics processors, so that in the video drivers inside your computer there is always optimization for UNIGINE. All is well: vendors have a reliable performance test, and our developers have access to tomorrow's hardware. Naturally, there is a fly in the ointment: vendors often hate us. It seems to everyone that on our benchmarks, their video cards have a weak performance and, on the contrary, their competitors are too high. So NVIDIA periodically believes that we sold out to AMD, and AMD - that we sold out to NVIDIA.

They thought about the demo, and then it started


The project, which eventually turned into a benchmark Superposition, began in March 2016. We wanted to complement the SDK engine UNIGINE 2 with a new interior 3D demo. Why the interior?

We have accumulated a lot of demos with large spaces from horizon to horizon. Therefore, some clients began to perceive UNIGINE 2 exclusively as an engine for scenes of planetary scale. He really does a great job with them, but he also knows how to make detailed detailed plans. Here is a project that would show all the capabilities of the engine when working with close plans, we as part of the UNIGINE 2 SDK just did not have enough.


On the UNIGINE 2 engine, you can create scenes in real-time up to the size of the solar system.

Lamp setting


We immediately decided that we didn’t want to make a modern designer interior: too sterile, too visually boring. Yes, beautiful. But from the next licked picture of the eye just slides off: oh, interiorik, we look further.

We were going to make our demo scene like looking at and exploring. For this, it is not enough just to fill the space with objects and make a cool render. In order for the room to be interesting to “stay” and carefully consider it, there should be a story behind it.

So, artists had to come up with a concept and a setting. To the room was both unique and recognizable. Since our engine, and especially benchmarks, are used from Australia to Scandinavia and from Singapore to California, we needed human images that were understandable in any country and culture. And such that at first glance fantasy played out and asked for supplements.


The first refs for the concept of the future benchmark were collected from films: fiction and films about prominent scientists of the 20th century.

Best of all for the international product were the visual refs from the cinema: made in Hollywood know everything and everywhere. We have already decided that the “room” will be a classroom or laboratory. So the artists reviewed the sea of ​​films where they study or conduct experiments: from "Edward Scissorhands" and "Flies" to "Imitation Games."

Most of all, the style of scientific laboratories of the 40s and 50s caught on: a boom in the development of science and related romance, a type of genius scientist that appeared at the same time, spending days and nights at work. So we decided on the setting: we are making an educational lab-laboratory from the 1950s. A team of artists gathered a rough first scene from primitives and sat down to create content.



Pre-production: outline composition of the scene.

Artists were given complete freedom and 3 months time. The main thing that was required: to give the maximum quality and rich content scene. Although the prospect of turning a demo into a benchmark was right as long as the task was limited to a static scene without logic, but with a lot of different objects. At the pre-production, we considered that we needed to make unique items about 120. For a period of 3 months by 4 people the task was difficult. But not impracticable.


So the laboratory looked for the second month of work.


So she began to look six months later, in October.

And not a telescope at all, but a very portal.


It was the second half of the second month. Our laboratory has overgrown with details and more and more became similar to itself. But she still lacked very little - the central object. The leading 3D artist and art director of the entire project Davyd was responsible for the concept and production of the “main character”.

To design a lot of references were collected: laboratory equipment, machine tools, robots, sci-fi units. The number of files in the classroom \ refs \ center_object folder has grown. Initially, the idea was to make a teleport from small objects. Two coasters, with one object disappeared, and on the other teleport. But after a couple of days of stubborn blocking (as the artists call the stage of building a silhouette out of primitives), the result still did not suit. Everything invented did not fit into the geometry of the room. The central object either needed to be placed in the very center of the room, and then it looked like an altar, or somewhere in a corner, but in this case the object ceased to be central.


There were a lot of ideas of the central object, even more visual references.

As a result, Davyd came to the conclusion: you need to try symmetrical geometry. Having rummaged in the reference, I found a photo of this symmetric unit with colored protruding "horns". Something they resembled thorns on the head of the Statue of Liberty, and at this moment immediately before my eyes I "clicked" on the image: we need a large, detailed piecework with thorns on the "head". Yeah, we'll put the doors in the front, so that a person can enter there and somehow settle down inside. And to make it easier for him, we will make a slight slope. And behind it is necessary "meat" - cylinders, tubes, wires, and surely asymmetric! The idea and image formed, it remained only to sit down and do.


This photo helped to finally come up with a portal from the Superposition.

As we learned after the release, this photo shows a gas-dynamic trap at the Novosibirsk Institute of Nuclear Physics. They say that you can go on an excursion to the institute. So if you are from Novosibirsk, you have every chance to see the prototype of our portal alive.

By the way, we wrote that we had 4 artists, but in fact there were 4.5 of them.
Closer to winter, when the number of objects in the laboratory was selected to 700 (and all were interactive!), We had a freelance remote artist from the mining town of Prokopyevsk. Stepan, a classmate of our lead over the artists Davyd, together with him began to “model something” at school, but then he abandoned it. And now decided to make up.

“Maybe you need to model something there? Otherwise, I'll die here, ”wrote Stepan from somewhere in the Kuzbass winter. He was ready for the interest and pumping skills to do small objects. Rulers, scissors, compasses, pens, pencils, erasers, a whole sea of ​​other trifles that are important to the atmosphere of a working disorder in the laboratory are all made by Stepan’s hands. So in the release version of Superposition of objects it became more than 900.

We will make a new benchmark, with VR and interactive


Three months allocated for the production of content, resulted in four. Conceived scene was ready. It remained to add a minimum of logic and interactivity - and that's it, you can send it to the SDK!

But the final transformation of the demo in the benchmark was influenced by two things. By September, there were already 600 objects in the scene, and she was successfully doing what was required of the benchmark: how well the GPU was loaded. Second, Sasha, a game logic programmer, came to the team. All the other programmers were painted on projects, but now we had another person with the necessary skills to create an interactive part.

And I wanted to have interactivity for a long time, because until this point all UNIGINE benchmarks were somewhat static. By Heaven and Valley you can walk, but no more. Because of this, we often encountered the opinion that everything is static in the UNIGINE engine. Do you want interactive? Will you interactive!

In parallel, there was a mass VR boom. HTC Vive came out, Oculus Touch should have appeared for Christmas. For the clients of the UNIGINE 2 engine, we have added VR support for a long time - with the same Oculus Rift, the engine is compatible with 2013. But UNIGINE has not yet had a publicly available VR product. And in our room-laboratory with a bunch of items and a legend about the professor VR and it was suggested.



So, by the autumn the task has become more complicated: it will be a benchmark with an interactive mode, VR support and the most advanced graphics, so that the video cards will have enough of it until 2020. Hurray, work again!

Because of the sudden VR, a problem appeared: what looked normal on the monitor seemed distorted or disproportionate in virtual reality. For example, the teaching desk turned out to be too big: “Yes, you can carve a horse on it!” Said the artists when they looked at the stage through the helmet. And once again sat down for the content, adapt everything for VR.

We had to spend a lot of time interacting with objects in VR: the controllers have no feedback, but you need to give the user a realistic feeling of different objects in their hands. Throwing objects is also a non-trivial moment, done in several iterations (difficulty in determining a realistic throw vector). About this there are already good articles, for example, this one is the original and the translation in Habré .

Moving to VR is also special. For example, experimentally, we found out that it is better to turn the camera discretely when turning with the buttons, and not to accelerate it smoothly - this way the user is less swayed. Fortunately, with teleport in VR applications, everything is more or less standard, took aim and jumped.

The first "field tests" benchmark Superposition was held at the Tomsk IT conference in November. In the same place, without departing from the stand, we programmed two new features: a hat and a cigarette became interactive.


Steam drama


When all the TTX benchmark finally formulated, we decided to try to send the release on Steam through the Greenlight system. From past experience with Heaven, which was given the "green light" when it was no longer necessary, we knew that the software section on Steam is such a black box with the illusion of democracy. It seems that users vote, but still decide the moderators Valve. Moreover, the timing and selection criteria are unknown to anyone. Even if you are six months in the first place, the passage of Greenlight is not guaranteed.


The superposition took off right away: in the first two weeks of voting, the benchmark received 95% of the votes in favor (the usual rating of projects at Greenlight is about 40%). But it turned out it does not matter.

Just before the New Year, we happily ordered a pizza in honor of the first place in the Greenlight Run: out of 2,000 participants, Superposition on Steam was the most waited.

And almost immediately after the New Year holidays, we received a letter from the moderators that we were removed from the vote. It turned out that literally before applying for Steam introduced new rules. Now the benchmark did not fall into any category of software allowed to participate in Greenlight.


Deciding that the festive mood does not happen much, we dressed up the portal. But - early rejoiced.

Steam exploded with evil comments to Valve, they wrote about it in the newspapers , wrote on the forums. But Valve did not give up. What turned out to be not so bad: we later found out that launching through the Steam application slows down the system and degrades performance. Not too hard, but for professional overclockers, any error in performance is critical.

I guess this video card on four numbers!


Four years have passed since the release of Valley, and the algorithm recognizing the type of GPU and other system characteristics needed to be seriously updated. For the development of an updated detector sat down programmer Tolya. He came to UNIGINE at the second attempt and was actually a web programmer. But by the second approach I pulled C ++ up to the level “I can, I practice” and voluntarily took up the detector upgrade to get even more pumped.



Where do I get the data about the GPU? In each video card, four numerical IDs are sequentially sewn: vendor, chip vendor, sub vendor and sub device. The easiest option is to pull them out of the driver API. We take the ID, compare it with the iron base, we get the exact and full name of the video card. But this is the “lucky” option.


Even one video card is not easy to recognize, but what if there are three different ones in the system? The answer will be lower.

Just like that, you can get an ID from the driver API only on Windows. There the drivers are proprietary, of which our detector extracted the necessary data without serious consequences. On Linux, the zoo has many more drivers. There are proprietary drivers too, but Linux users love everything open, so there are a lot of options. Even more complicated Tolin's life is that in most Linux “firewood” there are no necessary APIs at all and the configuration of a video card with a few lines of code can no longer be pulled out. We have to get florid.

On Linux, the detector needs to get into the files that are produced by the video drivers. Depending on the model of the card and the “firewood”, these files are stored in different places and are called differently. A pack of detector code knocks on system commands, on thermal sensors and other places, finds files and, like a good cop, extracts information from them. It is especially difficult to do this without a root access level.


Fragment of the very detector code that got us data under Linux.

And what if there are several video cards in the system from different vendors? In order to understand, in principle, which video card is active, Tolya wrote a piece of code for 300 lines, which in parallel with the work of the benchmark made snapshots.

First of all, the code checked the utilization of the video card (the idea with the recycling was suggested by Misha, the lead graphics programmer). Experienced to find out that even when the video card is turned off, recycling can be from 1 to 10%. Therefore, we had to set the value to 15%, if the utilization went out more, the video card was recognized as active.

But the measurement of recycling was not obtained on all video cards. Therefore, we had to look further. The code looked at the Windows drivers and Linux nooks and asked every 200 milliseconds: “Hey, how are you going with temperature and frequency?” At the end of the run, the minimum and maximum of these parameters made it clear which video card was active. Although there also appeared "nuances". For example, we had to take into account that if the video cards are nearby, one can simply heat the other. So, the drops did not count up to 2 ° C for the changes.

Another of the heaps of "private" examples. With some AMD cards, the ID of the vendor 1002 did not return in the hexadecimal system, as it should, but in the decimal. In this case, the video card was not detected at all, and the detector produced the result “0 video cards”.


For each such particular algorithm had to file. Considering that in the database we assembled, the currently living video cards turned out to be more than 9000 variants, there were a little more details than a lot.

In general, the definition of iron is not a trivial task, and almost no one knows how to do it cross-platform. You can, of course, license the CPU ID SDK libraries (as was done in 3dmark) and the GPU-Z SDK, but they only work under Windows.

When, after three weeks of the inhuman efforts of Toli, the detector was ready and we checked everything we could reach, it became clear that this was a drop in the sea of ​​the whole variety of GPUs. Attention, the question is: where to get more different iron to test on any decent sample?

Full internet configurations


And we decided to announce open testing. Two detector assemblies for Windows and for Linux, respectively, scattered across the forums and community asking for help with the tests. Those who wanted to participate in the development needed to launch a detector and send us the resulting logs and screenshots of CPU-Z and GPU-Z, as the only intelligible standard.

Have you ever asked strangers on the forum to download and run unidentified * .exe? Try it! “Do not run, there is a virus!”, “Yes, it bitcoins mine!”, “Doctor, it determined the serial of my motherboard!”, “Yes, these are generally some Russians. What do you want to say, do Russians work in UNIGINE? Clearly phishing, do not get fooled! ”


Open testing is awesome. But when you have more than 400 such screenshots, you have to sweat.

We were banned, we were banned, the PR man corresponded with the moderators, arguing that this is not a camel, but really UNIGINE. Then we wrote in official social networks: calmly, comrades, testing is underway. The cautious public realized that this is really us. And that you can participate in the development of a new benchmark UNIGINE.

And the real Log Rush began. Andrei, the main Superposition project, raked mail for days, answered emails and downloaded user logs scattered across the forums and social networks. As a result, we collected 450 results, with the help of which we managed to calibrate the detector. And volunteers still continue to send their logs sometimes.

Want some new tracing?


The benchmark was originally wanted to be released at the end of 2016, but the release moved to the first quarter of 2017. First, the Christmas rush is not the best time to release a mass product. Secondly, the priority for us is, after all, the engine and the non-shifting release of the UNIGINE 2.4 SDK . But now there is a time to add to the Superposition a new tracing technology - SSRTGI (Screen Space Ray Tracing Global Illumination), on which Michael, one of the programmers of the engine, and Davyd, the leading artist, worked together.


Lighting without SSRTGI // Lighting with SSRTGI on

The usual screensaver effects SSAO and SSGI do not use tracing. Yes, they make a 3D-image more similar to reality, but “cheat”: they try to reproduce a similar picture to a real one, but not at all in the way real lighting works. It helps to a certain extent, but the difference is still visible at first glance.

We made a technology built on the principle of ray tracing in the real world. SSRTGI takes into account the movement of rays, reflection from objects, obstacles, shading, and evens out the normals in the transitions between objects. In the end, we got a picture that is comparable in quality to the offline renderer, but in real time. Objects remain interactive. Each can be moved as you please, and it will not stand out sharply from the rest of the picture, as often happens in games.


Lighting without SSRTGI // Lighting with SSRTGI on

How the SSRTGI technology works, we will tell in details in the next post, along with the release of UNIGINE 2.5. In the meantime, the device effects and their work on different settings can be viewed in the game mode Superposition, including debug.

Music perfect for repit


Misha Paralyzah wrote the music for all our projects (the previous benchmarks and the game Oil Rush), he also started the Superposition soundtrack. The difficulty is that the benchmark is usually run repeatedly, and the music should not tire the user, but at the same time it is an important component that forms the overall impression. Plus, the music should ideally fall on the spans of the cameras in order to maintain the pace of what is happening.

We did not have the opportunity to record the symphony orchestra alive, so Micah collected the soundtrack in his home studio, with just a good base of virtual instruments, midi-keyboard and many years of experience. You can listen to the result yourself - the measured sounds of the piano are picked up by the fierce cello, and electronic notes are intertwined with them, when on the screen the power of science overcomes gravity and time.



All the pain of manufacturers


We have already mentioned that one of the advantages of benchmarking is working closely with the developers of graphics processors. On the one hand, this is a great perk: direct contact with engineers and access to the hardware of tomorrow. On the other hand, the project adds a large amount of work.

The first pre-pre-alpha vendors issued before anyone else, in November. But they got into an unsuccessful period: then their laboratories were fully occupied with tests of Advent games. "Let go" of producers closer to March, but all at once. We were alternately and simultaneously fired from three sides with the results of lab tests and NVIDIA, and AMD, and Intel. It seemed to those and others that it was their Superposition video card that somehow underestimated. We are only interested in the optimization of critical things for users. Due to the lingering silence of the vendors, a large chunk of this work came in the last weeks.

GPU manufacturers suffered. “Over the weekend, your settings have changed three times!” - Some were indignant. “Our video cards are much better, this is your wrong benchmark!” Others were indignant.

After refinement and optimization, we reached a balance by long correspondence: the benchmark still did not suit all manufacturers equally, but at a minimum. But the benchmark had everything the user needed: an accurate measurement of the performance of a wide variety of video cards.

Leaderboards? Leaderboards!


Under each news about UNIGINE benchmarks, screenshots with results are sure to appear. On every self-respecting overclocker and computer hardware forum, threads grow with results, for example, Valley has an epic thread of 1300 pages. And we decided: since we are already the fifth benchmark, it’s enough to sit on other people's forums. It's time to start your own leaderboards ! About them, we suddenly and stumbled. The whole process of production and release of the benchmark from and to was known for a long time, and it was easy to plan it. But the development of leaderboards was until the time hidden by the fog of war.





Hurray, release! Oh, wait ...


We postponed the release to the end of the first quarter, and it took just a few days to meet the deadline. Benchmark should be done immediately with high quality, release patches and versions 1.1.1., 1.1.2. no opportunity: “float” the results. The product should be immediately finished and stable. So that both our engineers, vendor laboratories, and beta testers could test the benchmark to the maximum, we moved the release to April 6th.



On the morning of April 6, it turned out that the world froze in anticipation. “I specifically took the day off, because the Superposition is coming out! When is the rock? ”Wrote James from the UK. “It's April 6th! Where is the benchmark? ”- wrote Bruce from the east coast of the USA. “I started this thread in advance, because today Superposition will be released. In the meantime, I will arrange the theme beautifully! ”- wrote on overclocking forums. "How are you doing? Soon? And you will write to me? ”James wrote again. Then Bruce. And Steve. And Marco. And a few dozen users through all possible channels of communication.

A couple of weeks before the release date, we realized that the amount of work on launching a new website with leaderboards and the entire back-end associated with it was underestimated. We chose the most critical one: launch a new website with benchmarks, download from it, user authorization, the payment system and, most importantly, the collection of results into the database, from which the standings will then be formed. Plus dock the front end with the back end.

About the evening of the first attempt at release, we shot a small but dramatic video:


On the night of April 6-7, the Superposition benchmark itself was ready and hands were removed from it. But the critical part of the back-end and the front-end still refused to work as it should. The release decision was moved by April 11th.

During these 4 days, the frequency of commits on the web has tripled. Twice the hero of Tolya’s detector and back-end according to plan (not because of the release!) He went to the hospital where he never stopped committing, and only the anesthesia stopped him. For an hour. Web programmer Lenya also stopped leaving work. Stop quitting QA.



Here we have to go back a little to the drama with Steam. The volume of distributable distributions on this release was significantly larger: the build of Superposition weighed 3 times more than the last Valley. And those who want to quickly download the new benchmark UNIGINE has also increased since then. We were counting on Greenlight and Valve's server, which would have distributed files without any problems. And they were absolutely not prepared to distribute a couple of tens of terabytes of traffic per day. Yes, we are aware of the torrent, but a significant part of users for ideological reasons does not use them.

It was necessary to have a quick solution so that everyone could download the long-awaited benchmark, our servers would not fall and that would not cost the company astronomical money. Sergey, our IT director, turned gray by 10% while his department was looking for how to do it.

As a result, they came up with a scheme: buy a bunch of small hosting sites for $ 5-10 and scatter our files over them. People coming to the benchmarks, redirect to these hosting servers and mirrors in random order, and so unload our servers. As a result, we made 11 mirrors for a budget of 3000 rubles. This is how the traffic of only one server on the night of release looks. We distributed a part from our servers with restrictions in order not to lie. Part - from the mirrors, which periodically fell on and off. The second Sergey from the IT department wrote a separate utility with 150 lines of code, which once a minute monitored the state of the mirrors, turned off the “dead”, and when they came to life, turned them on back into the distribution. In order to be in time for the release, I had to choose priorities: launch a new website







, prepare everything for distribution of builds, set up the collection of user results into the database of future leaderboards.

The requirements from web developers have suddenly fallen - we would have 32 GB of RAM on the server. All other UNIGINE web-projects were not sharpened by the download: for each site only a gig-two RAM was required. Therefore, a request of 32 GB of RAM for one site turned out to be extremely unexpected. The IT director turned gray by another 10%, but still managed to buy and configure the server in just half a day.

By April 11, we had a ready-to-launch part of the back-end and front-end. No sooner had the sun come up over California, and the entire invisible part “under the hood” was already finished. And after the final tests and the three “final” versions of the final build, on April 11 at 23:00, we put the Superposition into the download. And finally exhaled: the release happened.

It was easier to push the release than to cancel the cake ordered in his honor. So the cake came to us on April 7th. The team of artists is tired but happy: their work on the project has definitely ended.

What is not finished?


From the very first post about the benchmark, the most questions were asked about the support of Vulkan and DX12. Vulkan has a promising future, but for now the API is not yet stable on all platforms. DX12 works only on Windows 10, and not all users of our benchmarks (which we know for sure thanks to the detector) have moved to the top ten. Therefore, we have postponed the integration of Vulkan and DX12 to the next versions.


Overclockers from all over the world stocked up with liquid nitrogen in anticipation of a superposition.

By the release, we never mastered the support for SLI and CrossFire. Physically, both work. But CrossFire produces graphical artifacts, and SLI does not affect performance and sometimes also produces artifacts, depending on the configuration. This is due to the peculiarities of the effects of TAA (Temporal Anti Aliasing) and SSRTGI and the design features of multi-GPU interfaces. Textures for rendering each frame in SLI and CrossFire should be synchronized between two or more video cards, but the transfer speed is strongly limited by the bandwidth of the PCI Express bus. If the render goes to the extreme settings of 4K and 8K, the size of the textures becomes even larger, as the volume of data transmitted through PCI Express. Therefore, often real-time graphics, where there are temporal effects, do not scale well in SLI and CrossFire.

On individual configurations, there will be a performance boost - if SLI and Crossfire support AFR Friendly. Then the textures are not synchronized, each video card counts its frame, the bus is not loaded with the transfer of unnecessary information, and the performance grows (although in SLI, again, not on all configurations). But due to the lack of synchronization, graphic artifacts appear.

How to stabilize this for all configurations, we have not invented for the release. There are options for how to defeat this: reduce the number of synchronized textures, compress the data, try changing the synchronization method, abandon temporal effects altogether. But this task is not fast, so the optimization for multi-GPU moved to future versions of Superposition.


Superposition conquers the world - photo from Gamers Assembley in France, the largest European game festival

Leaderboards with the entire front-end and back-end completely overpowered and launched 3 weeks after the release. Overclockers with liquid nitrogen have already been registered in them on the top lines - it’s quite difficult to catch up with the average user, but you can try!

Dry total


In fact, in a post, far from all the dramas are told and not all the characters are mentioned. The whole saga would have taken a couple more posts. And, although it didn’t go without files, it’s impossible not to be proud of the results of the year of work that has passed from the beginning of the production of the demo to the release of the benchmark Superposition.




For the first day we collected 13,000 results in the database. At the time of publication of the post, Superposition was installed more than 100,000 times and the installation rate is stable. In total, the work did not exceed 6100 commits, 1,437 of them in the last 90 days before the release.

The code is written (not counting engine modifications), in the lines:


In the final assembly of 900+ objects and 400+ textures.
Collected RC-versions - 7.
Burned in the name of the release of video cards - 1.

And finally, on the day of release, a lot of reviews and articles about Superposition. The release of the benchmark was written by all the top popular world portals for hardware, for example, Tom's Hardware , TechPowerUp , VideoCardz.com and native IXBT . Began to go video reviews from users and videoblogerov.

You can evaluate the result yourself by downloading the Superposition . Despite the fact that at the highest settings, the benchmark is able to bend any modern system, thanks to the different quality presets, you can run it on a computer 4-5 years old.

Or look into the future of real-time 3D graphics by watching the video in maximum quality and at a resolution of 8K. This mode is also in the benchmark, but not all top-end video cards can withstand it:



All beautiful graphics and powerful iron. See you soon in our blog!

Source: https://habr.com/ru/post/328082/


All Articles