Vulkan is here!

Vulkan is here!

[olivier.henley]

:)

https://www.khronos.org/vulkan/
https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf

Re: Vulkan is here!

[Randy Brukardt]

Does it have anything (directly) to do with Ada? I couldn't find anything in 
a quick look.

                      Randy.

P.S. I ask, of course, to see if there is anything that needs to be linked 
on AdaIC. Not trying to be a pain in some body part. ;-)

<olivier.henley@gmail.com> wrote in message 
news:bf1c421d-0fce-417a-8ace-c5f1581b7597@googlegroups.com...
> :)
>
> https://www.khronos.org/vulkan/
> https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf 

Re: Vulkan is here!

[Luke A. Guest]

Randy Brukardt <randy@rrsoftware.com> wrote:
> Does it have anything (directly) to do with Ada? I couldn't find anything in 
> a quick look.
> 
>                       Randy.
> 
> P.S. I ask, of course, to see if there is anything that needs to be linked 
> on AdaIC. Not trying to be a pain in some body part. ;-)
> 
> <olivier.henley@gmail.com> wrote in message 
> news:bf1c421d-0fce-417a-8ace-c5f1581b7597@googlegroups.com...
>> :)
>> 
>> https://www.khronos.org/vulkan/
>> https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf 
> 
> 
> 

Not yet

Re: Vulkan is here!

[olivier.henley]

On Wednesday, February 17, 2016 at 3:31:20 PM UTC-5, Randy Brukardt wrote:
> Does it have anything (directly) to do with Ada? I couldn't find anything in 
> a quick look.
> 
>                       Randy.
> 
> P.S. I ask, of course, to see if there is anything that needs to be linked 
> on AdaIC. Not trying to be a pain in some body part. ;-)


As you probably know it is the next OpenGL and has nothing to do with Ada per se. Sorry for spamming...

but IMO, it is great news for computing in general. :)

Re: Vulkan is here!

[Luke A. Guest]

<olivier.henley@gmail.com> wrote:
> :)
> 
> https://www.khronos.org/vulkan/
> https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf
> 

Yup was quite a surprise yesterday at 3!

It's something I've been planing on binding. It's bigger than I expected,
just look at API overview card, 13 pages!

Re: Vulkan is here!

[olivier.henley]

On Wednesday, February 17, 2016 at 5:37:16 PM UTC-5, Luke A. Guest wrote:
> Yup was quite a surprise yesterday at 3!
> 
> It's something I've been planing on binding. It's bigger than I expected,
> just look at API overview card, 13 pages!

I would really like to help you with that but my mileage to translate C stuff is limited. In my spare time I'm "augmenting" a one-to-one binding to xlib because suprisingly I found only half implementations here and there.

p.s: I dont get it why people don't systematically make a thin binding, standalone, and then undertake any other Ada-ized layer over it separately. I hate extracting stuff from others "wool ball".

 

Re: Vulkan is here!

[Olivier Henley]

On Wednesday, February 17, 2016 at 6:56:23 PM UTC-5, Olivier Henley wrote:
> uprisingly I found only half implementations here and there.

I'm lying, the one from Intermetrics was complete.

Re: Vulkan is here!

[Luke A. Guest]

<olivier.henley@gmail.com> wrote:
> On Wednesday, February 17, 2016 at 5:37:16 PM UTC-5, Luke A. Guest wrote:
>> Yup was quite a surprise yesterday at 3!
>> 
>> It's something I've been planing on binding. It's bigger than I expected,
>> just look at API overview card, 13 pages!
> 
> I would really like to help you with that but my mileage to translate C
> stuff is limited. In my spare time I'm "augmenting" a one-to-one binding
> to xlib because suprisingly I found only half implementations here and there.

I need to look through the vk.xml and the readme.pdf properly, I've only
skimmed it. If it's similar enough to to the GL XML file I'll extend my GL
binding generator to do it.

I've actually not finished the GL binding generator yet 😖

Otherwise I'll likely think about extending their scripts as it would be
nice to try to get the Ada stuff folded back into the original source and
add documentation as well.

> 
> p.s: I dont get it why people don't systematically make a thin binding,
> standalone, and then undertake any other Ada-ized layer over it
> separately. I hate extracting stuff from others "wool ball".

