Re: having troubles with D and Vulkan.
ok found it, I am an idiot, (really not used to working with dynamic libraries). erupted needs a call to load device level functions. loadDeviceLevelFunctions(instance); On Thu, Jul 20, 2023 at 4:22 PM Danni Coy wrote: > > https://pastebin.com/Jc9ZaFFs > Redid the code as an almost exact translation of the C code. > should be easier to test and compare. Same issue is occurring. > > On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn > wrote: > > > > On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote: > > > https://pastebin.com/JxxJufNB > > > > What platform are you using, and how are you trying to build? > > > > I can try to replicate on my end.
Re: having troubles with D and Vulkan.
https://pastebin.com/Jc9ZaFFs Redid the code as an almost exact translation of the C code. should be easier to test and compare. Same issue is occurring. On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn wrote: > > On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote: > > https://pastebin.com/JxxJufNB > > What platform are you using, and how are you trying to build? > > I can try to replicate on my end.
Re: having troubles with D and Vulkan.
On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn wrote: > > On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote: > > https://pastebin.com/JxxJufNB > > What platform are you using, and how are you trying to build? > > I can try to replicate on my end. I am on Manjaro Linux with an AMD RX 6600 using the open source driver. I am building with visual studio code and dub. I get segfaults when building with dmd or ldc. The following C code https://pastebin.com/2XJbjzMw does not cause a segfault on the same system. Other code you will need to build https://pastebin.com/hx2GD1DL Build settings (from dub.json) { "dependencies": { "bindbc-opengl": "~>1.0", "bindbc-sdl": "~>1.0", "erupted": "~>2.1.98+v1.3.248" }, "versions": [ "SDL_206", "GL_32", "validateVulkan" ], "name": "subterrainian" }
Re: having troubles with D and Vulkan.
https://pastebin.com/JxxJufNB
Re: having troubles with D and Vulkan.
> > I was able to get through the triangle demo a while back. I feel > like it's more of a D question than a Vulkan library question. > You'll have to post your code so people can tell what it is. Just > a hunch, but it's probably something that the gc is collecting > before it is used. What's the best way to post code? I am mostly not using the GC, using std.experimental.allocator specifically mallocator to allocate other than using std.exception.enforce.
having troubles with D and Vulkan.
I am trying to run through the basic Vulkan triangle demo. I am getting stuck at vkGetDeviceQueue which segfaults for me. I have written the same tutorial to about the same point in C and I am not getting the segfault. I have enabled validation layers and they are not picking up anything. Any suggestions? module vulkan; import std.exception : enforce; import erupted; import bindbc.sdl : SDL_Window, SDL_Vulkan_GetInstanceExtensions, SDL_Vulkan_CreateSurface; import memory; import util: CStringList; version (validateVulkan) { string [] validationLayers = ["VK_LAYER_KHRONOS_validation"]; const(char)[] debugExtension = "VK_EXT_debug_utils"; } else { string [] validationLayers = []; } CStringList getInstanceExtensions (SDL_Window * window) { uint n; SDL_Vulkan_GetInstanceExtensions(window,&n,null); version (validateVulkan) { auto extensions = CStringList(n+1); SDL_Vulkan_GetInstanceExtensions(window,&n,extensions.ptr); extensions[n] = cast(const(char)*) debugExtension.ptr; } else { auto extensions = CStringList(n); SDL_Vulkan_GetInstanceExtensions(window,&n,extensions.ptr); } return extensions; } void createInstance (CStringList extensions) { auto vlayers = CStringList(validationLayers); VkApplicationInfo appInfo = { pApplicationName: "Vulkan Test", apiVersion: VK_MAKE_API_VERSION(0,1,3,0), }; VkInstanceCreateInfo createInfo = { pApplicationInfo: &appInfo, enabledLayerCount: cast(uint) vlayers.length, ppEnabledLayerNames: vlayers.ptr, enabledExtensionCount: cast(uint) extensions.length, ppEnabledExtensionNames: extensions.ptr, }; auto r = vkCreateInstance(&createInfo, null, &instance); enforce(r == VK_SUCCESS,"failed to create instance"); loadInstanceLevelFunctions(instance); } void getPhysicalDevices () { uint n; vkEnumeratePhysicalDevices(instance, &n, null); physicalDevices = allocator.makeArray!VkPhysicalDevice(n); vkEnumeratePhysicalDevices(instance,&n,physicalDevices.ptr); enforce(physicalDevices.length > 0,"no physical devices found"); } void pickPhysicalDevice () { if (physicalDevices.length == 1) { primaryPhysicalDevice = physicalDevices[0]; } else { ulong maxScore,index=-1; foreach(i,device; physicalDevices) { uint score = 0; VkPhysicalDeviceProperties properties; device.vkGetPhysicalDeviceProperties(&properties); VkPhysicalDeviceFeatures features; device.vkGetPhysicalDeviceFeatures(&features); switch(properties.deviceType) { case VK_PHYSICAL_DEVICE_TYPE_DISCRETE_GPU: score = 1000; break; case VK_PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU: score = 500; break; case VK_PHYSICAL_DEVICE_TYPE_CPU: score = 100; break; default: score = 0; } if (score > maxScore) { maxScore = score; index = i; } } primaryPhysicalDevice = physicalDevices[index]; } enforce(primaryPhysicalDevice,"failed to find acceptable physical device"); } int [2] findQueueFamilies (VkPhysicalDevice dev) { int [2] r = [-1,-1]; uint n; vkGetPhysicalDeviceQueueFamilyProperties(dev,&n,null); auto families = memory.allocator.makeArray!VkQueueFamilyProperties(n); vkGetPhysicalDeviceQueueFamilyProperties(dev,&n,families.ptr); foreach (i,family; families) { if (family.queueCount > 0 && family.queueFlags & VK_QUEUE_GRAPHICS_BIT) r[0] = cast(uint) i; VkBool32 presentSupport = false; vkGetPhysicalDeviceSurfaceSupportKHR(dev,cast(uint)i, surface, &presentSupport); if (family.queueCount > 0 && presentSupport) r[1] = cast(uint) i; } enforce (r[0] >= 0,"failed to find grahpics family"); enforce (r[1] >= 0,"failed to find present family"); return r; } void createLogicalDevice (int[2] q) { const(float[]) priority = [1.0f]; VkDeviceQueueCreateInfo queueCreateInfo = { sType: VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO, queueFamilyIndex: cast(uint) q[0], queueCount: 1, pQueuePriorities: priority.ptr, }; VkPhysicalDeviceFeatures deviceFeatures; VkDeviceCreateInfo createInfo = { sType: VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO, pQueueCreateInfos: &queueCreateInfo, queueCreateInfoCount: 1, pEnabledFeatures: &deviceFeatures, }; auto r = vkCreateDevice(primaryPhysicalDevice,&createInfo,null,&device); enforce(r == VK_SUCCESS,"failed to create logical device"); } void getGraphicsQueue (uint i) { vkGetDeviceQueue(device, 0, 0, &graphicsQueue); enforce(graphicsQueue,"failed to get graphics queue"); } void init (SDL_Window * window) { createInstance(getInstanceExtensions
alias this and initialisation
can anybody tell me why struct S { int x; alias x this; } void test() { S s; s = 8; // this works S s = 8 // but this does not? }
Re: Game and GC
gc causes unpredictabilities in performance*. With games it tends to be worst case performance that matters. I would reccomend using std.experimental.allocator (even if you still use the default GC backed allocator). This will allow you to swap out your allocator for a more specialised one as your requirements become more concrete. auto foo = new CustomStruct(); becomes auto foo = allocator.make!CustomStruct(); The next thing you probably want is @nogc - Last time I checked getting IAllocator objects are a bit tricky to use in @nogc code. Currently I am using https://github.com/radcapricorn/alloctraits to get around this limitation (You will still need an allocator that doesn't use the GC, I use Mallocator for test purposes). * The GC itself is deterministic, but it is really easy to write code that triggers GC pauses at times that is difficult track down. On Sat, Apr 7, 2018 at 7:55 AM, Chris Katko via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > I'm in the same boat. I do games. But I love D's syntax and template > power. So I'm doing a full experiment. > > Honestly, if D is that big a liability, you'll encounter it long before > it's "too late" to port it to C++. > > Last night I had stuttering issues, but I realized there was a single, > C-function, being called too many times (and never deallocating!). > > But previously, I've also had stutter issues. Now granted, I test on a > "crap" laptop 2 GB RAM / Celeron processor. But it'll be 60 FPS ... then > spike down. If this happens again with my current project, what I'm going > to do, is hack the open source garbage collector to fire off an > event/console message EVERY TIME it actually pauses to collect. Because > it's possible the GC isn't actually the problem, or, some simple change to > a line of code may prevent the GC from being a problem. > > That said, there's also @nogc (but that's also a bit of a lie because they > never tell you that ANY THREAD running GC code can pause ALL THREADS for a > collection.) > > But if you're making games, you should really be using static pools > anyway. What's the MAXIMUM number of objects/trees/maps your game will have > at a time? It's simple (regardless of D, C, Python, or Lua). Static. Pools. > Basically, you just allocate at startup a simple fixed-length array for all > your objects. That way, you're never asking the OS for memory = Never > needing the garbage collector. If you don't use all that memory? Who cares. > RAM is cheap. And if your program CAN swell in size, that means your > low-end PCs will fail without knowing why. > > So you just put all your objects in fixed length arrays of size > MAX_OBJECTS, MAX_ENEMIES, MAX_ITEMS, etc. And deleting an object is as > simple as erasing it, or marking it as "bool is_deleted = true;" and adding > a new object is simply finding the first "is_deleted" and re-running the > constructor / re-using the carcass of the dead object. > > 99% of AAA studios use static pools. Now technically, static pools are > "chunks" of fixed length arrays. So you could have one pool for a "map", > and start loading another pool for the next map you're going to enter, and > then when you finally transfer to the next map, you then free the static > pool by marking it as deleted. And repeat as necessary. So it's a very > macro-level amount of allocations. We're talking like, less than a dozen > actual entities. (Depends on gametype, of course. But the > order-of-magnitude helps convey it.) >
Static array * scalar is not working for me
The following code is not working for me float[3] f; f[] = abs(f)[] * -1.0f; where abs is a function that returns a float[3]; it complains that f should be attached to some memory. Is it a bug or am I missing something?
Re: DDox and filters.
yup figured it out - module documentation needs to go *above* the module declaration or you get nothing. On Fri, Jul 28, 2017 at 11:53 AM, Soulsbane via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > On Thursday, 27 July 2017 at 03:01:50 UTC, Danni Coy wrote: > >> I am trying to build my projects documentation via the ddox system via >> dub. It seems that my modules are being documented and then filtered out. >> >> Ironically for a documentation system there isn't a lot of documentation. >> What is the minimum I need in order for documentation to show up? >> how do I control the filter options. >> > > I think I had this problem and solved it by adding a comment block at the > top describing the module. >
DDox and filters.
I am trying to build my projects documentation via the ddox system via dub. It seems that my modules are being documented and then filtered out. Ironically for a documentation system there isn't a lot of documentation. What is the minimum I need in order for documentation to show up? how do I control the filter options.
std.experimental.allocator example wanted
Can somebody give me a quick example of how to combine the MMapAllocator with the AllocatorList and the BitmapBlock objects together?
std.experimental.allocator and @nogc?
Lets assume I want to be able to swap in and out allocators none of which will be the gc_allocator... What is best practice for using std.experimental.allocator in @nogc code?