Duke4.net Forums: PolymerNG will use Vulkan and D3D12 - Duke4.net Forums

Jump to content

  • 9 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • This topic is locked

PolymerNG will use Vulkan and D3D12

#1

Hey guys,

I would like to let everyone know PolymerNG will use Vulkan and D3D12. I want to emphasize the D3D12 part of the renderer will get dropped when the Vulkan API gets released, and will not be in the eduke32 main depot until that point(or maybe not depending on what TX allows :thumbsup:). Initially though the renderer will use Direct3D 12. When Direct3D 12 gets deprecated by Vulkan the renderer will work on any OpenGL 4.1 compliant hardware, and any device/OS that supports the Vulkan API.

That was a heavy few sentences I would like to break down my reasoning for going down this path. The eduke32 3d renderer needed a complete overhaul. Staying with a soon to be deprecated API wasn't the right way to move PolymerNG forward. Vulkan used to be called "glNext". Vulkan and Direct3D 12 offer great performance gains that I will get into later.

The only parts I have kept of Polymost and Polymer for PolymerNG are the math functions related to build to 3D conversion, and I have made those API agnostic functions. For example say that we have rotate sprite:

Previous code:

Quote

void polymost_dorotatespritemodel(int32_t sx, int32_t sy, int32_t z, int16_t a, int16_t picnum, int8_t dashade, char dapalnum, int32_t dastat, uint8_t daalpha, int32_t uniqid)
{
[bunch of math]
[immediate draw call]
}


New code

Quote

void Build3D::dorotatesprite(BuildRenderCommand &command, int32_t sx, int32_t sy, int32_t z, int16_t a, int16_t picnum, int8_t dashade, char dapalnum, int32_t dastat, uint8_t daalpha, int32_t cx1, int32_t cy1, int32_t cx2, int32_t cy2, int32_t uniqid)
{
[bunch of math]
[render state and vertex data get stored in "BuildRenderCommand"]
}


This allows render commands to get processed at more optimal times during a frame.

This brings me into the next part, the game and renderer are now in separate threads. When the engine calls "nextpage" the render thread kicks off and begins processing the "BuildRenderCommands". The game can then continue to process the next frame, but if the renderer is still rendering by the time the next nextpage function is called the game thread will wait. The game thread can only be one frame ahead of the renderer. EDuke32 used to poll windows messages at the start of the game loop, this now happens continuously in the main thread. Due to all of these modifications winlayer.c has been deprecated in PolymerNG, and replaced with a generic syslayer.cpp.

The renderer is also API agnostic, and all API specific calls are wrapped in a Render Hardware Interface Layer or RHI.

Example:

Quote

//
// BuildImage::UpdateImage
//
void BuildImage::UpdateImage()
{
if (!waloff[imageOpts.tileNum])
loadtile(imageOpts.tileNum);

//TODO: HQ textures don't need to get converted.
char *tempbuffer = ConvertARTImage();

if (!IsLoaded())
{
bool allowCPUWrites = (imageOpts.heapType == BUILDIMAGE_ALLOW_CPUWRITES);

RHI::RHITextureFormat format = RHI::TextureManager::GetRHITextureFormat(imageOpts.format);

switch (imageOpts.imageType)
{
case IMAGETYPE_2D:
texture = RHI::TextureManager::LoadTextureFromMemory(name, GetWidth(), GetHeight(), format, (const void *)tempbuffer, allowCPUWrites);
break;
case IMAGETYPE_3D:
texture = RHI::TextureManager::LoadTexture3DFromMemory(name, GetWidth(), GetHeight(), GetDepth(), format, (const void *)tempbuffer, allowCPUWrites);
break;
}

texture->SetHardwareDebugName(name.c_str());

Bfree(tempbuffer);
return;
}

if (imageOpts.heapType != BUILDIMAGE_ALLOW_CPUWRITES)
{
initprintf("BuildImage::UpdateImage: Image not set for CPU Writes");
Bfree(tempbuffer);
return;
}

texture->UploadRegion(0, 0, GetWidth(), GetHeight(), (const void *)tempbuffer);
Bfree(tempbuffer);
}


I still haven't answered the question why did I choose NG API's? Why did I start off with Direct3D 12? The fact is Vulkan and Direct3D 12 offer granular control over how commands are batched up and sent down to the GPU. There are great performance gains to be gained there. Second Pix saves development time. Pix only works with Direct3D and as I am getting the renderer on it's feet, I don't have time to dick around with trying to figure out where bugs are cropping up from. Pix gives great debugging information.

As I said when Vulkan gets released I will move PolymerNG over to Vulkan and that is the API we will use going forward. I hope this answers some questions and I would love to answer any other questions or concerns you guys have.

This post has been edited by icecoldduke: 13 December 2015 - 07:44 PM

4

User is online   Danukem 

  • Duke Plus Developer

#2

Speaking for ignorant users such as myself, I would just like to know when we can expect to see the first build that we can play around with. Can we have something publicly available, like the synthesis builds? Also, will the early versions be a separate branch?
0

#3

View PostTrooper Dan, on 13 December 2015 - 08:37 PM, said:

Speaking for ignorant users such as myself, I would just like to know when we can expect to see the first build that we can play around with. Can we have something publicly available, like the synthesis builds? Also, will the early versions be a separate branch?


My goal by the end of the year is to have the game rendering levels with FXAA, DOF, HDR, and a couple other things, but without lighting. At that point I will have a auto build system setup, that will submit executables to my branch. I will then allow public read only access to my repository. TerminX said he doesn't want the D3D12 code in the main branch(and I can understand that), I'm hoping he will take the Vulkan code. The amount of code changes I'm doing to the engine need to be properly QA'ed, and vetted before going back to main anyway. I have a guy I know who is a junior engineer who will be doing code merges from main into the branch, I'll probably have him do it every 2-3 weeks.

The goal is once the renderer is on its feet(with Vulkan) and doesn't fuck up Polymost or Classic, that I submit the code over to Terminx to go into main and we work in main from there on out. I need to talk to TerminX to figure out what needs to happen for him to accept the new renderer, I just haven't had the time yet.

This post has been edited by icecoldduke: 13 December 2015 - 09:44 PM

3

User is offline   Micky C 

  • Honored Donor

#4

