• Content count

  • Joined

  • Last visited

Community Reputation

174 Neutral

About IrYoKu1

  • Rank

Personal Information

  1. Getting GPU vendor ID

    I think in general it should be repeatable, but in laptops with multi-GPUs this is hacked, and seems to be bogus (after creating a device, the adapter order changes).   I think what is happening under the hood is that the driver is exposing the selected GPU as first adapter; but somehow, after device creation this hacked order is being reverted (probably to the real one, putting the NVIDIA GPU first).   If I enum the adapters, I'll always only get only one; it seems the driver again hides the second one (in this particular case). I was searching for doing special things depending on the vendor, as some optimizations that improve things in some vendor, make things worse in others.
  2. Getting GPU vendor ID

    It seems you are right; in fact I think the way this is implemented is bogus.   I tried to get the first adapter available: factory->EnumAdapters(0, &adapter) Hoping it would always yield the GPU actually used. Doing it right in the beginning of the app worked out, but after DXUT initialization it was failing. I tracked down the problem and found this: factory->EnumAdapters(0, &adapter); // Returns the adapter for the Intel card D3D10CreateDevice(...); // Seems to be the first one in the app, when DXUT creates dummy devices for testing compatibility factory->EnumAdapters(0, &adapter); // Returns the adapter for the NVIDIA card So, doing it as I wrote in my first post (getting the adapter from the device) is not reliable, and trying to do in this other way (directly from first adapter ordinal) is also bogus. Unless this is done before device creation, you cannot rely on what you get from EnumAdapters.
  3. Getting GPU vendor ID

    The problem is how I can tell which one is the one currently being used, when using EnumAdapters?   The code I posted came from this page:   I wonder if it's a bug.
  4. Hi,   I'm trying to use this code for getting the vendor ID:     IDXGIDevice *dxgiDevice;     V(device->QueryInterface(__uuidof(IDXGIDevice), (void **) &dxgiDevice));     IDXGIAdapter *dxgiAdapter;     V(dxgiDevice->GetAdapter(&dxgiAdapter));     DXGI_ADAPTER_DESC adapterDesc;     dxgiAdapter->GetDesc(&adapterDesc);     SAFE_RELEASE(dxgiAdapter);     SAFE_RELEASE(dxgiDevice);     return adapterDesc.VendorId;   And is working well in most cases, but it's failing on my multi-GPU laptop. It always return the vendor ID of the integrated Intel GPU, even if the NVIDIA one is being currently used.   Someone knows where can be the problem?   Thanks!
  5. So, it's certainly not a Windows 8 problem, but likely to be a Windows 8 + something else, as only Megamoscha could repo it. I was thinking it was an AMD issue, but seems no to be the case. The weird thing is that this not specific to my applications, but also happen to all DX SDK samples using DXUT.   I'm not sure it could be the shader compilation, the whole system became very unresponsive in my case (to the point I've just to sit and wait for it to finish), and CPU utilization is about 16% (a single thread). I think it's something going on in the GPU. For what I debugged past week, it seems to hang in a EnumDisplayDevices loop.   Many thanks for the help!
  6. Hi,   I'm having troubles with old DXUT-based demos in my new Windows 8 system (I believe that is the cause, still not sure).   It seems the first time they are run, they hang for about one minute or two. Subsequent runs are fine. But if I change the executable file name or move them around the filesystem, then they will hang again the first run (so it seems to be something related with the path; note that I've the antivirus turned off).   This didn't happened to me before, so it seems it's either a problem with Windows 8 and DXUT, or with my system (I've tried it on a system with the same GPU and drivers but with Windows 7, and no problems).   The same happens with any DX SDK sample that is using DXUT. In particular, one of my projects that are having this problem is this one: Code: Binary:   If someone can also test this in Windows 8, and see if it hangs as well I'd really appreciate it (just to know if it's a Windows 8 problem, or something specific to my machine).   Thanks! Jorge  
  7. Thanks for the reply!   My question was motivated by this document:   There is a lot of useful information in there regarding normal mapping, it's amazing how it can break in some many ways I could not even imagine.   I discovered that xnormal uses unnormalized normals for the tangent basis (normal, tangent and bitagent), and only uses the cross in the pixel shader when a certain option turned on. But I don't know how much of a difference doing the cross in one place or the other can be (regarding visuals).   MJP, you usually normalize normals of the tangent basis in the pixel shader (before transforming the normal from the normal map)? I used to, but now I'm wondering about it as well. It requires a some instructions to do so, and it seems it will only match normal maps generated by some software but not others (being xNormal an important example).
  8. Hey guys,   I'm wondering what is the best approach to create the tangent frame:   - Pass normal, tangent and bitangent, and normalize all three in pixel shader [9 instructions]   - Pass normal, tangent and handedness, and do handedness * cross(normal, tangent) [9 instructions]   From the performance side you save two float slots in the interpolators if you use the second approach.   From the quality side, I wonder. I suppose there is no correct approach, and it all depends on how the normal map was baked: if using a orthogonalization before or after interpolation (per vertex or per pixel). If that is true, I wonder what approach popular tools like Maya, xNormal or Zbrush uses.   I'd love to have some input on the topic!   Thanks Jorge
  9. Hey guys, I'm trying to setup a orthogonal projection matrix for a directional light, but it's giving me problems. I just implemented regular spotlight shadow mapping, then switched the projection matrix to an orthogonal one. But as soon as I did that, shadow mapping stopped working (getting really weird non-informative results, so it's probably not very useful to post images). Looking at the shadow map itself, it looks good, the scene is being rendered there properly. Any general hints about what I can be doing wrongly? Thanks!
  10. Hey guys, To put this in context: imagine I'm rendering to backbuffer 0. Then, without presenting, I want to copy current backbuffer 0 contents to backbuffer 1. Then, continue rendering in backbuffer 0. Is that possible? From what I have read here: [url=""]http://msdn.microsof...0(v=VS.85).aspx[/url] It seems to be not possible on MSAAed buffers, if someone can confirm, I would really appreciate that! =) Thanks! Jorge
  11. Hey guys! As promised, we finally released the source code, in tandem with the book release: [url=""][/url] Any comments, optimizations and suggestions are welcome :-) Hope you like it! Jorge
  12. Thanks both for the replies! Three deltas, three cross products, three abs, two sums and one comparison. Seems to be cheap enough =]
  13. Hey guys, I was just wandering, what is the best way of determining if a point (x,y) is inside of a triangle defined by their vertices (p1, p2, p3, where each one is a (x,y) tuple). It is just that for multisampling, each subsamble must be tested to discover whether it is inside or outside ([url=""]http://msdn.microsof...2(v=vs.85).aspx[/url], see Multisample Anti-Aliasing Rasterization Rules), and what I found seems to be too expensive for it to be efficient (the barycentric approach: [url=""]http://www.ugrad.cs....notes-sept9.pdf[/url]). Maybe for multisampling a special trick is done somehow? (by the way, gamedev looks splendid right now, with the redesign =) Thanks! Jorge
  14. CSAA 8xQ == 16xQ?

    Just found the problem: I was not using a depth buffer (as I was only rendering a quad, I just omitted its creation), and as stated in the CSAA whitepaper, the depth buffer plays an important role in CSAA antialiasing. Curiously enough, 8xQ and 16xQ are now different but still have the same number of steps in the gradients (I would have a hard time telling what is the best one really). Somehow (I don't know where I read it I am unable to find the doc again) I thought that CSAA works as follows: For example for 16xQ you have 8 color samples and 16 coverage samples, so basically you decoupled color and z/stencil storage (MSAA decouples execution, not storage). So for each of the 16 z/stencil samples, you have a 3bit index to a table of 8 colors. Thus, it exploits the fact that usually the 16 samples have a similar color (just two in my quad example), and only store 8. But by the results I'm getting, I'm starting to think that it not works this way (if this was the case you should see 16 steps gradients in 16xQ instead of the 8 steps I'm seeing). Quote: On a semi-related note, when are we going to get in on some of that sweet MLAA action? Your site says code is coming soon but we haven't seen anything since like October :( We finally decided to release it to game companies first under a NDA. GPU Pro 2 is going to be release in March, so we will publish the code online this month or maybe in February. We should have stated this in the webpage... Quote: Another issue here is that you need to make sure everything is gamma-correct...both when rendering, and when viewing the image. Certain apps don't properly handle sRGB color space when scaling, and that includes web browsers. I'm using SRGB render targets in DX10, so I suppose the resolve is done in linear space, and presented to screen gamma space. By the way, I've been wondering, what are the count-sample combinations for real MSAA 8x and 16x? I cannot find them anywhere... Thanks!
  15. Hey guys, I have been playing around with different CSAA modes (see here) and have found something strange. See this (zoom in to see the gradients on top of the quad): As you can see, both 16xQ and 8xQ yield the same image. Definitely, 16x should produce smoother gradients, and it is not the case. I am using the exact quality numbers found in the previous NVIDIA link: struct MsaaMode { wstring name; DXGI_SAMPLE_DESC desc; }; MsaaMode msaaModes[] = { ... {L"8x CSAA", {4, 8}}, {L"8xQ CSAA", {8, 8}}, {L"16x CSAA", {4, 16}}, {L"16xQ CSAA", {8, 16}} }; Any thoughts about this? Maybe the numbers are not correct? Happy new year btw!