[enderandrew]

 Hank, on 24 September 2018 - 08:35 PM, said:

^ I'm lost.
Help please, in English slang: what does punting mean then? I understood it as putting Vulkan on the sidelines for now, since it's implementation for RTX would require the 2080 cards for starters?

In American football, punting is kicking the ball away.

icecoldduke said:

'VK RT extensions are not available on my 1080, I just created a simple app to check.

Do you have the new 411.63 drivers that came out a few days ago? I suspect it may take a while before Nvidia backports support for it to the 10 series. But it might come in time.

[lamduck]

From Jon Peddie Research, may be rumor so take with grains of salt, one thing for sure the next few months will get interesting:

As far as how the new NVIDIA technology impacts its competitors, Peddie adds, “AMD will react. They already have an AI accelerator in the works which they announced at Computex. It’s expected out later this year. AMD has their own ray tracing software too, so you can expect to see them making real-time ray tracing announcements in Q4. They will likely use Microsoft’s DXR because in general, AMD prefers to go open source. Intel, which is expected to introduce a discrete GPU in 2020, may pull that in and make a surprise announcement in 2019. But even if they do, it won’t have AI acceleration.” With regards to Intel, Peddie went on to conclude, “They are in an awkward position of being a bit behind the curve with their product entry, which I would guess was part of NVIDIA’s motivation in this surprising announcement. Intel will probably be able to offer real-time ray tracing by 2021-2022 at the latest.”

[Romulus]

 enderandrew, on 25 September 2018 - 11:15 AM, said:

Do you have the new 411.63 drivers that came out a few days ago? I suspect it may take a while before Nvidia backports support for it to the 10 series. But it might come in time.

I can answer that one. Yes, he is using the 411.63 set of drivers, because it is the only public unified driver available for the RTX series of cards.

[icecoldduke]

I don't think NVIDIA will create a Vulkan RT fallback layer for Pascal and earlier GPU's, it wouldn't make sense. DXR Fallback on Pascal can render albedo only at framerate. The build engine is one of the few engines that would benefit from raytracing on non RTX hardware. Major engines, UE4, idTech and Unity wouldn't benefit from raytracing driver emulation, they can stick with rasterization on non RTX hardware. However if NVIDIA does release something I'll jump on it.

Some updates:

I started to implemented DXR into build and committed quite a bit of stuff to my github(PolymerRTX Github). Basically all the stages of initilization required for DXR and D3D12 are implemented and working. The game will run right now, but it won't render anything. Next I'm going to modify the map loader so I can build the DXR acceleration structure and start to render stuff.

[Phredreeke]

This may be a very noob question but how would Build engine benefit from ray tracing outside of light effects?

[icecoldduke]

 Phredreeke, on 26 September 2018 - 06:06 AM, said:

This may be a very noob question but how would Build engine benefit from ray tracing outside of light effects?

In build you can create very complex layouts that aren't friendly to rasterization. Here's an example: rooms crossing over other rooms. In a normal engine, if I put two rooms that intersect each other, players could see the room intersection, which sounds like something you would expect. However in build that isn't the intended outcome. The big issue with build is draw call overhead. I have to submit many tiny draw commands to the GPU, so I don't get any overdraw that would cause portal hidden rooms to be visible when they shouldn't. Build is unique to this issue, because overdraw can cause visual artifacts and not just performance overhead. With raytracing things become a bit easier. Once I have the BVH acceleration structure ready(there's going to be some work here), I just basically create a single draw command that includes the raytracing shaders, the BVH structure, and the camera stuff. So in theory I take many tiny draw commands and only submit a single draw command. Eventually I hope to create a custom intersection program that will work with the BVH acceleration in RTX, that doesn't need triangles, instead just intersects with build data(either using SDF's or something else), which would mean I could take out the triangle generation in PolymerRTX, which would mean you guys would have the ability to create classic style effects in PolymerRTX.

My idea previously for solving this issue was to use Vulkan or Direct3d 12, since both APIs allow developers to control command buffer generation and when those command buffers get submitted to the GPU. GPUs have something similar to the concept of cores on CPU called wave fronts that allows the GPU to crunch work in parallel. So for example, if I submit a single 500k poly mesh to he GPU in one call, it would be faster then submitting many tiny draw calls that render the same thing, even in Vulkan or D3D 12, because the GPU will run the single call in parallel with more parrallelization.

DXR will definetly saturate the wave fronts, and I think I'll get more performance out of DXR then any of the methods above.

[enderandrew]

 Romulus, on 25 September 2018 - 11:29 PM, said:

I can answer that one. Yes, he is using the 411.63 set of drivers, because it is the only public unified driver available for the RTX series of cards.

He was talking about a test he performed on his 1080, so I don't know if he was using the brand new drivers on his 1080.

[icecoldduke]

 enderandrew, on 26 September 2018 - 09:08 AM, said:

He was talking about a test he performed on his 1080, so I don't know if he was using the brand new drivers on his 1080.

My computer is a laptop, the 2080 is a external card and my 1080 is a internal card. So yes I have to be using the same drivers, since its the same computer .

[icecoldduke]

Here is a picture so you can visualize my setup . The 2080 is in the black box with the blue light, the 1080 is in the laptop, I can simply switch between the two by unplugging the black box from the laptop.

[Romulus]

 enderandrew, on 26 September 2018 - 09:08 AM, said:

He was talking about a test he performed on his 1080, so I don't know if he was using the brand new drivers on his 1080.

If the cards are on the same PC, you can't use different drivers for hardware from the same vendor, which in this case is nvidia, hence I used the term "Unified" driver as it suggests every active nvidia GPUs are supported in the same driver package. I was shocked to learn that he managed to get DXR Fallback working on a version of windows that is earlier than build 1803.

[Micky C]

Out of curiosity, does polymost use rasterisation, or some other technique that’s closer to the classic renderer? I’ve heard discussion in the past of how it’s basically “classic implemented in openGL”, and that it does a lot more work on the CPU than a standard 3D renderer, only passing certain aspects of calculation to the GPU.

[icecoldduke]

 Micky C, on 27 September 2018 - 01:46 AM, said:

Out of curiosity, does polymost use rasterisation, or some other technique that’s closer to the classic renderer? I’ve heard discussion in the past of how it’s basically “classic implemented in openGL”, and that it does a lot more work on the CPU than a standard 3D renderer, only passing certain aspects of calculation to the GPU.

