Closed vlj closed 5 years ago
The hitman 2 shadows thing on vulkan i also found to be odd. It doesn't seem to be due to border clamp color (it is set to white, 1.f). I was going to open a separate issue, but I guess this can serve as a tracker for this.
Another issue is that Afterburner climax does not work on GL for some reason. With vulkan, it just worked out of the box, and it was a direct opengl port back then, so I really dont know why it doesnt work.
I looked at After Burner Climax with GL. What happens is that rtt are created as gl_texture_2d but are sampled with unnormalized coords. Unfortunately in gl texture 2d and rectangle are different object from gl spec point of view, they can't even be mapped using texture view. It works in Vulkan because sampler 2d can be transformed into a sampler rest by setting the right bit in sampler object.
Fix for gl is the same as for dx12, we need to divide input by texture size.
I'll extend GL to use explicit samplers through ARB_sampler_objects and see if it helps. Should help make it similar to vulkan in that regard.
EDIT: Seems ARB_sampler_objects doesn't handle unnormalized coordinates. We'll just use the shader method as in dx12
Vulkan doesn't support non 0xFFFF primitive restart index, this makes SH3 crashes on nvidia (kernel exception). I think it tries to access vertex "-2" which is not contained in the vertex buffer.
That'd be 0xFFFE. I think we have to fill the index buffer ourselves and replace the primitive restart index with FFFF or FFFFFFFF depending on the type
Actually I was wrong SH3 does not crash because of primitive restart but because of cubemap (which are not supported atm : what happens is that the extra layer becomes mipmap level atm). Some geometry is missing though so maybe it's tied to primitive restart.
Another issue i've noticed on gl: missing/corrupt geometry. Notable on afterburner climax, hitman 2 (hair), resogun. prince of persia the sands of time
Geometry in GL is apparently here but misplaced, at least in Hitman 2. For some reason the hair is using wrong vertex attribute apparently.
Its interesting that there are attribute issues on openGL and not on vulkan. The initial vulkan commit was a near direct port of the OpenGL backend and there are no issues there.
I found the issue, vertex buffer size was wrong: https://github.com/vlj/rpcs3/commit/979eea638ab61d19918f176da647839cebcef83e
vertex_draw_count is the number of vertex draw, in case of non indexed draw it's exactly the count of element in the vertex buffer array however for indexed draw there is no relationship between count of element in vertex buffer and vertex_draw_count. Usually the buffer has less element (since indexed usually reuse a vertex several time) however in some case the vertex array must be bigger.
Nice catch. Vulkan initially had a similar bug but i somehow completely missed this when reviewing the opengl code recently trying to fix this bug.
I have almost finished factorizing vertex attribute upload code between dx12 and Vulkan, will soon send a pr.
Btw it looks like there is a bug with rgba32 format and vertex buffer with some Radeon card, I've signaled it to Vulkan project and it looks like a driver bug and not a hw limit. I'm keeping the workaround for now but I will remove it if it get fixed with a driver update.
@vlj btw, it's unrelated but while you have a contact with AMD driver dev could you ask if missing glsl 450
support is intentional (because otherwise amd drivers are oGL 4.5 compliant) or it's an oversight.
@danilaml If I remember correctly, newer drivers report glsl 450 for GCN on windows since the 16.x crimson series. I could recheck when I get home though if I'm wrong.
@vlj Its interesting that texelFetch should respect the swizzle mask under vulkan but not openGL. Under OpenGL glsl, the texelFetch instruction completely ignores the component masking state of the sampler for both amd and nvidia. I'm not sure if its a bug or just an undefined part of the spec since I havent found anything dictating expected behaviour.
@kd-11 wow. Indeed it does. I'm pretty sure that's got added recently though (I think I checked on first crimson drivers with no luck so it was either 16.2 or 16.3 or something in between).
Slightly unrelated, but it would be nice to instead create the VertexProgram and FragmentProgram files in a separate folder. It's quite annoying to have the bin folder filled up with 100's of them.
I agree.
@vlj btw, if you haven't lost your contact, you can probably ask him about this issue: https://community.amd.com/message/2710176#2710176
https://github.com/RPCS3/rpcs3/pull/1722 should fix hitman and other games with the black shadow covering everything
https://github.com/RPCS3/rpcs3/pull/1743 should fix the alpha testing in opengl and vulkan backends.
Having https://github.com/RPCS3/rpcs3/pull/1763 , all backends should have Logic Op implemented
Extra buffer copying in opengl has been removed as of https://github.com/RPCS3/rpcs3/pull/1772
@kd-11 , i think the extra buffer copy still remains for Vulcan ? or should be removed as well
I'm going to rewrite the vulkan upload code after I track down the nv resizing bug. It still does a double copy which is slow.
thanks @kd-11
Just added the DX12 heap size into TODO list above
Buffer copying fixed for vulkan with latest commit, so that's one more off the list
separate front/back diffuse and specular color for Vulkan and GL is done. DH implemented GL and I implemented dx12
Thanks @kd-11.Updated the list.
Besides , i think the oversizing of heap memory in DX12 probably becasue of https://github.com/RPCS3/rpcs3/issues/1912 and also sometime leads to "Working buffer not enough"
Regarding Disgaea 3 loading screen special effect , it works previously long time ago using GL with write color buffer option
Btw, might be interesting: https://github.com/KhronosGroup/Vulkan-Hpp
@danilaml I saw that earlier, but I'm on the fence about it. We kinda already have our vk:: namespace wrappers in place at a higher level than the hpp provides. Using it becomes using a wrapper within another wrapper although it shouldn't affect much else. I'm not against it if someone is looking to invest time into it though.
Closing as the relevant bits are implemented for a long time.
I gathered a list of TODO related to graphic code. This is likely not exhaustif and not ranked by priority or difficulty.
Implement texture cube/texture 3d for GL and Vulkan. GL doesn't support texture 3d atm (there is no glTex3dStorage call). Some code exists in Vulkan but a lots of function use a default VK_IMAGE_DIMENSION_2D by default. So far After Burner Climax has cubemap texture for the reflection effect and Resogun has 3d textures likely for smoke effect.