New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why 1 item and not 2 items is returned by vkGetPhysicalDeviceSurfacePresentModesKHR? #34
Comments
I've seen this too, but I liked this behavior. in python we have len() - C does not and I've always had to iterate over the returned lists anyway, I've never needed only the count. As for what it is doing. |
I was thinking that if I see a Vulkan function returning multiple pointers like below,
then with vulkan, I could access them by
Does this format make sense? |
Yeah, that'd be the pythonic way of doing it, assuming of course, that we ignore that fact that python supports lists/arrays as objects. II feel like the proper answer here is more philosophical than technical. It would be more "pure" to return the amount, but I don't see a technical reason to do so as it's implicated in the array object. Then there is the aspect of expected outcome, which for some people would be the expected outcome of the spec, which is fair enough. For me I've learned that people don't always update their documentation and so I've come to accept what my IDE tells me as expected outcome, which in this case just tells me it is one ffi object (but does tell me it is not a tuple). Anyway, in the end, up to realitix to decide if anything needs changing here. |
Hello @sunbearc22, like @Berserker66 told you, it's on purpose. Indeed it's philosophical. The goal is to be a very thin wrapper BUT it's Python and we can't ignore that. So I had to make a choice to know how far we pythonize this module. The advantage of a small wrapper like that (same functions names, struct names, constant names as the original C version) is that you can easily google the code and find plenty of documentation. It's still a Python module so we have to take advantage of that, it would be useless to return the Thanks, I can close this issue now. |
Hm. By the same token though, should it not also work this way the other way around then?
enabledLayerCount and enabledExtensionCount should then be automatic - or optional? |
@Berserker66 Thanks for sharing your thought. I read the
I tried
But got an error saying the object is a generator. I then tried below to expose the item
but got a ' Your example uses a list comprehension to expose the names of the extensions. But Pardon me for asking these questions. My intention is not to advocate pure pythonic way of coding with vulkan. Instead, I want to know how to use it better. Hope you can advice me.
|
What you are getting returned from vkEnumerateDeviceExtensionProperties is - assuming it was called correctly - pProperties, which is an array of VkExtensionProperties. If you look that structure up, : You can find that it has the extensionName and specVersion fields. |
Slightly unrelated, but will likely help you. This exists: |
@Berserker66 Thanks for your explanations. Also for the conversion scripts. I will try it out later in the day. |
Good point @Berserker66 about the other way around. Indeed the api is not consistent. I will fix it. The default value will be the |
@Berserker66 I was trying your script but encountered error. Can you explain?
However, I got:
I also tried
But also got the same error:
However, simple print statement works:
I got:
How do I resolve the NameError i am getting? I believe it should be '_Setup.__convert_struct_field'. I am sure it is something silly I am missing out but can't seem to figure it? |
If you look at the pastebin again, you can see that __convert_struct_field is the first function it defines. That is what you need to call. I don't get where the "_Setup" bit comes from at all, it seems you're including the class name for some reason when this is a function, not a method. Edit: derp - I just noticed. You're not meant to call "__convert_struct_field" yourself, this is meant to be called by convert_to_python only. You use It is python convention - I think PEP 8 - that _ and __ are the closest thing to a private function in python, that is not meant to be called by a "user application" of a module. |
@Berserker66 Noted your 3 points. `convert_to_python(s) worked partially. I tried
Output is given below and is correct:
However, it did not work on surface Format:
Error message:
Do you know what is causing this error? The reason I did not try The other thing I do not understand about function |
Mh, that is an interesting anomaly. ffitype.length for the surface formats is None. despite it reporting it is a type of array. The structure, using PyCharm debugger: |
This is the patch that makes it work:
So yeah, it is an array with 1 item, but it says the length of the array is None instead of 1. Edit: Is this how cffi handles a |
@Berserker66 Thanks. Patch works. Noticed the changes here:
Can you tell me why it is possible for a function to call itself? Would this not result in an infinite loop? Why not write:
? |
This is basically programming 101 - but anyway. Functions can call themselves, this is called recursion: Yes, you can end up with an infinite loop. Here's some things why you don't:
Your code just returns back the original as it was, unchanged. You still end up with a structure, just the same (or parts of a struct). The intended result of that function is to "convert to python". Python, by default, does not use C structures, it would therefore then fail its intended functionality. |
@Berserker66 Hey, thanks for your explanations. It brightened up my day. ;) |
Well, that is a much more complex discussion. Maybe we should open a new issue for that. So far, this module has been a very faithful and direct vulkan implementation, no bells and whistles (apart from some pythonizing of exceptions and i/o). However, as you call it, there are no helper functions. We can look at other projects that do this, for example pyglet, which is a close comparison. Pyglet exposes the entire OpenGL interface, and you can use it like that. But really, you'll likely dig into its convenience functions, like a framerate counter, shader handling, batching etc. and you can intermix its stuff with your own. I've used pyglet in the past for two projects and it was nice. Admittedly I implemented shaders on my own before pyglet did - but anyway - such convenience functions can be nice, but if such a road is taken it should be split off well. A submodule or another project entirely that has this project as dependency. There is merit to a pure vulkan copy, especially when you get to people porting code from python to something else or from something else to python, porting is a lot easier if you just need to port the language and not also the api. In other words, I don't want convenience functions to "pollute" the pure vulkan interface. A collection of helper functions is something I don't think any user is going to say no to, it's always a nice to have, but it is also work to maintain and document it all. As it stands, this module can just point at the vulkan spec and say - just do this and doesn't need much documentation of its own. At the end of the day, I would support a helper module, but caution that; that would require someone to maintain it, make unittests and documentation for it. |
@realitix has provided an excellent vulkan wrapper to Vulkan. It is what it calms to be. Also, I know vulkan does serves as the basis for vulk and there I saw many helper functions relating to math and graphics, which gives enthusiast like myself better understanding on how to use vulkan to write a Vulkan app. As to my suggestion, I am limiting my consideration to functions that help expose the cffi data returned by vulkan; not so much about helper functions that could be useful in vulk. As you both know, I am not conversant in cffi and so thought that the functions shared by @Berserker66 can help non-literate cffi users like myself to better appreciate and use vulkan. After reading @Berserker66 opinions, I do appreciate that it does take effort to maintain helper functions. If @realitix does agree to go this route, I can help do a short write-up on the functions, which I think can be added to the section on function in the readme document. |
Hi @sunbearc22, indeed it's nice to have helper functions. My vulk project can help for that. Like @Berserker66 said, it's better to create a separate project dedicated to these helper functions. |
Noted @realitix. Thank @Berserker66 again for your helper functions. |
Hi realitix,
I noticed that for function vkGetPhysicalDeviceSurfacePresentModesKHR, it only returns the presentModes. I was expecting it to return both
presentModes
andpresentModeCount
as defined in Spec. Is is possible to return 2 items instead of one item so it follows Vulkan?I did noticed in line 4463, you defined
pPresentModes = ffi.new('VkPresentModeKHR[]', pPresentModeCount[0])
. Did you make pPresentModes a tuple or generator containing the presentMode and the presentModeCount? Pardon me I don't understand ffi.At the moment, I am using a loop to expose the presentMode and len to expose presentModeCount.
Output:
Appreciate your explanation.
The text was updated successfully, but these errors were encountered: