Jump to content

  • Log In with Google      Sign In   
  • Create Account

Ed Welch

Member Since 08 Jun 2009
Offline Last Active Aug 24 2016 06:43 AM

Posts I've Made

In Topic: Best Way To Comment Code Without Cluttering

03 August 2016 - 06:35 PM

I do minimal commenting like youself. I found too much comments makes the code harder to read. I found also any workaround code for tricky bugs is *very* hard to understand later on after you've forgotten about the bug, so I make sure I document those bits very well.


In Topic: "render To Texture" With Mipmaps On Opengl Es 2.0

20 July 2016 - 05:50 AM

I figured out my mistake. I was calling  glGenerateMipmap after creation of the texture and then once again after I render to the texture, but I didn't release that I had to unbind the frame buffer first and then call glBindTexture:

// after rendering to texture
glBindFramebuffer(GL_FRAMEBUFFER, m_origFrameBuffer);
	glBindTexture(GL_TEXTURE_2D, m_textureID);
	glGenerateMipmap(GL_TEXTURE_2D);

Thanks for the help anyways


In Topic: "render To Texture" With Mipmaps On Opengl Es 2.0

20 July 2016 - 05:20 AM

At least in the code you posted you appear to only ever bind mipmap-level 0 to render on. If you want to glGenerateMipmap() to propagate the rendered state to the lower levels, you will have to call it after rendering. It's not really magic, it just takes the current content of the texture's base level and creates the mip map levels from that in the canonical way. Any changes after that in any level are not reflected in the other mipmap levels.

Do you mean call    

glFramebufferTexture(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT1, m_textureID, 0);

?

I tried that. It doesn't work

 


In Topic: Vulkan is Next-Gen OpenGL

19 July 2016 - 10:56 AM

 

Async compute is looking to be a killer feature for DX12 / Vulkan titles. The benchmarks indicate that Pascal's implementation of async compute isn't half as good as AMD's.

Ah, one should be careful with such a blanket statement (unless you have some more detailled information?). Benchmarks are rarely unbiased and never fair, and interpreting the results can be tricky. I'm not trying to defend nVidia here, and you might quite possibly even be right, but I think solely on the linked results, this is a bit of a hasty conclusion.

From what one can see in that video, one possible interpretation is "Yay, AMD is so awesome, nVidia sucks". However, another possible interpretation might be "AMD sucks less with Vulkan than with OpenGL". Or worded differently, AMD's OpenGL implementation is poor, with Vulkan they're up-to-par.

Consider the numbers. The R9 Fury is meant to attack the GTX980 (which by the way is Maxwell, not Pascal). With Vulkan, it has more or less the same FPS, give or take one frame. It's still way slower than the Pascal GPUs, but comparing against these wouldn't be fair since they're much bigger beasts, so let's skip that. With OpenGL, it is however some 30+ percent slower than the competing Maxwell card.

All tested GPUs gain from using Vulkan, but for the nVidia ones it's in the 6-8% range while for the AMDs it's in the 30-40% range. I think there are really two ways of interpreting that result.

 

Not really, because all games that have async compute AMD gains much more than pascal, including direct X titles. Check this out if you don't believe me:

http://wccftech.com/nvidia-geforce-gtx-1080-dx12-benchmarks/


In Topic: Vulkan is Next-Gen OpenGL

19 July 2016 - 08:24 AM

Async compute is looking to be a killer feature for DX12 / Vulkan titles. The benchmarks indicate that Pascal's implementation of async compute isn't half as good as AMD's.


PARTNERS