Because it's nicer to use a thick binding over thin ones.

Luke

Re: Vulkan is here!

[Olivier Henley]

On Wednesday, February 17, 2016 at 8:22:43 PM UTC-5, Luke A. Guest wrote:
> Because it's nicer to use a thick binding over thin ones.
> 
> Luke

It is "nicer" when you assume that every one swears by your coding paradigm (the one forced by the thick layer)... which is, I think, close minded.  

A standalone thin layer does not prevent anyone else from undertaking a thick layer over it and still retains freedom for others.

Re: Vulkan is here!

[Per Sandberg]

Well i'd put an hour on the "problem" to get a complete lowlevel binding 
and it is correct with all methods and and constants and is now in 
github ready to be extended with some highlevel stuff.

https://github.com/persan/a-vulkan

/Per


Den 2016-02-18 kl. 16:58, skrev Olivier Henley:
> On Wednesday, February 17, 2016 at 8:22:43 PM UTC-5, Luke A. Guest wrote:
>> Because it's nicer to use a thick binding over thin ones.
>>
>> Luke
>
> It is "nicer" when you assume that every one swears by your coding paradigm (the one forced by the thick layer)... which is, I think, close minded.
>
> A standalone thin layer does not prevent anyone else from undertaking a thick layer over it and still retains freedom for others.
>

Re: Vulkan is here!

[Simon Wright]

Per Sandberg <per.s.sandberg@bahnhof.se> writes:

> Well i'd put an hour on the "problem" to get a complete lowlevel
> binding and it is correct with all methods and and constants and is
> now in github ready to be extended with some highlevel stuff.
>
> https://github.com/persan/a-vulkan

You translate (~0U) as 0, but the ~ operator is bitwise-inversion, so ~0
is all-1s (in whatever length is appropriate).

Hope the size indicators are correct; you could generate for instance

   VK_WHOLE_SIZE : constant Unsigned_64 := not 0;

Re: Vulkan is here!

[Per Sandberg]

Thanks  missed that patch.
It's corrected.
/P


Den 2016-02-19 kl. 00:21, skrev Simon Wright:
> Unsigned_64 := not 0

Re: Vulkan is here!

[Per Sandberg]

The above miss highlights the danger of trusting humans for simple transformation of data.

Re: Vulkan is here!

[Simon Wright]

Per Sandberg <per.s.sandberg@bahnhof.se> writes:

> Thanks  missed that patch.
> It's corrected.
> /P
>
>
> Den 2016-02-19 kl. 00:21, skrev Simon Wright:
>> Unsigned_64 := not 0

I'm not sure that all of the constants are Unsigned_64? I'm not familiar
with C constant qualifiers, but it's at least possible that (~0U) is
Unsigned_32, (~0ULL) is Unsigned_64? This will depend on where the
constants get used.

I can't check this out, because OS X isn't supported.

Re: Vulkan is here!

[Per Sandberg]

That's the problem when going from an untyped language with MACROS to a typed language with constants.
In my experience a working way to get the "types" correct is a to do a higher level of binding, that way those ambiguities usually sort them self out.

/Per

Re: Vulkan is here!

[Simon Wright]

Per Sandberg <persan.sandberg@gmail.com> writes:

> That's the problem when going from an untyped language with MACROS to
> a typed language with constants.
> In my experience a working way to get the "types" correct is a to do a
> higher level of binding, that way those ambiguities usually sort them
> self out.

Indeed.

As an alternative translation, which allows the compiler to decide,

   function VK_WHOLE_SIZE return Unsigned_64 is (not 0);
   function VK_WHOLE_SIZE return Unsigned_32 is (not 0);
   function VK_WHOLE_SIZE return Unsigned_16 is (not 0);
   function VK_WHOLE_SIZE return Unsigned_8 is (not 0);

Re: Vulkan is here!

[G.B.]

On 19.02.16 13:05, Simon Wright wrote:
> As an alternative translation, which allows the compiler to decide,

To let the compiler decide seems the Right Thing, insofar
as this also reflects what C's int types are about. Of course,
neither the C implementation nor the Ada implementation are
free to decide at whim, because either language's type system
has requirements for, respectively, int and Integer etc.

