<feed xmlns='http://www.w3.org/2005/Atom'>
<title>slang.git/source/slang/hlsl.meta.slang.cpp, branch master</title>
<subtitle>Making it easier to work with shaders</subtitle>
<id>https://git.yummers.dev/slang.git/atom?h=master</id>
<link rel='self' href='https://git.yummers.dev/slang.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/'/>
<updated>2017-09-27T18:17:39+00:00</updated>
<entry>
<title>First attempt at a Linux build (#193)</title>
<updated>2017-09-27T18:17:39+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoleyNV@users.noreply.github.com</email>
</author>
<published>2017-09-27T18:17:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=74f2f47cb63b02638270beecd20acea1a0f5665e'/>
<id>urn:sha1:74f2f47cb63b02638270beecd20acea1a0f5665e</id>
<content type='text'>
* First attempt at a Linux build

- Fix up places where C++ idioms were written assuming lenient behavior of Microsoft's compiler

- Add a few more alternatives for platform-specific behavior where Windows was the only platform accounted for.

- Add a basic Makefile that can at least invoke our build, even if it isn't going good dependency tracking, etc.

- Build `libslang.so` and `slangc` that depends on it, using a relative `RPATH` to make the binary portable (I hope)

- Add an initial `.travis.yml` to see if we can trigger their build process.

* Fixup: const bug in `List::Sort`

I'm not clear why this gets picked up by the gcc *and* clang that Travis uses, but not the (newer) gcc I'm using on Ubuntu here, but I'm hoping it is just some missing `const` qualifiers.

* Fixup: reorder specialization of "class info"

Clang complains about things being specialized after being instantiated (implicilty), and I hope it is just the fact that I generate the class info for the roots of the hierarchy after the other cases. We'll see.

* Fixup: add `platform.cpp` to unified/lumped build

* Fixup: Windows uses `FreeLibrary`

and not `UnloadLibrary`

* Fixup: fix Windows project file to include new source file

This obviously points to the fact that we are going to need to be generating these files sooner or later.
</content>
</entry>
<entry>
<title>IR: handle control flow constructs (#186)</title>
<updated>2017-09-14T22:37:05+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoleyNV@users.noreply.github.com</email>
</author>
<published>2017-09-14T22:37:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=10b62eecd94be53eca4ac2555af860f864966d76'/>
<id>urn:sha1:10b62eecd94be53eca4ac2555af860f864966d76</id>
<content type='text'>
* IR: handle control flow constructs

This change includes a bunch of fixes and additions to the IR path:

- `slang-ir-assembly` is now a valid output target (so we can use it for testing)
  - This uses what used to be the IR "dumping" logic, revamped to support much prettier output.
  - A future change will need to add back support for less prettified output to use when actually debugging

- IR generation for `for` loops and `if` statements is supported

- HLSL output from the above control flow constructs is implemented

- Revamped the handling of l-values, and in particular work on compound ops like `+=`

- Add basic IR support for `groupshared` variables

- Add basic IR support for storing compute thread-group size

- Output semantics on entry point parameters
  - This uses the AST structures to find semantics, so its still needs work

- Pass through loop unroll flags
  - This is required to match `fxc` output, at least until we implement
    unrolling ourselves.

* Fixup: 64-bit build issues.

* fixup for merge
</content>
</entry>
<entry>
<title>Support IR-based codegen for a few more examples.</title>
<updated>2017-09-11T21:06:02+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoley@nvidia.com</email>
</author>
<published>2017-09-11T16:33:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=2055d540c5dd420448a6924d784d5aed0efcd93d'/>
<id>urn:sha1:2055d540c5dd420448a6924d784d5aed0efcd93d</id>
<content type='text'>
The main interesting change here is around support for lowering of calls to "subscript" operations (what a C++ programmer would think of as `operator[]`).

An important infrastructure change here was to add an explicit AST-node representation for a "static member expression" which we use whenever a member is looked up in a type as opposed to a value. The implementation of  this probably isn't robust yet, but it turns out to be important to be able to tell such cases apart.
</content>
</entry>
<entry>
<title>Initial work on boilerplate code generator</title>
<updated>2017-09-11T16:50:56+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoley@nvidia.com</email>
</author>
<published>2017-09-07T21:35:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=14137cbd2ddd7deebcdf8cc85c30d534bec8e40b'/>
<id>urn:sha1:14137cbd2ddd7deebcdf8cc85c30d534bec8e40b</id>
<content type='text'>
The goal here is to get the Slang "standard library" code out of string literals and into something a bit more like an actual code file.
This is handled by having a `slang-generate` tool that can translate a "template" file that mixes raw Slang code (or any language we want to generate...) with generation logic that is implemented in C++ (currently).

This work isn't final by any stretch of the imagination, but it moves a lot of code and not merging it ASAP will complicate other changes.
My expectation is that the generator tool will be beefed up on an as-needed basis, to get our stdlib code working.

Similarly, the stdlib code does not really take advantage of the new approach as much as it could. That is something we can clean up along the way as we do modifications of the stdlib.
</content>
</entry>
</feed>