So you're saying the renderer will be capable of rendering levels to the same extent as polymost by the end of the year, plus a few extra effects? That's pretty nice! I'm hoping that it'll include support for multiple paralaxed skies in a map after all this time Posted Image (and by extension the showview command if I'm remembering it correctly). The lack of the latter has broken many features in mods.
0

#5

Nice, i'm very excited for this. Although i'm not a code techie, i always find it interesting to read code stuff. Gonna keep a close eye on this project and wish you good luck!
0

User is offline   Mark 

#6

I'm bummed out that my system won't run the new renderer even with a fairly new Nvidia 750ti card.
0

#7

View PostMark., on 14 December 2015 - 04:43 AM, said:

I'm bummed out that my system won't run the new renderer even with a fairly new Nvidia 750ti card.


Actually your card does support DX12 my apologies I was half asleep last night when I sent you that message :thumbsup:. PolymerNG will work on your card. You will need Windows 10 for the Direct3D 12 version. For Vulkan you won't need Windows 10 but I don't think Vista will be supported, but that would depend on NVIDIA releasing Vulkan Vista drivers.

Here is a list of cards that support D3D12

NVIDIA:
http://www.geforce.c.../supported-gpus

AMD:
http://www.amd.com/e...ogies/directx12

This post has been edited by icecoldduke: 14 December 2015 - 07:34 AM

0

User is offline   Mblackwell 

  • Evil Overlord

#8

Vulkan is supported all the way back to Fermi, which is the GTX 4xx series.

Currently Nvidia's driver support extends all the way back to XP for newer GL features so I assume they'll do the same for Vulkan.
1

#9

View PostMblackwell, on 14 December 2015 - 08:22 AM, said:

Vulkan is supported all the way back to Fermi, which is the GTX 4xx series.


Do you have a source for that?
0

User is offline   Mblackwell 

  • Evil Overlord

#10

Fermi supports GL 4.5, and the latest driver version for 4xx/5xx series cards (for XP) is the same version that's available for all Windows systems. During the original Vulkan talks/presentations they stated that one of the goals was to keep people from being unable to use their old hardware, and to allow it to be used on Windows XP (which is still the largest install in asian countries).

from this overview

Quote

Vulkan supported platforms will include Linux, Windows XP to Windows 10, Mobile



I think the biggest issue is probably Mac support since it relies on coordination with Apple.
0

#11

View PostMblackwell, on 14 December 2015 - 09:16 AM, said:

Fermi supports GL 4.5, and the latest driver version for 4xx/5xx series cards (for XP) is the same version that's available for all Windows systems. During the original Vulkan talks/presentations they stated that one of the goals was to keep people from being unable to use their old hardware, and to allow it to be used on Windows XP (which is still the largest install in asian countries).

from this overview

I think the biggest issue is probably Mac support since it relies on coordination with Apple.


I wasn't aware that 400 series cards supported GL 4.x, that's good to know :thumbsup:, and Windows XP being supported is also good news. This is all speculation right now, and who knows what hardware will be supported at launch. But this is great news and will strengthen my case for the Vulkan renderer to go in main.
0

User is offline   MusicallyInspired 

  • The Sarien Encounter

#12

I've got a Fermi card (460) which is stated to be DX11 only. So I guess I can run Vulkan, but I can't do DX12. And I'm not upgrading to Win10. How soon is Vulkan supposed to be fixed/released? And how long after that will it take to move to that API from DX?

This post has been edited by MusicallyInspired: 14 December 2015 - 12:28 PM

0

User is offline   Kyanos 

#13

Quote

How soon is Vulkan supposed to be fixed/released?


I'm the same boat as you, won't go win 10 for this. I looked into Vulkan, I like it, cross platform ftw. As for release, it was first announced in march with a 2015 release scheduled, but no new news regarding a release is easily available.

Here is the <best / very poor> info I found.

http://www.kitguru.n...se-vulkan-does/

Quote

While for cross-platform developers it makes a great-sense to use Vulkan, DirectX 12 still has a number of advantages. The Vulkan API is still not finalized, so it cannot really be used for commercial products right now. As a result, those, who plan to release their titles in the next twelve month, should keep using DirectX 12.

September 24th, 2015

0

User is offline   Mblackwell 

  • Evil Overlord

#14

Developers can sign an NDA and get access to it and have been able to for awhile. But generally yes, you couldn't write something for it right now. However it's pretty similar to D3D12 in the way that it works, so it's not really impossible to port between the two. Although, I'm sure the initial time-to-triangle is non-trivial.
0

#15

View PostMblackwell, on 14 December 2015 - 02:39 PM, said:

Developers can sign an NDA and get access to it and have been able to for awhile. But generally yes, you couldn't write something for it right now. However it's pretty similar to D3D12 in the way that it works, so it's not really impossible to port between the two. Although, I'm sure the initial time-to-triangle is non-trivial.


Even if I got NDA'ed into the program, it would be stupid to use it while its closed off. I couldn't release builds with the Vulkan API until its released publicly. I would also have to NDA the developers working with me on PolymerNG and that would be a pain in the ass.

Quote

I'm the same boat as you, won't go win 10 for this. I looked into Vulkan, I like it, cross platform ftw.


Wouldn't expect you too, likewise I wouldn't expect most people to use PolymerNG until its flushed out more. Vulkan is the path forward when it gets released. I can still get the renderer working without Vulkan, and it should be fairly straight forward to port the RHI layer over.

This post has been edited by icecoldduke: 14 December 2015 - 04:45 PM

2

User is offline   MusicallyInspired 

  • The Sarien Encounter

#16

Will Polymer still be in the codebase as well? Or are you removing it in favour of PolymerNG?
0

#17

View PostMusicallyInspired, on 15 December 2015 - 06:19 AM, said:

Will Polymer still be in the codebase as well? Or are you removing it in favour of PolymerNG?


Before the code goes back into main, the original three renders will work as they did before.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#18

Tbh., "NG" doesn't sound very modern nowadays. Why not give it a distinct name?

Polyphem keeps up with our renderer naming "tradition" and I expect people to come up with nice logos...
Posted Image

Or Polyfem, to emphasize the improved rendering of chicks. :thumbsup:
0

#19

View PostLeoD, on 15 December 2015 - 08:22 AM, said:

Tbh., "NG" doesn't sound very modern nowadays. Why not give it a distinct name?

Polyphem keeps up with our renderer naming "tradition" and I expect people to come up with nice logos...
Posted Image

Or Polyfem, to emphasize the improved rendering of chicks. :)


I'd rather make the renderer render pretty images rather then worry about the name :thumbsup:.
2

User is offline   Tea Monster 

  • Polymancer

#20

What do artists need to know to make content for the new renderer?
1

User is offline   Spiker 

#21

Also will bones ever be supported?

This post has been edited by Spiker: 16 December 2015 - 12:09 PM

0

#22

View PostTea Monster, on 16 December 2015 - 01:58 AM, said:

What do artists need to know to make content for the new renderer?


I will come out with a comprehensive doc after the initial release. There is a a lot to cover, but one thing I will say is keep in mind how many different effects you will enable in any given scene. I can forsee a lot of content developers wanting to cram in "all" the effects into one room, and they release maps and people start bitching about perf of the new renderer. The renderer will include performance counters, content developers will need to use them!

View PostSpiker, on 16 December 2015 - 11:58 AM, said:

Also will bones ever be supported?


Yes. The FBX model format will be supported.
2

User is offline   Mark 

#23

I think what TM might be asking is what texture maps will be supported beyond the normal and spec maps we have now. If we know that sooner we can start planning out our content sooner.
0

#24

View PostMark., on 16 December 2015 - 07:15 PM, said:

I think what TM might be asking is what texture maps will be supported beyond the normal and spec maps we have now. If we know that sooner we can start planning out our content sooner.


Over the course of development, I plan on supporting Albedo, Normal, Spec, Spec2, SSS Maps, Displacement, Mask, Glow, and Animated Textures. I can't promise when all of those will get in. Please keep textures at or under 2048x2048. You don't need bigger textures unless your zooming up against something, so please be smart when making assets. If there are any performance problems from high-res textures, I have been known to tell artists to quarter res there shit. :thumbsup:.

I do not want to see glow maps that are 4k x 4k :/.

This post has been edited by icecoldduke: 16 December 2015 - 07:31 PM

0

User is offline   Mark 

#25

So far I have rarely felt the need to exceed 1024 x 1024
0

User is offline   Steveeeie 

#26

View Posticecoldduke, on 16 December 2015 - 07:24 PM, said:

Over the course of development, I plan on supporting Albedo, Normal, Spec, Spec2, SSS Maps, Displacement, Mask, Glow, and Animated Textures. I can't promise when all of those will get in. Please keep textures at or under 2048x2048. You don't need bigger textures unless your zooming up against something, so please be smart when making assets. If there are any performance problems from high-res textures, I have been known to tell artists to quarter res there shit. :thumbsup:.


Will we be able to utilize fbx's ability to store polygon material IDs, so that we can specify multiple materials for a single mesh?

This would be useful if we want part of the texture to be animated so we can make a smaller material for that particular area and save some performance and file size by not having to load in the whole texture for every frame.
1

#27

View PostSteveeeie, on 16 December 2015 - 07:33 PM, said:

Will we be able to utilize fbx's ability to store polygon material IDs, so that we can specify multiple materials for a single mesh?

This would be useful if we want part of the texture to be animated so we can make a smaller material for that particular area and save some performance and file size by not having to load in the whole texture for every frame.


I'm not sure how this would save performance. The slowest part of loading in textures is the hard drive loads, and then uploading that data to the GPU across the main bus. For animated textures, the movie file will always been in main memory(unless I create a ring buffer, but I don't have plans to do that right now), it will then get decoded into a double buffered texture. I planned on supporting multiple materials per mesh.

I haven't decided whether or not I'm going to try and implement a texture streaming system down the line, but I don't plan on loading huge chunks of texture data from the HD every frame.

This post has been edited by icecoldduke: 16 December 2015 - 07:43 PM

1

User is offline   Tea Monster 

  • Polymancer

#28

If nothing else, it will allow us to sanely apply smoothing groups. NPherno's MD3 compiler breaks them on UV islands, which is crap.

4K textures.... LULWUT?

This post has been edited by Tea Monster: 17 December 2015 - 04:01 AM

1

User is offline   Spiker 

#29

View PostTea Monster, on 01 April 2012 - 02:12 PM, said:

OK, in that other thread, I did make a silly 'April Fools' joke.

They won't be ready by Monday.

They aren't finished by any means, and they don't have teeth yet, but what do you think?

Posted Image
Time to revive demons of the pastPosted Image
1

User is offline   Inspector Lagomorf 

  • Glory To Motherland!

#30

View PostTea Monster, on 17 December 2015 - 03:48 AM, said:

4K textures.... LULWUT?


We are dealing with forces beyond our comprehension...

Posted Image
0

Share this topic:


  • 9 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • This topic is locked


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options