There's also System.Word_Size on the Ada side; maybe the Ada
compiler docs inform about the relation of that static constant
to the (auto-convertible) C expression "~0" in context, allowing
the definition of matching Ada types, or finding potential
width errors in pre-C99 stdint C use.

thick bindings, was Re: Vulkan is here!

[tmoran]

> p.s: I dont get it why people don't systematically make a thin binding,
> standalone, and then undertake any other Ada-ized layer over it
> separately. I hate extracting stuff from others "wool ball".

A thick binding, like any API, creates an abstraction intended to be
easier and safer to program than coding at a lower level.  If you don't
like the abstraction, don't use it - it's straightforward to code the
necessary lower level thin binding instead.

A thick binding makes many assumptions about the state of the machine and
coding at the thin binding level likely makes those invalid.  Luring the
programmer into trying to code at two different abstraction levels at
the same time is not a kindness.

Re: thick bindings, was Re: Vulkan is here!

[Olivier Henley]

On Thursday, February 18, 2016 at 11:21:26 PM UTC-5, tmo...@acm.org wrote:
> A thick binding, like any API, creates an abstraction intended to be
> easier and safer to program than coding at a lower level.  If you don't
> like the abstraction, don't use it - it's straightforward to code the
> necessary lower level thin binding instead.
> 
> A thick binding makes many assumptions about the state of the machine and
> coding at the thin binding level likely makes those invalid.  Luring the
> programmer into trying to code at two different abstraction levels at
> the same time is not a kindness.

1. I understand the goals of a thick binding. 

2. I questioned its architecture.

3. I answered that previously: It is "nicer" when you assume that every one swears by your coding paradigm (the one forced by the thick layer)... which is, I think, close minded. A standalone thin layer does not prevent anyone else from undertaking a thick layer over it and still retains freedom for others.

4. It is not THAT straightforward to make a pristine lower level thin binding as both Per Sandberg and Simon Wright have to exchange to clarify possible caveats.

Re: thick bindings, was Re: Vulkan is here!

[Alejandro R. Mosteo]

On 19/02/16 14:07, Olivier Henley wrote:
> On Thursday, February 18, 2016 at 11:21:26 PM UTC-5, tmo...@acm.org wrote:
>> A thick binding, like any API, creates an abstraction intended to be
>> easier and safer to program than coding at a lower level.  If you don't
>> like the abstraction, don't use it - it's straightforward to code the
>> necessary lower level thin binding instead.
>>
>> A thick binding makes many assumptions about the state of the machine and
>> coding at the thin binding level likely makes those invalid.  Luring the
>> programmer into trying to code at two different abstraction levels at
>> the same time is not a kindness.
>
> 1. I understand the goals of a thick binding.
>
> 2. I questioned its architecture.
>
> 3. I answered that previously: It is "nicer" when you assume that every one swears by your coding paradigm (the one forced by the thick layer)... which is, I think, close minded. A standalone thin layer does not prevent anyone else from undertaking a thick layer over it and still retains freedom for others.
>
> 4. It is not THAT straightforward to make a pristine lower level thin binding as both Per Sandberg and Simon Wright have to exchange to clarify possible caveats.

And nowadays the thinnest of bindings should be even easier: 
http://www.adacore.com/adaanswers/gems/gem-59/

Not pretty IME though, but can be a start.

Re: thick bindings, was Re: Vulkan is here!

[Lucretia]

On Friday, 19 February 2016 15:38:14 UTC, Alejandro R. Mosteo  wrote:
> On 19/02/16 14:07, Olivier Henley wrote:

> > 4. It is not THAT straightforward to make a pristine lower level thin binding as both Per Sandberg and Simon Wright have to exchange to clarify possible caveats.
> 
> And nowadays the thinnest of bindings should be even easier: 
> http://www.adacore.com/adaanswers/gems/gem-59/
> 
> Not pretty IME though, but can be a start.

If you've started reading the spec, you'll notice that creating a thick binding to Vulkan is going to be quite difficult due to the amount of locking involved. 

I intend to create a simple thin binding and then build of that after some experimentation.

Re: thick bindings, was Re: Vulkan is here!

[Per Sandberg]

