Vulkan API opinions from a programmer's perspective

>VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT_EXT

How do you feel about Vulkan Sup Forums?

Other urls found in this thread:

nvidia.com/object/freebsd-archive.html
github.com/bkaradzic/bgfx
twitter.com/SFWRedditGifs

I don't feel about it because it isn't supported on my platform.

I think that once OpenGL gets implemented on top of Vulkan and non-Vulkan GPUs start falling out of support, the porting story for alternative OSes gets a lot nicer.

Enjoying the feeling of having the apple dildo stuck up your ass?

What the fuck platform is that?

>7, 8.1, 10
Supported

>Linux
Supported

Any other platform is irrelevant for a graphics API

he is probably using bsd cuck os

Debian, the drivers for the 270X are bugged.

to be honest I'm just waiting for an OpenGL-like API made on top of Vulkan that would allow me to feed the GPU from multiple cores without any hassle.

the SDK*

>Any other platform is irrelevant for a graphics API
FreeBSD literally powers most game consoles.

JUST_FUCK_MY_SHIT_UP

...

>nonfree OS based of cuck code runs nonfree frameworks and user/kernelspace drivers
lmao you sure showed him.

While that's true it's more popular in movie effects rendering farms.

>"Irrelevant for graphics API"
>proves it's highly used in an industry where every product makes use of graphics API
>"lmao I'll make an even more retarded post"

You seem real desperate for attention, that's unfortunate.

Hard as fuck but will bridge the gap closer between mobile/handhelds and desktops

>timesharing and API layer blob made/sourced by some console manufacturer in an irrelevant kernel somehow makes freebsd relevant in this field when FreeBSD or normal users can't have it.

that fucking blob can be dropped in windows or linux as well. it doesn't magically make your cuckOS any less irrelevant in the grand scheme of the system. it just so happens that freebsd's shitty code is licensed in a way that circumvents the licensing fees of wangblows and the whole "muh GPL boogeyman" of linux.

The way you write makes it seem like you don't have any idea what you're talking about but are just looking to start an argument, probably for attention.

...

FreeBSD has vulkan through nvidias drivers I think

lmao
let me know when you stop porting DRM/DRI from linux to get usable graphics bsd kiddo.

nvidia.com/object/freebsd-archive.html

;)

Why would it make any difference where the drivers come from? How would that invalidate anything? Seriously, what is your intention here other than to start trouble.

literally just a port of their linux driver, it even has a fucking linux ABI compat layer because of how irrelevant your shitware os is.

Their linux driver is just a port of their windows driver. They all share the same foundation

I don't think you have any idea what you're talking about, the ABI compat is for the linuxulator so that you can use the GPU on BSD binaries and Linux ones as well.

Their Unix drivers all stem from their Solaris drivers but that's irrelevant because after a few generations they consolidated their drivers to be very similar across platforms.

Why are you trying to stir up shit, if you want to have an OS war, please make a seperate thread for it, this is a thread about Vulkan.

>VkBool32

Why use a 32-bit value to store 2 states?

...

It's probably faster computationally somehow. Same reason people pad out other datastrcutures to be at least a certain size. Cache aligned I guess. I could be wrong.

makes you think huh

You think you're smart?

Then explain to me why the pQueuePriorities member of the VkDeviceQueueCreateInfo struct is a pointer to a float instead of an actual float.
Apart from the performance issues that come from indirection, on 64-bit systems that member takes up more space because pointers are 64-bit while floats take 32-bits.

> GL_SUICIDE
> CL_KILL_SELF

opengl was difficult enough for me to use. i'll wait for the smart people to make a neat API

>cudaMallocPitch

It's almost like hardware is complicated and C has no namespacing.

>>Linux
>Supported
kek
It's supported only on the Intel HD (i.e. shit) and nVidiot proprietary drivers (i.e. unusable on some Optimus laptops).

>It's supported only on the Intel HD (i.e. shit) and nVidiot proprietary drivers
AMDGPU Pro supports Vulkan
Mesa does too with RadV

RadV is still new, but I believe its compliant enough now to run everything and pass the tests.
Its just not as fast as it could be yet, but that's changing rapidly.

radv works great, fucko.

Do you know if any progress has been made on that? I know the Mesa developers were talking about it along with a couple of Vulkan extensions they thought would make it easier.
I wonder if we'd still need thin hardware tuned GL drivers on top of Vulkan similar to how the Gallium drivers work, or if there could be one hardware-agnostic version.

I'm hoping for something to come out of the vk9 project, and for a vk11 and vk12 to show up.

Takes hours to go through a tutorial.

I am waiting.

I prefer metal.

>OpenGL gets implemented on top of Vulkan

is this happening? why do opengl on top of vulkan instead of just native opengl?

I know nothing about graphics programming, though I am a software developer during the days. Once I finish at the startup I'm working at I'd love to implement some old arcade games in vulkan just to learn it. Pong, breakout, space invaders etc.

It would be hardware vendor and to an extent OS agnostic. Test against libGLvulkan and it'll work the same on every OS, on ayymd and Novidya alike.

alright, that does seem desirable.

Why use opengl at all then though? Besides for porting projects already written in opengl, wouldn't it be better to start off writing for vulkan?

OpenGL is way easier to program against for simple projects that don't need Vulkan's autistic low level detail like game engines. It's just the drivers are terrible. Programming a libGL on top of Vulkan gets you the best of both worlds for that class of application.

alright, thanks.

Why would anyone need graphics apis now that we have engines like unity?

low quality bait

unity still uses a graphics api, you fucking ape

>writing a whole game engine just to draw a fucking triangle

currently vulkan is too complicated. And I'm really good with modern OpenGL (>= 3.3) and DirectX 11.

Plus what is the advantage of giving developers bare metal optimization IF the fucking graphics vendors can't even pull their shit together for more standardized hardware design? One uses HBM, requires different kind of optimization, another one has a weird pipelining, requires weird kind of paths to optimize. What you think a really good optimization might be completely shit in another card or architecture. So your code is potentially non future proof. It resembles the old days where C programmers targetted at specific CPUs had lots of inline assembly in the game code.

We don't even know what will be the future of Vulkan and its driver support. Vendors just dont give a fuck. API is complicated and there is not even an official C++ implementation for it, makes projects with tidied up codebase harder to implement.

it's another clusterfuck.

Why don't they just use an engine?

What do you think this engine would have to use to display graphics?

I hope that it get more popular than directx because i am tired of windows

github.com/bkaradzic/bgfx
Opengl like API but has backend to directx and others.

codemonkey developers never going to use this :ยด(
is there even one book that teaches proper vulkan?

a gpu

how do you code to the graphics api in unity? you rotate shit, pick shaders, animate etc. per drag and drop. you never see shader calls in there.