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

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.
Newer Posts
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 -