Do you want top start from scratch or colaborate ?
I would gladly give you write access to
	https://github.com/persan/a-vulkan.

This is gem-59 generated stuff.

/P




Den 2016-02-19 kl. 17:54, skrev Lucretia:
> On Friday, 19 February 2016 15:38:14 UTC, Alejandro R. Mosteo  wrote:
>> On 19/02/16 14:07, Olivier Henley wrote:
>
>>> 4. It is not THAT straightforward to make a pristine lower level thin binding as both Per Sandberg and Simon Wright have to exchange to clarify possible caveats.
>>
>> And nowadays the thinnest of bindings should be even easier:
>> http://www.adacore.com/adaanswers/gems/gem-59/
>>
>> Not pretty IME though, but can be a start.
>
> If you've started reading the spec, you'll notice that creating a thick binding to Vulkan is going to be quite difficult due to the amount of locking involved.
>
> I intend to create a simple thin binding and then build of that after some experimentation.
>

Re: thick bindings, was Re: Vulkan is here!

[Lucretia]

This is a project I have been planning since it was announced. I've already started.

I want Ada to have a decent Vulkan binding from the outset and not get left behind like we have with OpenGL (I still need to finish my binding generator for GL!).

I'm still annoyed at AMD for having a Linux driver ready and the Windows driver is not fully comformant either.

I do think a more collaborative operation would be better, but it needs someone who knows C a bit better to get the ball rolling. Plus there's more that just creating the binding, it has to have all the flags in place for compiling for other OSes due to the various window manager extensions.

Luke.

Re: thick bindings, was Re: Vulkan is here!

[Lucretia]

I have no problem with collaboration. I'll put up what I have on Github and my plan and we can compare.

Re: thick bindings, was Re: Vulkan is here!

[Per Sandberg]

Many thumbs up.

Since I believe the all hands should try to join and collaborate, if 
your start-point is better then mine i gladly nuke mine ;)

And put my thinking into yours.

/P


Den 2016-02-19 kl. 19:02, skrev Lucretia:
> I have no problem with collaboration. I'll put up what I have on Github and my plan and we can compare.
>

Re: thick bindings, was Re: Vulkan is here!

[Randy Brukardt]

"Olivier Henley" <olivier.henley@gmail.com> wrote in message 
news:66c5617d-49e6-40eb-9341-31c6664b1f6c@googlegroups.com...
On Thursday, February 18, 2016 at 11:21:26 PM UTC-5, tmo...@acm.org wrote:
> A thick binding, like any API, creates an abstraction intended to be
> easier and safer to program than coding at a lower level.  If you don't
> like the abstraction, don't use it - it's straightforward to code the
> necessary lower level thin binding instead.
...
>2. I questioned its architecture.

True thin bindings are trivial to make (and can be pretty much automated), 
but they completely lose any advantage to using Ada. Pretty much the only 
thing to do with a true thin-binding is use it to make a thicker binding, 
else you would be better off writing in C. (C has meager correctness 
checking, but you lose even that when you cross the boundary between 
languages. The use of Ada is actually a negative in such circumstances.)

What I've often advocated in such circumstances is the creation of a "medium 
binding". That is, eliminate the visibility at C issues without changing the 
essense of the binding (thus existing examples can be used with it). We did 
that for Windows waaay back before Claw; in the Windows 3.1 timeframe we 
made a medium binding for essentially all of the Windows interface of the 
time. It use the same operations but eliminated various c-isms:
    (1) Routines were named with underscores;
    (2) Overloading was used rather than unions (this was before 
Unchecked_Union was invented);
    (3) Boolean failure results were mapped to exceptions;
    (4) In out parameters were used rather than access parameters as much as 
possible (this requires inspection of the API in many cases);
    (5) null-terminated strings were converted into normal Ada string 
parameters where possible;
    (6) enumeration types were used rather than sets of constants if the 
values were distinct.

There probably were a few other changes that I've since forgotten. (Probably 
some typing was strengthened.)

(1) probably is a matter of taste (I find it near impossible to type 
identifiers that don't have the words separated by underscores, YMMV), and 
more recent improvements in Ada mean that (2) and (4) probably get at least 
partially handled by automatic conversion. But (3), (5), and (6) are the 
essence of Ada; without at least that you are gaining nothing for the 
significant loss of checking.

The important reason for having access to some low-level binding is so that 
one can directly translate examples into Ada. The idea is that a medium 
binding preserves that (one uses the same objects, same parameters [possibly 
better typed], same subprogram calls), but makes those calls more sensible 
Ada code, letting the compiler provide more help to the programmer.)

In contrast, a thick binding like Claw uses a different, more Ada-like 
overall design. Which means that one has to use only Claw examples -- most 
foreign language material doesn't work (at least not without a lot of mental 
translation). I agree with you that hiding the original API to that level 
can be a problem if your application doesn't fit into it's model - or you 
can't figure out how to do what you want even though you have a C example in 
front of you.

I would have preferred to concentrate on medium bindings, myself, but it 
didn't appear that we could sell such a thing (too hard to explain the 
value, especially to non-Ada programmers) so we wrote an ATIP-P proposal for 
Claw, not MAWB (Medium Ada Windows Binding). Which was accepted, so the 
route was cast...

                         Randy.

Re: thick bindings, was Re: Vulkan is here!

[Olivier Henley]

@Randy:

I totally agree with you. 

Adapting is one thing, starting to directly cramp mecanics over the original (or change completely the paradigm of the API) ... and while at it not cover the whole api, is another.

Then, sprinkle a little bit of "un-maintenance" and after a couple of years you get a UBIB (Useless Broken Incomplete Binding). 

:D

       

Re: thick bindings, was Re: Vulkan is here!

[Luke A. Guest]

Randy Brukardt <randy@rrsoftware.com> wrote:

> True thin bindings are trivial to make (and can be pretty much automated), 
> but they completely lose any advantage to using Ada. Pretty much the only 
> thing to do with a true thin-binding is use it to make a thicker binding, 
> else you would be better off writing in C. (C has meager correctness 
> checking, but you lose even that when you cross the boundary between 
> languages. The use of Ada is actually a negative in such circumstances.)

Vulkan really is an unusual API in that there is supposed to be minimal to
no error checking at the lowest layer. The higher layers do the checking
then when you release the app you turn off the debugging layers.

The vk.xml file already separates bit masks and enums properly.

I think this is likely to be a medium binding tbh.

Luke

Re: thick bindings, was Re: Vulkan is here!

[tmoran]

>The important reason for having access to some low-level binding is so that
>one can directly translate examples into Ada. The idea is that a medium
>binding preserves that (one uses the same objects, same parameters [possibly
>better typed], same subprogram calls), but makes those calls more sensible
>Ada code, letting the compiler provide more help to the programmer.)

  As I recall, there were a lot of Windows calls that did not work as
documented (or weren't documented completely).  A thick binding like CLAW
works around and thus hides such things.  A mechanically produced binding
wouldn't do that.
  For instance, I have a mechanically produced thin, and hand made thick,
binding to the Google Earth API.  Several years ago Google changed the
meaning of some of the parameters to an important function.  The thick
binding can check the API version and do the right thing - the thin binding
can't.

Re: thick bindings, was Re: Vulkan is here!

[Randy Brukardt]

<tmoran@acm.org> wrote in message news:na912e$cv0$1@gioia.aioe.org...
> >The important reason for having access to some low-level binding is so 
> >that
>>one can directly translate examples into Ada. The idea is that a medium
>>binding preserves that (one uses the same objects, same parameters 
>>[possibly
>>better typed], same subprogram calls), but makes those calls more sensible
>>Ada code, letting the compiler provide more help to the programmer.)
>
>  As I recall, there were a lot of Windows calls that did not work as
> documented (or weren't documented completely).  A thick binding like CLAW
> works around and thus hides such things.  A mechanically produced binding
> wouldn't do that.

True enough. In fairness to Microsoft, the state of their documentation in 
more recent years is a lot better than it was when we started creating CLAW. 
I recall being surprised on several occasions by reading about stuff that we 
had to figure out by trial-and-error. (Of course, that probably came about 
because of their anti-trust problems. One of the things they agreed to in 
the settlements was to fully document all APIs. The typical open source 
library probably doesn't have legal reasons for getting the documentation 
correct and complete. ;-)

                                             Randy.