Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

Khronos Vulkan 1.0

Name: Anonymous 2016-02-16 21:49

It's out. Discuss!

https://www.khronos.org/registry/vulkan/

Spec:
https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html
https://www.khronos.org/registry/vulkan/specs/1.0/pdf/vkspec.pdf

Name: Anonymous 2016-02-16 21:55

I see tons of undefined behaviour here https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/src/vulkan/vulkan.h and abuse of the unportable [u]intN_t types in the spec. Is there any way around it?

Name: Anonymous 2016-02-17 2:43

>>2
Use the Rust version. Did they ever get that union nonsense sorted?

Name: Anonymous 2016-02-17 3:22

>>2
[u]intN_t is required by POSIX and Windows requires 8-bit bytes, so it's portable enough.

I don't like how they use 32-bit bools though, and some of their structure packing is suboptimal on platforms with 64-bit pointers, there's some wasted space for byte padding.

But at the end of the day, you're still able to get double the throughput when compared to OpenGL, so it doesn't really matter.

>>3
Looks like there's still a couple of unions, Rustfags can die.

Name: Anonymous 2016-02-17 3:28

https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/src/vulkan/vk_platform.h

#ifdef VK_USE_PLATFORM_WIN32_KHR
#include <windows.h>
#endif

Uggh...

Name: Anonymous 2016-02-17 3:59

[u]intN_t is required by POSIX and Windows requires 8-bit bytes, so it's portable enough.
It's not portable if it requires a specific byte size, I hope you choke on your own pee.

>>5
lol
#if defined(__LP64__) || defined(_WIN64) || defined(__x86_64__) || defined(_M_X64) || defined(__ia64) || defined (_M_IA64) || defined(__aarch64__) || defined(__powerpc64__)
#define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef struct object##_T *object;
#else
#define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef uint64_t object;
#endif

Name: Anonymous 2016-02-17 7:09

https://renderdoc.org/vulkan-in-30-minutes.html
EVEN MORE BOILERPLATE
and i thought OGL3 was bad
... NULL, NULL, NULL, NULL, NULL, NULL);

Name: Anonymous 2016-02-17 7:16

>>6
It's not portable at all if it doesn't require a specific size, unless... nevermind, you can choke on your own fuckups.

>>7
This isn't OpenGL. You're an ih b t.

Name: Anonymous 2016-02-17 8:11

>>8
pls stop doing banter you are worst banter i have ever seen

Name: Anonymous 2016-02-17 8:52

>>8
You are retarded

Name: Anonymous 2016-02-17 9:24

>>8
This isn't OpenGL.
Of course. And Direct3D and OpenGL have never been competitors.

Name: Anonymous 2016-02-17 10:04

>>11
The whole purpose of Vulkan is that it is not OpenGL.

Name: Anonymous 2016-02-17 10:58

>>9
Shouldn't it be a banterer who does banter? And bantererer who does banterers? Or is it actually a bant that banter does?

Name: Anonymous 2016-02-17 11:13

>>12
Maybe. But the API still looks like a clusterfuck to me.

Name: Anonymous 2016-02-17 18:18

>>14
That's only because you haven't worked on a fully-featured real-time rendering engine with all of the bells and whistles.

It's not supposed to be an easy-to-use API for little kids to use, but rather a close to perfect mapping for what high-performance rendering engines need.

Name: Anonymous 2016-02-17 19:20

>>14
That's because you're an idiot.

Name: Anonymous 2016-02-17 20:53

>>6
Shut up byte-size cunt.

Name: Anonymous 2016-02-18 17:27

Its only v1.0, like OpenGL 1.0 it will become useless legacy shit no one cares about. Consider developing for it once it becomes established and widely supported.

Name: Anonymous 2016-02-18 17:59

>>18
Except OpenGL 1.0 isn't going away. It's fucking everywhere because it is the best documented and has the most examples, which is only because it is already everywhere. Try finding a nontrivial example of OpenGL 4.0 usage.

