search

KhronosGroup / Vulkan-Docs

The Vulkan API Specification and related tools
Other
2.7k stars 452 forks source link

whether the first return value of opimagequerylod add baselevel when baselevel !=0? #2383

Closed Lucas5a4d closed 2 weeks ago

Lucas5a4d commented 3 weeks ago

when baselevel !=0, I saw the vulkan spec said:

OpImageQueryLod returns the Lod parameters that would be used in an image operation with the given image and coordinates. The steps described in this chapter are performed as if for OpImageSampleImplicitLod, up to [Scale Factor Operation, LOD Operation and Image Level(s) Selection](https://registry.khronos.org/vulkan/specs/1.3/html/chap16.html#textures-lod-and-scale-factor). The return value is the vector (λ', dl). These values may be subject to implementation-specific maxima and minima for very large, out-of-range values.

and image so it should add baselevel value according to the vulkan spec. but when i test on nvidia and amd gpu, the return value is relative to baselevel ,which means that it won't be added by baselevel. For example: If the calculated lod is 0.4 relative to baselevel and baselevel equals 2 and mipmapfilter is nearest, the op should return(2,0.4) according to the vulkan spec. But on gpu, i got a (0,0.4) as return value.

HansKristian-Work commented 2 weeks ago

I'm confused. Why is this a SPIRV-Cross question? Did you intend to post this to https://github.com/KhronosGroup/Vulkan-Docs/ instead? OpImageQueryLod is relative to base level I'm pretty sure. Sounds like a spec bug to me.

HansKristian-Work commented 2 weeks ago

I've created an internal spec issue for this. No need to create one on public repo as well.

Lucas5a4d commented 2 weeks ago

Ok，Thanks！

HansKristian-Work commented 2 weeks ago

Closing this as it has no relevance to SPIRV-Cross.

Lucas5a4d commented 2 weeks ago

@HansKristian-Work Have you come to a conclusion as to whether this is a bug? If you come to a conclusion, please tell me，thanks!

TomOlson commented 4 days ago

@Lucas5a4d Confirming, this is a bug. Thanks for flagging it! Hans-Kristian is working on a fix internally.