Yes both Polymost and Polymer both use rasterization. The delta between the two renders is how each converts the build data to geometry for rasterization. Polymost's approach is on the slow side, but its the most accurate(I do remember you guys complaining about issues with Polymost that weren't buggy in classic). You could get performance gains in Polymost by converting it from OpenGL to Vulkan. I just don't know how big those gains will be. Even if you build the command buffer yourself, you still filling that command buffer with many small draw commands, which require a bunch of random access reads into a VBO. Aside from what I stated above, I don't know how well the memory prefetcher will get that data into the various caches before the data is required by the shader(if the data isn't there in time, you stall). There are a lot of unknowns with DXR, and there are a lot of knowns with Vulkan. I know were all the issues are going to be with continuing down the rasterization route, eventually you will hit a ceiling and the geometry passes are going to take a lot longer compared to other engines. Which means most mappers will be making hard choices between map complexity and enabling fancy effects, this is true in all game engines, but even more so in a PolymerNG style renderer. One of the good things about raytracing is, no matter how many sectors you guys have in your map, it won't affect GPU performance.

So its possible in the standard Duke3D and SW maps, a Vulkan Polymer/Polymost will out perform PolymerRTX on non DXR hardware. Most people now-a-days play usermaps, and I think this is were PolymerRTX will shine on some non DXR hardware, and I also think in both cases, PolymerRTX will out perform in standard maps on DXR hardware.

EDIT:
I have all the DXR rendering code implemented, and the map loader is already modified to build the DXR acceleration structures, but for some reason I only get a black buffer on screen. That's the next thing to resolve.

[TON]

You should also check line of code #2604 in polymer.cpp

https://github.com/j...lymer.cpp#L2604

[icecoldduke]

 TON, on 27 September 2018 - 10:29 AM, said:

You should also check line of code #2604 in polymer.cpp

https://github.com/j...lymer.cpp#L2604

Lol while no code in a for loop looks terrible, I have more code locally that I haven't checked in.

However regardless I should be getting a blue buffer, even if there isn't any geometry. The "miss" shader in DXR is called when a ray doesnt hit anything, and if a primary ray misses geometry I have it write a blue rgb value to the render target.

[Hank]

my turn for an ignorant questions ...
Any ideas about RTX 2070? They'll come out in October ...
Is it a mystery sales pitch from nVidia, or worth buying (upgrading) them?

[icecoldduke]

 Hank, on 27 September 2018 - 07:25 PM, said:

my turn for an ignorant questions ...
Any ideas about RTX 2070? They'll come out in October ...
Is it a mystery sales pitch from nVidia, or worth buying (upgrading) them?

I'm not a fan of the initial $599 price point for the 2070. For $200 more you can get the 2080 which is a superior card by a decent margin. However if the 2070 ever comes down to MSRP($499) and can match the performance of a 1080 in non DLSS/RTX games and can exceed/match a 1080 ti with DLSS enabled, then I think its worth getting. The 2070 will definitely speed up PolymerRTX compared to non rtx cards, but the 2 "gigaray" delta between the cards is worth looking at, not only for PolymerRTX but for big AAA titles that will have RTX enabled.

My thoughts: Save up $200 more and get the 2080 if your going to upgrade.

[icecoldduke]

The color buffer still renders black, but I'm getting used to the new Pix and debugging DXR with it. I discovered huge bugs with my DXR acceleration structure, were geometry was not looking right at all. Just got that fixed. I can't pan over in the pix pipline camera, but you can see the starting area in E1L1 actually looks somewhat proper(without the sprites of course).

[icecoldduke]

Just got the game to render stuff! Fixed some of the camera code(still needs work), but I took a quick recording of E1L1 playing in full DXR. Due to the recording, playrate looks choppy but look at the FPS counter at the top of the window to see what framerate I'm getting approx 550fp when recording and 730fps when not recording at 1920x1080.

[Mark]

I think last year some time was the last time I saw you in one of your NG vids. Have you lost weight?

[icecoldduke]

 Mark, on 29 September 2018 - 10:39 AM, said:

I think last year some time was the last time I saw you in one of your NG vids. Have you lost weight?

I have lost weight. I lost about 70 pounds when I switched to diet soda .

[icecoldduke]

Did some clcoast tests. PolymerRTX vs Polymost/Polymer. Polymost/Polymer tests were done with the latest eduke32 binary(eduke32_win64_20180928-6988). All tests were done at 1920x1080 on the same video card(RTX 2080).

PolymerRTX: 866 fps
Polymost: 282fps
Polymer: 26fps

PolymerRTX


Polymost


Polymer

[Hendricks266]

That's not a fair comparison because you're only rendering geometry, not textures. Don't give misleading numbers.

[icecoldduke]

 Hendricks266, on 29 September 2018 - 03:46 PM, said:

That's not a fair comparison because you're only rendering geometry, not textures. Don't give misleading numbers.

That's a good point but I don't think performance is going to be impacted that much by texture sampling. I can't attach a single texture to a piece of geometry by just binding a texture a shader then rendering geometry Instead I think I'm going to sample textures from texture atlases.

For classic textures I can fit all them on texture atlases without a problem. HRP will be a different story

[Danukem]

 icecoldduke, on 29 September 2018 - 04:10 PM, said:

For classic textures I can fit all them on texture atlases without a problem. HRP will be a different story

Is there a particular size cutoff for what makes a texture eligible for the atlas treatment? A typical Eduke32 project will contain all the classic textures, plus thousands of new but classic-styled textures (usually 256x256 or smaller, but not necessarily), and then some higher resolution textures as well (e.g. for cutscenes, menu etc.)

[icecoldduke]

 Trooper Dan, on 29 September 2018 - 04:58 PM, said:

Is there a particular size cutoff for what makes a texture eligible for the atlas treatment? A typical Eduke32 project will contain all the classic textures, plus thousands of new but classic-styled textures (usually 256x256 or smaller, but not necessarily), and then some higher resolution textures as well (e.g. for cutscenes, menu etc.)

I'll know more when I get things implemented. Is there any textures in the HRP that aren't power of 2? That's my biggest concern at this point.

[Mark]

I don't remember ever coming across one in the HRP.

[Danukem]

 icecoldduke, on 29 September 2018 - 05:49 PM, said:

I'll know more when I get things implemented. Is there any textures in the HRP that aren't power of 2? That's my biggest concern at this point.

Wouldn't the correct question be, does EDuke32 support textures that aren't power of 2?

The HRP is just one fan-made mod among many that have been produced for Eduke32 over the years. It's popular, yes, but it's not the only popular mod. Why does it in particular concern you so much? It worries me that you already seem to be thinking about the vanilla game and the vanilla game with HRP textures as your 2 targets. A typical EDuke32 project doesn't fit into either category. My concern is that you will make decisions based on the assumption that projects are either "classic" or "HRP".

[icecoldduke]

 Trooper Dan, on 29 September 2018 - 06:22 PM, said:

Wouldn't the correct question be, does EDuke32 support textures that aren't power of 2?

The HRP is just one fan-made mod among many that have been produced for Eduke32 over the years. It's popular, yes, but it's not the only popular mod. Why does it in particular concern you so much? It worries me that you already seem to be thinking about the vanilla game and the vanilla game with HRP textures as your 2 targets. A typical EDuke32 project doesn't fit into either category. My concern is that you will make decisions based on the assumption that projects are either "classic" or "HRP".

Very valid point. It just never occurred to me to ask about other projects. Dumb mistake really sorry about that.

Non power of two doesnt work well for virtual texturing because you have to page in smaller tiles that need to be power of two.

[Mark]

Thats got me wondering. With your best guess, will there be much difference, if any, between how a vanilla map in software or Polymost will look compared to in your new renderer? I would imagine the lighting and normal/spec/etc mapping will be an improvement over Polymer along with a speed increase. The point I'm attempting to make is if your renderer will not really offer much over software or Polymost rendering, don't hold it back simply to be compatible with them. Those users will have a perfectly good eduke32 to use.

[Phredreeke]

How is Polymost only doing 282 FPS? I don't know the map in question but I typically get framerates in the thousands.