For example, I'm pretty sure most Scheme dialects that support it at all don't even have bindings for 2.0, much less three or four.

Name: Anonymous 2016-02-18 18:55

>>19
Can't they just use C FFI and link an openGL library?

Name: Anonymous 2016-02-18 19:01

>>20
That's what they use.

Name: Anonymous 2016-02-18 19:21

>>20
That Racket does: https://docs.racket-lang.org/sgl/gl.html, and it still only supports OpenGL 1.5. The ``lispy'' version of this API is even more pathetic and abandoned.

Name: Anonymous 2016-02-18 19:26

>>21
Try this one and import latest openGL headers
http://wiki.call-cc.org/eggref/4/easyffi

Name: Anonymous 2016-02-18 19:27

>>23
That's not the point. The point is that 1.0 is here to stay because it is seen as the default.

Name: Anonymous 2016-02-18 19:43

>>24
Google "dropped OpenGL * support"

Name: Anonymous 2016-02-18 19:57

>>23
And pretend I'm writing C with more parens? No Thank You !!

Name: Anonymous 2016-02-18 19:57

Its all emulated and wrapped into later openGL:
Modern GPUs no longer provide specialized hardware for the purpose of doing specific calculations in the OpenGL pipeline. Everything is done with shaders. In order to preserve compatibility, the GL driver generates a shader which emulates the fixed functionality.

Among many others, a simple example is rendering a primitive using one function call to submit each vertex attribute separately, e.g. glVertex3f(1.f, 0.f, 0.f)​, inside a glBegin()​ and glEnd()​ statement. Using shaders, you have to first define all vertex attributes in a local memory buffer, create a buffer object, and then transfer the vertex attributes using glBufferData​, glBufferSubData​ or by mapping the buffer using glMapBuffer​ or glMapBufferRange​. Shaders will then be able to use the data in the buffer object's data store for rendering.
https://www.opengl.org/wiki/FAQ#Do_modern_GPUs_still_support_the_fixed-function_pipeline.3F

Name: Anonymous 2016-02-18 20:26

Whats more important VGA is getting dropped this year.
http://www.zdnet.com/article/leading-pc-manufacturers-dropping-vga-support-by-2015/
http://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/4

Name: Anonymous 2016-02-19 6:55

>>28
I predict VESA video extensions will be replaced with DRM-laden UEFI graphics drivers in few years - after the "analog hole"(VGA) being plugged. All digital future with closed-source video path.

Name: Cudder !cXCudderUE 2016-02-19 12:05

>>28,29
A DVI is fine too.

Name: Anonymous 2016-02-19 13:20

>>29
hax my anal og hole

Name: Anonymous 2016-02-20 5:04

>>30
DVI supports HDCP as well.

Name: Anonymous 2016-02-21 12:24

>>32
So use DVI without HDCP. Problem solved.

Name: Anonymous 2016-02-22 6:22

>>33
Then comes mandatory HDCP.

Name: Anonymous 2016-02-22 9:15

Mandatory HTDP.

Name: Anonymous 2016-02-25 16:13

Mandatory Homotopy Type Theory.

Name: Anonymous 2016-02-27 20:32

>>29
It's already happening. Windows 7 was the last Microsoft OS that needed a VESA BIOS; once it's gone everything will be using EFI.

>>33
This however remains a totally viable option. The application you're using has to specifically elect to use HDCP, so if you aren't using a DRM encumbered player for DRM encumbered media you really oughtn't care.

The bigger thing to be worried about is mandatory signing of applications by the OS vendors, as is already a de facto standard on mobile devices. Then all the OS vendor needs to do in order to force you to use DRM encumbered players is to refuse to sign the free ones.

Name: Anonymous 2016-02-27 23:04

>>37
And the use of FPGA will require license?

Name: Anonymous 2016-02-28 0:17

http://c2.com/cgi/wiki?ProfessionalLicensingOfProgrammers

Name: Anonymous 2016-02-28 0:21

Should the software industry be a regulated profession, in the way that law, medicine, architecture and civil engineering are? If so, what sort of industry standards should there be, and how should they be enforced?

