[Mesa-dev] v3d: Difference between TransformFeedback Gallium <-> Vulkan
For a few weeks now I am working on implementing Vulkan for VideoCore 6 AKA 42 (using V3D/DRM). Don't hold you breath ;) Currently I am trying to understand what is necessary or how to interact with V3D. So I am looking at TransformFeedback because it interacts with quite a few other parts of the pipeline and still seems less mangled into the big logic than other features. So I am comparing how Gallium (V3D) is handling TF in the state tracker VS how Vulkan (Intel) is handling the Extension. The following is what I so far think I gathered: 1. GV3D is handling TransformFeedback directly with other bound parts of the pipeline (e.g. `emit_state` in _v3dx_emit.c_). It seems to look into the shader and associated TF specs. It seems to use "streamout targets", although I do not yet understand what these are really. Then it passes all the offsets, indices and finally resources to V3D. 2. The Vulkan Extension only knows about CounterBuffers and iterates over these. Intel seems to call TF -> XF? and subsequently the buffers XFB. Have also not yet gathered what is the difference and what all the gazillion acronyms mean. So far my idea would be to implement TF similar to Intel and instead of iterating over "streamout targets" I would iterate XFBs. The problem with this approach is, that it will not be easy to mimic `cl_emit` calls similar to Gallium. My question now is which parts of V3D emits have a dependency. I would assume that I can move TRANSFORM_FEEDBACK_SPECS and TRANSFORM_FEEDBACK_ENABLE to cmd state flush in Vulkan. `vkCmdBeginTransformFeedbackEXT` shoudl then only need TRANSFORM_FEEDBACK_BUFFER and TRANSFORM_FEEDBACK_OUTPUT_ADDRESS. Sorry if this is a bit confusing - I am really just trying to figure this out one by one. Any information would be appreciated. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Declaration of _CmdBeginTransformFeedbackEXT
Sorry for being a bit thick but it seems like I cannot find where *_CmdBeginTransformFeedbackEXT functions are getting declared. I would assume, that it is somewhere in a XML to header stage, but could not yet figure out, which header. Probably using some macro magic, that makes the code non-searchable :( Could anyone please point me in the right direction? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Copying common u_format from gallium/auxiliary to broadcom/util
Currently broadcom/compiler does not link on its own. It references undefined symbols to: - `util_format_description` - `util_format_is_unorm` - `util_format_is_float` For gallium/v3d, these get provided by gallium/auxiliary. Seems to be an odd dependency to me. I would now like to copy at least these 3 symbols to broadcom/util with a `v3d_` prefix. This way broadcom/compiler has no implicit dependency on gallium anymore. Any opinions or better ideas? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Implement memory information for RPi4 Vulkan
On my impossible quest to try to implement a Vulkan driver for RPi4, I now need to implement memory information (mostly heap and types). As always I shadowed what anv is doing but have no access to RPi documentation. What is the best approach to get necessary information for question like: 1. Need 48+bit addresses supported (would assume no since the max. memory config is 4GB)? 2. What can be exposed as the heap start/end/size? 3. Which types of memory can one support (would assume VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | VK_MEMORY_PROPERTY_HOST_COHERENT_BIT and VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT | VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | VK_MEMORY_PROPERTY_HOST_CACHED_BIT)? I will have another look at v3d (drm) sources. Is there something to be found in v3d (gallium)? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] VulkanCTS only supporting robustBufferAccess == true?
Testing my Vulkan driver agains Vulkan CTS, I am a bit suprised, that is seems like CTS does enforce robustBufferAccess (e.g. https://github.com/KhronosGroup/VK-GL-CTS/blob/master/external/vulkancts/modules/vulkan/api/vktApiFeatureInfo.cpp#L1045). Am I mistaken or can someone explain what the logic behind all that is. Bonus points for pointing me to a hidden documentation about Vulkan CTS which I haven't found yet. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] V3D Vulkan DeviceWaitIdle
On the quest of implementing Vulkan (using V3D (DRM)), I am currently trying to implement things like `_DeviceWaitIdle`. For devices the current plan is to have an active `v3d_job` together with a collection of available `v3d_job`s similar to Gallium. IIUC the device would then be the owner of these `v3d_job`s. Is `_DeviceWaitIdle` then as easy as waiting for the `bo` of the active `v3d_job` (binner + render) or would I need to wait for all `bo`s in all `v3d_job`s? Or is my approach utterly wrong? Cheers Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Moving v3d_format to broadcom
Anyone objecting to moving struct v3d_format and native defines from Gallium to Broadcom? I think it would make sense to use it similarly in Vulkan. Cheers Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Documentation and abbreviation
As a newbie to Mesa, I wonder what the stance on documentation is. The official developer documentation seems scarse and partially outdated. Also it does not seem to take advantage of GitLab Wiki. So as a newbie I feel pretty left alone. Is this a shared view? Is there any roadmap or plan for this to go anywhere? One particular field of confusion are the hundreds of abbreviations that are used all over the place. I started collecting these in a file and slowly are able to uncover their meaning. I do wonder whether it would make sense to collect and document these in a centralized fashion. Cheers Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev