[Mesa-dev] v3d: Difference between TransformFeedback Gallium <-> Vulkan

2019-08-26 Thread abergmeier
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

2019-10-03 Thread abergmeier
 

 

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

2019-10-03 Thread abergmeier

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

2019-10-26 Thread abergmeier
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?

2019-11-08 Thread abergmeier
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

2019-11-12 Thread abergmeier
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

2019-12-09 Thread abergmeier
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

2019-12-26 Thread abergmeier
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