1. Regulation would empower users because they would get superior software as a result and wouldn't have to wade through mountains of dreck to find it.
2. It would also empower clients since they would no longer have to worry about incompetent programmers who are 30 years behind the state of the art.
3. Finally, it would empower programmers since people would take programmers seriously instead of demonstrating contempt of them.

Name: Anonymous 2016-02-28 10:06

>>40
No, it shouldn't.

Name: Anonymous 2016-02-28 11:52

>>40
I don't think it should be regulated. If you know about the ISO 9000 standard, you would know that there are already standards regarding the operation of a business and the quality of the product/service that's delivered.

Name: Anonymous 2016-02-28 16:14

The only licensed programmers are the knights of lambda calculus!

Name: Anonymous 2016-02-28 17:58

Render my dubs

Name: Cudder !cXCudderUE 2016-02-28 18:01

>>40
No, no, no, no, NO! The last thing we need is more corporate bureaucracy with no doubt the user-hostile "security" and DRM-loving faggots getting involved too.

>>42
The correct standard is ISO 9001:2008. IT'S OVER 9000!!!!!!!!11

Name: Anonymous 2016-02-28 19:45

>>45
You're no professional, Cudder.

Name: Cudder !cXCudderUE 2016-02-29 11:35

>>46
And proud of it.

"Amateurs built the ark. Professionals built the Titanic."

Name: Anonymous 2016-02-29 14:10

>>45-47
I miss the old Cudder.

Name: Anonymous 2016-02-29 18:40

Anyone who really wants a programming license needs to be put to the rope, seriously. What the fuck is wrong with you, fool?

Name: Anonymous 2016-02-29 22:09

A programming license would be like a hammering license.
Instead, make it so you need a license depending on what you want to hammer.
So, y can hammer a nail into a plank of wood you own without a license, but if you try to hammer a brain tumour, you'll need to get a license. If you try to hammer a space rocket containing live humans, you'll need a license. If you try to do some high-frequency stock market hammering, you'll need a license.
Et cetera.

Name: Anonymous 2016-03-01 0:19

>>50
Applied in the shit way the industry and bureaucracy always work, it'll take the more literal approach of needing a license for Java, a license for Python, a license for AWS, a license for Visual Studio, etc. In other words, completely missing the point of what programming and software engineering actually is.

Name: Anonymous 2016-03-02 7:43

>>40
this kind of nu-security approach really pisses me off. oldschool hacker approach to security was about education and experimentation, nu-security wants everything to be like a fucking mobile phone. the DON'T TOUCH ANYTHING AND LET BIG GUYS DO THEIR WORK shit is going to doom industry

Name: Anonymous 2016-03-02 8:09

>>51
basically, it would be legislated certificate fetishism, but with bonus government inefficiency. expect exams on which you'll need to calculate large prime numbers by hand and memorize opcodes

Name: Anonymous 2016-03-02 8:19

Should fetishism be a regulated activity?

Name: Anonymous 2016-03-02 10:46

>>54
Check 'em

Name: Anonymous 2016-03-02 20:29

Anyone know when I can get Vulkan to work on my Radeon HD7950 GPU on Linux? I know it's not supported at least at the beginning by Catalysty. What about Mesa?

Name: suigin 2016-03-06 8:40

>>56
Radeon HD7950 GPU

Your GPU won't ever be supported by AMD, at least not in the short to medium term. Vulkan will only be available with the new AMDGPU kernel driver, and that means Sea Islands/Volcanic Islands chipsets and later. Your only hope there is for Vulkan to eventually show up in Mesa and get backported for use with Radeon/Radeonsi drivers.

Thing is, AMD hasn't even released proprietary Linux drivers with Vulkan support yet. I was thinking about heading down and grabbing an nVidia GPU for my home system, but decided against it at the last minute. AMD better get their shit together.

Also, the 4.5 Linux kernel sure is taking a fucking long time to get out of RC purgatory. What gives?
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -