Modernization Kit Beta
by Alex Scarborough · in Torque Game Engine · 02/26/2007 (12:02 am) · 331 replies
Due to the absurd length of this thread, a new one has been started HERE. Please post in the new thread!
This thread is essentially a restatement of this except it's crossplatform now.
I am contractually obligated to do at least one (1) shiny thing a month, so here's my shiny thing for this month:
A working Win32 version of the ModernizationKit.
A huge thanks to OneST8 for getting the port started, and to GG for putting me in front of a PC and not minding that I quietly spent around 20 minutes a day getting this working.
Current version is: v0.8 build 0010 released 4-10-07
This is for TGE 1.5.0/1.5.1 ONLY!
Modernization Kit Website
Username: torqueUser
Password: tMK60152
This code is compatible with the latest version of Mac OS X and Windows 2000/XP
Thanks to the fabulous Jeff "Reno" Raab for letting me host this on the server he runs, and to Ben Sparks for setting up the website and forums!
I can't guarantee this code will work, or even compile, on anything other than my personal computer! Backup your copy of TGE if you use this! Actually, download a clean copy and play with that. I am not responsible for any damage done to your hardware or software as a result of using this!
Some notes: Cg is disabled by default, because it saved me the trouble of shoving Cg into TGE under Windows. Trust me, you're not going to miss the Cg layer anyways, GLSL is where it's at. If you do happen to want to enable Cg for whatever reason, uncomment #define SHADER_MANAGER_USE_CG in mkShaderManager.h.
Unit tests are disabled on Windows, to save the trouble of getting the CppUnit library up and running properly. Unit tests are enabled on OS X because you don't have to do anything for them to work; the bundled project file will link with the compiled dylib, copy it into the application bundle, and even change the install path so you really don't have to do a thing to use unit tests.
This code has not been tested on ATI GPUs under Win32. Presumably it will all work, but who knows. It has been confirmed to at least function on nVidia cards (there are a couple of known issues which will be addressed before 2008).
If you would like to subscribe to the Modernization Kit mailing list, submit a bug, or send some general feedback, please use the links on the Modernization Kit Web Center.
Best of luck, and I hope you get some good use, pretty screenshots, or fun out of this code!
This thread is essentially a restatement of this except it's crossplatform now.
I am contractually obligated to do at least one (1) shiny thing a month, so here's my shiny thing for this month:
A working Win32 version of the ModernizationKit.
A huge thanks to OneST8 for getting the port started, and to GG for putting me in front of a PC and not minding that I quietly spent around 20 minutes a day getting this working.
Current version is: v0.8 build 0010 released 4-10-07
This is for TGE 1.5.0/1.5.1 ONLY!
Modernization Kit Website
Username: torqueUser
Password: tMK60152
This code is compatible with the latest version of Mac OS X and Windows 2000/XP
Thanks to the fabulous Jeff "Reno" Raab for letting me host this on the server he runs, and to Ben Sparks for setting up the website and forums!
I can't guarantee this code will work, or even compile, on anything other than my personal computer! Backup your copy of TGE if you use this! Actually, download a clean copy and play with that. I am not responsible for any damage done to your hardware or software as a result of using this!
Some notes: Cg is disabled by default, because it saved me the trouble of shoving Cg into TGE under Windows. Trust me, you're not going to miss the Cg layer anyways, GLSL is where it's at. If you do happen to want to enable Cg for whatever reason, uncomment #define SHADER_MANAGER_USE_CG in mkShaderManager.h.
Unit tests are disabled on Windows, to save the trouble of getting the CppUnit library up and running properly. Unit tests are enabled on OS X because you don't have to do anything for them to work; the bundled project file will link with the compiled dylib, copy it into the application bundle, and even change the install path so you really don't have to do a thing to use unit tests.
This code has not been tested on ATI GPUs under Win32. Presumably it will all work, but who knows. It has been confirmed to at least function on nVidia cards (there are a couple of known issues which will be addressed before 2008).
If you would like to subscribe to the Modernization Kit mailing list, submit a bug, or send some general feedback, please use the links on the Modernization Kit Web Center.
Best of luck, and I hope you get some good use, pretty screenshots, or fun out of this code!
About the author
#82
03/14/2007 (10:08 am)
Yeah... they run normal TGE just fine, but I've never done any shader stuff on Linux so it's up in the air. I plan on installing Ubuntu but this machine has some jobs to do (my desktop machine at work), and needs to keep doing them... it will take time to get it all set up. How are the ATI proprietary drivers working with Ubuntu 6.10? My buddy installed 6.01 a while ago and there were lots of hoops to jump through to get the ATI drivers installed and working correctly. You'd think by now, the Linux distributions would all have a simple and foolproof way to download and install the proprietary drivers as part of the install process... ;-)
#83
@Paul: For dark and spooky, might I suggest DRL::setBiasLimits(-0.05, 0.0); DRL::setGoalIntensity(0.15); DRL::setBloomColorOffset(0.3); ?
@Marc: I have a worse card than he does and get 20-25 FPS with everything on max. The MK, for the most part, is CPU limited. Amount of VRAM and bus speed can also play a major role, but it takes a lot of shiny to make the GPU matter.
@All VC8 users: I'll talk to Jeff about that. I don't use VC8 myself (I can barely stand VC7 really), so a lot of these issues tend to go unaddressed. Hopefully we'll get things fixed properly in build 0009.
Build 0009 will be quite special, looking forward to getting it out...
03/14/2007 (12:16 pm)
@EddieRay: The chances of the Linux version running at all are... well, ridiculously slim. The Modernization Kit makes numerous changes to the platform layers to ensure that all of the necessary GL functions are properly loaded, and since these changes have not been made to the Linux platform layer... ya.@Paul: For dark and spooky, might I suggest DRL::setBiasLimits(-0.05, 0.0); DRL::setGoalIntensity(0.15); DRL::setBloomColorOffset(0.3); ?
@Marc: I have a worse card than he does and get 20-25 FPS with everything on max. The MK, for the most part, is CPU limited. Amount of VRAM and bus speed can also play a major role, but it takes a lot of shiny to make the GPU matter.
@All VC8 users: I'll talk to Jeff about that. I don't use VC8 myself (I can barely stand VC7 really), so a lot of these issues tend to go unaddressed. Hopefully we'll get things fixed properly in build 0009.
Build 0009 will be quite special, looking forward to getting it out...
#84
Of course, I had to modify the platformX86UNIX code to add the extra GL stuff needed (like was done in platformWin32), and there are no complaints about missing extensions, etc. Also, if the new MK code was trying to query all the features, and I didn't add them to the platform code, then I'd get either a compile-time error, or an assert at runtime, right?
Anyway, what I'm reporting is that it does actually *run* on Linux, and it does appear to be using the shaders/materials (with the massive frame-rate hit - so I know it's actually doing its thing, according to others who have seen similar performance).
Why would you think the chances are "ridiculously slim"...? Do you mean, "...without modifying the platform code"...? This is just straight OpenGL stuff, and (even my old) Linux drivers have all the necessary GL extensions (for my ATI card at least)... so I'm a bit confused by your statement. Why shouldn't the MK work on Linux?
03/14/2007 (12:31 pm)
Quote:@EddieRay: The chances of the Linux version running at all are... well, ridiculously slim. The Modernization Kit makes numerous changes to the platform layers to ensure that all of the necessary GL functions are properly loaded, and since these changes have not been made to the Linux platform layer... ya.
Of course, I had to modify the platformX86UNIX code to add the extra GL stuff needed (like was done in platformWin32), and there are no complaints about missing extensions, etc. Also, if the new MK code was trying to query all the features, and I didn't add them to the platform code, then I'd get either a compile-time error, or an assert at runtime, right?
Anyway, what I'm reporting is that it does actually *run* on Linux, and it does appear to be using the shaders/materials (with the massive frame-rate hit - so I know it's actually doing its thing, according to others who have seen similar performance).
Why would you think the chances are "ridiculously slim"...? Do you mean, "...without modifying the platform code"...? This is just straight OpenGL stuff, and (even my old) Linux drivers have all the necessary GL extensions (for my ATI card at least)... so I'm a bit confused by your statement. Why shouldn't the MK work on Linux?
#85
As much as I hate to say it, that's the easy part.
It'd be more of a crash and burn at runtime if you were lucky. If Torque failed to find the extension for whatever reason it'd be a whole lot of console spam. Asserting would be ideal, but it just doesn't happen.
There is no such thing as straight OpenGL stuff regrettably. The changes to the platform layer for the Win32 port took an hour. Working around driver idiosyncrasies took a month (and there are still nasty vendor specific bugs). Any Linux port is likely to find itself in a similar situation, if not a worse one. So, the chances of it working correctly out of the box, even with all of the necessary platform changes, are ridiculously slim. I would be incredibly impressed if it all worked as expected with expected performance with no changes made to the MK code.
3-5 FPS is not expected performance. I get 20-25 FPS and my computer is worse than yours in almost every way. Radeon 9600 with 64 MB of VRAM, 1.42 GHz G4, 1.5 GB of RAM. You should be getting a higher framerate than I am, not 1/6 of my framerate. Something in there is going horribly wrong.
03/14/2007 (1:16 pm)
Quote:Of course, I had to modify the platformX86UNIX code to add the extra GL stuff needed (like was done in platformWin32)
As much as I hate to say it, that's the easy part.
Quote:Also, if the new MK code was trying to query all the features, and I didn't add them to the platform code, then I'd get either a compile-time error, or an assert at runtime, right?
It'd be more of a crash and burn at runtime if you were lucky. If Torque failed to find the extension for whatever reason it'd be a whole lot of console spam. Asserting would be ideal, but it just doesn't happen.
Quote:This is just straight OpenGL stuff, and (even my old) Linux drivers have all the necessary GL extensions (for my ATI card at least)... so I'm a bit confused by your statement. Why shouldn't the MK work on Linux?
There is no such thing as straight OpenGL stuff regrettably. The changes to the platform layer for the Win32 port took an hour. Working around driver idiosyncrasies took a month (and there are still nasty vendor specific bugs). Any Linux port is likely to find itself in a similar situation, if not a worse one. So, the chances of it working correctly out of the box, even with all of the necessary platform changes, are ridiculously slim. I would be incredibly impressed if it all worked as expected with expected performance with no changes made to the MK code.
3-5 FPS is not expected performance. I get 20-25 FPS and my computer is worse than yours in almost every way. Radeon 9600 with 64 MB of VRAM, 1.42 GHz G4, 1.5 GB of RAM. You should be getting a higher framerate than I am, not 1/6 of my framerate. Something in there is going horribly wrong.
#86
Is there a bug list somewhere?
Well, as you might expect, it does vary a good deal. However, when I'm standing at the starting point look out over a good portion of the town in starter.fps, it's really bad... like 2 FPS.
Is "vertical sync" used at all in MK? I noticed that the X86UNIX platform code has that silently disabled. Also, I should probably note that I use two screens (separate X displays, not one big one with Xinerama). That might have an impact on performance... or not.
Do you get 20-25 FPS at the beginning of starter.fps without moving at all?
The console looks pretty "clean"... you can view it here: console.log
03/14/2007 (1:58 pm)
Quote:and there are still nasty vendor specific bugs
Is there a bug list somewhere?
Quote:3-5 FPS is not expected performance. I get 20-25 FPS and my computer is worse than yours in almost every way.
Well, as you might expect, it does vary a good deal. However, when I'm standing at the starting point look out over a good portion of the town in starter.fps, it's really bad... like 2 FPS.
Is "vertical sync" used at all in MK? I noticed that the X86UNIX platform code has that silently disabled. Also, I should probably note that I use two screens (separate X displays, not one big one with Xinerama). That might have an impact on performance... or not.
Do you get 20-25 FPS at the beginning of starter.fps without moving at all?
Quote:It'd be more of a crash and burn at runtime if you were lucky. If Torque failed to find the extension for whatever reason it'd be a whole lot of console spam.
The console looks pretty "clean"... you can view it here: console.log
#87
I suspect updating your drivers will at least get some basic things going. Assuming that the latest ATI Linux drivers are any good.
Starter.fps does poorly for me, but that's a CPU problem. Removing the precipitation gets me up to 20-25 FPS.
The MK does not inherently require that vsync be enabled or disabled.
I have had a chance to test the MK on a system with two monitors and there were no averse affects (beyond some nastiness with the parallax mapping shader, but that's an ATI issue, not a multi-monitor issue).
There isn't much of a bug list because I can never get confirmation on whether a bug is present or if updating drivers had any effect. The only bugs on the list are ones I've been able to personally reproduce and/or fix. As such, the only known bug is that the parallax mapping shader fails to work on an ATI X1300 GPU. I am about 90% certain that there are also issues on ATI Mobility GPUs with outdated drivers which caused the water to break, but I never got confirmation that updating the drivers fully resolved the issue. I should start accepting donations of computers so I can at least get everything tested on a wide variety of hardware/drivers.
03/14/2007 (2:13 pm)
@EddieRay: The console.log says "Update your drivers". The GL version string is returning 1.3 (!!!), and it doesn't support EXT_framebuffer_object, and, well, everything the MK does relies on EXT_framebuffer_object really. It's used for the reflections, it's used for DRL, it's used to generate the normal maps for interiors, etc.I suspect updating your drivers will at least get some basic things going. Assuming that the latest ATI Linux drivers are any good.
Starter.fps does poorly for me, but that's a CPU problem. Removing the precipitation gets me up to 20-25 FPS.
The MK does not inherently require that vsync be enabled or disabled.
I have had a chance to test the MK on a system with two monitors and there were no averse affects (beyond some nastiness with the parallax mapping shader, but that's an ATI issue, not a multi-monitor issue).
There isn't much of a bug list because I can never get confirmation on whether a bug is present or if updating drivers had any effect. The only bugs on the list are ones I've been able to personally reproduce and/or fix. As such, the only known bug is that the parallax mapping shader fails to work on an ATI X1300 GPU. I am about 90% certain that there are also issues on ATI Mobility GPUs with outdated drivers which caused the water to break, but I never got confirmation that updating the drivers fully resolved the issue. I should start accepting donations of computers so I can at least get everything tested on a wide variety of hardware/drivers.
#88
So that's the only "nasty" bug? Was/is this a "driver idiosyncracy" in that you had to change shader code because it wouldn't run correctly on a given video card with a given driver version the way it was written initially, and works fine on other cards/drivers?
My Mobility Radeon X600 in my Dell D810 probably falls into that category... but I've yet to get the MK working on Windows due to the above compiler issues, so I don't even have anything running on Windows yet. I'm still trying...
It doesn't seem to have any trouble without MK on the same machine. Where is the CPU time being spent/squandered? Removing the percipitation alleviates a huge amount of overdrawn of alpha-blended textures (since the precipitation covers a significant number of pixels that have already been drawn with 3D objects)... so that would seem to me to be GPU slowdown.
I'm guessing it's the DIF+shaders rendering. If I turn to look away from the DIF towers, the framerate spikes up to 20+. However, if I look out over the water (without any DIFs in view) the framerate also drops, but not nearly as bad as when the DIFs are onscreen.
Even if I delete the precipitation altogether (which doesn't improve the framerate significantly), I still see the framerate drop from >50 down to 6-8 FPS just by turning the camera so that any part of a just single tower comes onscreen.
03/14/2007 (2:32 pm)
Quote:The only bugs on the list are ones I've been able to personally reproduce and/or fix. As such, the only known bug is that the parallax mapping shader fails to work on an ATI X1300 GPU.
So that's the only "nasty" bug? Was/is this a "driver idiosyncracy" in that you had to change shader code because it wouldn't run correctly on a given video card with a given driver version the way it was written initially, and works fine on other cards/drivers?
Quote:I am about 90% certain that there are also issues on ATI Mobility GPUs with outdated drivers which caused the water to break
My Mobility Radeon X600 in my Dell D810 probably falls into that category... but I've yet to get the MK working on Windows due to the above compiler issues, so I don't even have anything running on Windows yet. I'm still trying...
Quote:Starter.fps does poorly for me, but that's a CPU problem. Removing the precipitation gets me up to 20-25 FPS.
It doesn't seem to have any trouble without MK on the same machine. Where is the CPU time being spent/squandered? Removing the percipitation alleviates a huge amount of overdrawn of alpha-blended textures (since the precipitation covers a significant number of pixels that have already been drawn with 3D objects)... so that would seem to me to be GPU slowdown.
I'm guessing it's the DIF+shaders rendering. If I turn to look away from the DIF towers, the framerate spikes up to 20+. However, if I look out over the water (without any DIFs in view) the framerate also drops, but not nearly as bad as when the DIFs are onscreen.
Even if I delete the precipitation altogether (which doesn't improve the framerate significantly), I still see the framerate drop from >50 down to 6-8 FPS just by turning the camera so that any part of a just single tower comes onscreen.
#89
The really odd thing is that when I brought up the escape dialog and started moving it around, I started seeing the reflection change - that red stripe in the lower right is the top of the dialog box (color gets blended and altered). Also, I can see the mouse cursor move around in the reflection as I move it around onscreen. Seems like the render-to-texture might be going wrong...
03/14/2007 (2:42 pm)
Here's a shot of the water reflections:The really odd thing is that when I brought up the escape dialog and started moving it around, I started seeing the reflection change - that red stripe in the lower right is the top of the dialog box (color gets blended and altered). Also, I can see the mouse cursor move around in the reflection as I move it around onscreen. Seems like the render-to-texture might be going wrong...
#90
That's the only known bug. Changes to the shaders had to be made for nVidia cards, but not for ATI cards. The water shaders especially are written around working well on the FX series, and look ugly as sin accordingly.
Collisions. One raycast per drop. 5,000 drops. It adds up very very quickly. In my profiling I have seen precipitation collision take up to 75% of total CPU time.
Sounds like your drivers aren't dealing with VBOs very well. This is the kind of annoying driver issue that makes the MK so much fun to port. Or the normal maps are causing obscene amounts of texture thrashing and you're on a PCI bus.
As for the water reflection, you need to set a normal map for the waterblock (if you haven't). One is provided in common/data/water/. Of course, if your drivers don't support EXT_framebuffer_object reflection isn't going to work anyways.
03/14/2007 (3:39 pm)
Quote:So that's the only "nasty" bug? Was/is this a "driver idiosyncracy" in that you had to change shader code because it wouldn't run correctly on a given video card with a given driver version the way it was written initially, and works fine on other cards/drivers?
That's the only known bug. Changes to the shaders had to be made for nVidia cards, but not for ATI cards. The water shaders especially are written around working well on the FX series, and look ugly as sin accordingly.
Quote:Where is the CPU time being spent/squandered?
Collisions. One raycast per drop. 5,000 drops. It adds up very very quickly. In my profiling I have seen precipitation collision take up to 75% of total CPU time.
Quote:Even if I delete the precipitation altogether (which doesn't improve the framerate significantly), I still see the framerate drop from >50 down to 6-8 FPS just by turning the camera so that any part of a just single tower comes onscreen.
Sounds like your drivers aren't dealing with VBOs very well. This is the kind of annoying driver issue that makes the MK so much fun to port. Or the normal maps are causing obscene amounts of texture thrashing and you're on a PCI bus.
As for the water reflection, you need to set a normal map for the waterblock (if you haven't). One is provided in common/data/water/. Of course, if your drivers don't support EXT_framebuffer_object reflection isn't going to work anyways.
#91
I'm sure that this holds for the most part.
Thats why I have 80 FPS without DLR which is similar to TGE in the same situation (just nicer).
But the moment I enable DLR and the clouds start glowing like dumb, the FPS go down to ~25 FPS.
Thats similar to what happens when I enable DLR in TGEA.
I'm on a Core Duo 2x2Ghz, 256MB VRAM (128bit bus), 2GB RAM
(will get a new one, but I have to wait for intel to launch the Core 2 Quad Q6400 first)
03/14/2007 (4:16 pm)
Quote:@Marc: I have a worse card than he does and get 20-25 FPS with everything on max. The MK, for the most part, is CPU limited. Amount of VRAM and bus speed can also play a major role, but it takes a lot of shiny to make the GPU matter.
I'm sure that this holds for the most part.
Thats why I have 80 FPS without DLR which is similar to TGE in the same situation (just nicer).
But the moment I enable DLR and the clouds start glowing like dumb, the FPS go down to ~25 FPS.
Thats similar to what happens when I enable DLR in TGEA.
I'm on a Core Duo 2x2Ghz, 256MB VRAM (128bit bus), 2GB RAM
(will get a new one, but I have to wait for intel to launch the Core 2 Quad Q6400 first)
#92
03/14/2007 (4:22 pm)
It's interesting that DRL has that much of an impact on FPS. I certainly haven't seen that kind of impact in my own tests. I'll have to look into it. 
#93
I had an odd "inside-out" bug in the editor (F11) that looked like the faces were flipped.
I fixed it by applying the same changes MK does to engine\game\gameTSCtrl.cc and engine\game\gameTSCtrl.h to engine\editor\editTSCtrl.cc and engine\editor\editTSCtrl.h.
I also had to do it for the AFX TSCtrl.
Pretty much everything is working perfect for the dozen or so people that have tested it.
Except the DRL angle lighting bug and I still can't figure out how to apply it to TSShapes, etc. this thing is great!
Keep it up.
03/14/2007 (8:22 pm)
DRL still gets bright when I look down and darker when I look up (or so it seems).I had an odd "inside-out" bug in the editor (F11) that looked like the faces were flipped.
I fixed it by applying the same changes MK does to engine\game\gameTSCtrl.cc and engine\game\gameTSCtrl.h to engine\editor\editTSCtrl.cc and engine\editor\editTSCtrl.h.
I also had to do it for the AFX TSCtrl.
Pretty much everything is working perfect for the dozen or so people that have tested it.
Except the DRL angle lighting bug and I still can't figure out how to apply it to TSShapes, etc. this thing is great!
Keep it up.
#94
Also, DRL angle lighting bug? Could you submit a bug report with a screenshot on that? Maybe I can reproduce it/fix it.
03/14/2007 (9:07 pm)
@BrokeAss Games: You wouldn't mind sending me the editTSCtrl.cc and editTSCtrl.h files, would you? This is one of those things I've been putting off, and if I can skip it completely, well huzzah.Also, DRL angle lighting bug? Could you submit a bug report with a screenshot on that? Maybe I can reproduce it/fix it.
#95
I'm pretty sure that's all of it.
I'm swamped and I bet you are too but I gotta pass the buck, I can upload the ArcaneFX TSCtrl but you'll have to ask Jeff Faust if it's cool.
I'll try and fill out a bug report on my DRL bug, it's prolly self inflicted.
03/14/2007 (9:19 pm)
Fix for models and terrain turning inside out in the editor.I'm pretty sure that's all of it.
I'm swamped and I bet you are too but I gotta pass the buck, I can upload the ArcaneFX TSCtrl but you'll have to ask Jeff Faust if it's cool.
I'll try and fill out a bug report on my DRL bug, it's prolly self inflicted.
#96
03/14/2007 (9:40 pm)
I don't have AFX, so uploading those files probably wouldn't be a good idea. 
#97
Please keep at it. If you get MK working well on Linux you'll be my hero.
Alex:
You are already my hero.
03/14/2007 (9:41 pm)
EddieRay:Please keep at it. If you get MK working well on Linux you'll be my hero.
Alex:
You are already my hero.
#98
Even though I have TGEA (and TGE 1.4.2) and so can't really test drive MK, I just wanted to say how very impressed I am with what you've done! Nice job!
I'm curious (since I can't test it for myself), given what you've done with MK, what does TGEA do that TGE 1.5 + MK doesn't do? Just Atlas?
Again, a hearty well done!
Best regards,
Kilo
03/19/2007 (3:29 pm)
Hi Alex -Even though I have TGEA (and TGE 1.4.2) and so can't really test drive MK, I just wanted to say how very impressed I am with what you've done! Nice job!
I'm curious (since I can't test it for myself), given what you've done with MK, what does TGEA do that TGE 1.5 + MK doesn't do? Just Atlas?
Again, a hearty well done!
Best regards,
Kilo
#100
I updated the waterblock to include a normal map, and that makes things better, but the water is very dark and the sun reflection spot is light blue. I can see the detail of the waves moving tho'. It's hard to tell if the rest of the reflections are correct since everything is so dark. I tried changing the shader quality and it makes things different, but no setting looks like the shots from Alex above yet.
03/20/2007 (8:17 am)
I'm still trying... it's probably gonna be a few weeks before I can update my work machine, so feel free to give it your own shot too... ;-)I updated the waterblock to include a normal map, and that makes things better, but the water is very dark and the sun reflection spot is light blue. I can see the detail of the waves moving tho'. It's hard to tell if the rest of the reflections are correct since everything is so dark. I tried changing the shader quality and it makes things different, but no setting looks like the shots from Alex above yet.
Torque 3D Owner Marc 'Dreamora' Schaerer
Gayasoft
(and the 5 FPS are expected I fear ... I get 20-25 FPS on a 7600Go which has 8 PSU and 5 VSU with DLR enabled so you will get around 10 at best)