Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (808)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (872)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 3 4 [5] 6 7
  ignore  |  Print  
  Vulkan 1.0 Release  (Read 134216 times)
0 Members and 1 Guest are viewing this topic.
Offline theagentd
« Reply #120 - Posted 2016-03-12 01:01:48 »

New API?! O__O

Yes: new allocation methods in struct classes, configurable stack allocator implementation, thread-local API for convenience, explicit allocator parameters where it makes sense for top performance.
Hmm. Do you have a rough ETA for this? I want to know if it's worth waiting for your changes or if I should keep going.

Myomyomyo.
Offline Spasi
« Reply #121 - Posted 2016-03-12 01:43:36 »

Hmm. Do you have a rough ETA for this? I want to know if it's worth waiting for your changes or if I should keep going.

I'll work on it tomorrow, hoping to push a working prototype by Sunday morning at the latest.

Today I spent half the day tuning jemalloc and trying to get a feel of how its thread caching behaves. Also played a bit with custom arenas. Nothing exciting to report, but I did disable two compile-time features which resulted in a 10-13% performance increase for a tight malloc(4)/free loop. The next nightly build will have the newly configured jemalloc.

The other half, I spent verifying a stupid idea I had, to optimize Java-side thread-local access. It's so wicked that I'm not even going to share it here, but it is indeed 3-4x faster than ThreadLocal. It's used internally only in LWJGL and there'll be a configuration option to enable/disable it (not sure if I want to make it the default yet).

Btw, the reason I worked on that was to get thread-local stack allocations closer in performance to your BufferStack example. The idea is to be able to allocate structs without passing explicit stack objects, then do a static "pop" at the end. That should work fine for most use-cases and you could use an explicit stack for tight, performance-sensitive loops.
Offline theagentd
« Reply #122 - Posted 2016-03-12 09:13:17 »

The other half, I spent verifying a stupid idea I had, to optimize Java-side thread-local access. It's so wicked that I'm not even going to share it here, but it is indeed 3-4x faster than ThreadLocal. It's used internally only in LWJGL and there'll be a configuration option to enable/disable it (not sure if I want to make it the default yet).
I bet it's indexing into a static array based on the thread ID. =P

EDIT: Another more concrete way of doing that is to have a specific Thread class that implements some kind of ID number (preferably reused when a thread ends).
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
public class ThreadLocalThread extends Thread{
    private static ArrayList<Integer> availableIDs;
    static{
        availableIDs = new ArrayList<>(1024);
        for(int i = 0; i < 1024; i++){
            availableIDs.add(i);
        }
    }
   
    private int id;
   
    public ThreadSafeThread(){
        synchronized(availableIDs){
            id = availableIDs.remove(availableIDs.size()-1); //Remove last
        }
    }

    public void run(){
        super.run();
        synchronized(availableIDs){
            availableIDs.add(id); //Return ID to pool.
        }
    }

    public int getThreadSafeID(){
        return id;
    }
}

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #123 - Posted 2016-03-12 11:44:11 »

My LibStruct library has already solved the problem of blazingly fast thread-locals. No synchronization whatsoever. It works as long as you create fewer than 100_000 threads (or however much memory you're willing to throw at it).

https://github.com/riven8192/LibStruct/blob/fc8cd3092aa765cbe25cc0e9b8c98a48e279bf3a/src/net/indiespot/struct/runtime/FastThreadLocal.java

In LibStruct it is used for pushing and popping the stack on method entry and termination. IIRC it's at least, say, 100-1000x faster than ThreadLocal, as it replaces ThreadLocal's HashMap lookup by a plain memory access.


Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline KaiHH

JGO Kernel


Medals: 820



« Reply #124 - Posted 2016-03-12 11:54:00 »

Really? 100-1000x faster? That sounds amazing! Smiley
However, isn't Java's ThreadLocal lowered to the platform's thread-local memory support during JIT?
I mean, that Java ThreadLocal class is really just a "proof of concept" and shouldn't be done this "manual" way when a Java program gets compiled.
(just wondering)
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #125 - Posted 2016-03-12 11:56:17 »

Maybe it is today, but when I wrote LibStruct, it was dreadfully slow. LibStruct was unusable without this FastThreadLocal class. Just benchmark it on a JIT near you.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline Spasi
« Reply #126 - Posted 2016-03-12 12:39:00 »

Please note that my 3-4x figure was a comparison to a very simple program with a single ThreadLocal. The ThreadLocalMap lookup indeed slows down as you add more TLs, but the quick path is quite fast (~8ns).

The lookup in my code is equivalent to Riven's, except there's no array access. It works in any thread and for any number of threads. Btw, in my post I said "thread-local access", not "ThreadLocal replacement". Wink
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #127 - Posted 2016-03-12 14:03:21 »

Quote
The ThreadLocalMap lookup indeed slows down as you add more TLs, but the quick path is quite fast (~8ns).
There was only 1 thread-local in LibStruct, but it ground performance to a halt (compared to my FastThreadLocal)


I refered to "but it is indeed 3-4x faster than ThreadLocal". Given that ThreadLocal is (was?) super-slow, factor 3-4 isn't much Smiley

Why not share your crafty hacky new mechanism, then we can run some benchmarks.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline Spasi
« Reply #128 - Posted 2016-03-12 14:43:52 »

Just finished testing your implementation and it is indeed much faster.

But not because of the lookup speed itself, as I said my implementation is basically the same number of instructions and both are not more than 3-4x faster than ThreadLocal. The big difference is that the JVM is able to detect your code as loop invariant and moves it outside the benchmark loop. That's how you were able to see 100-1000x speedups. This is admittedly a big advantage for your method. I use Unsafe in my code which basically kills any code motion during JIT.

I'm respectfully asking for permission to add (a modified version of) FTL to LWJGL.
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #129 - Posted 2016-03-12 18:40:44 »

The big difference is that the JVM is able to detect your code as loop invariant and moves it outside the benchmark loop. That's how you were able to see 100-1000x speedups.
Ehm... which benchmark loop? It's a little presumptuous to think I would make such a rookie mistake when analyzing performance. Smiley

Like I said, maybe the JVM has optimized ThreadLocal performance these days, causing the FTL performance to be only 3-4x faster than TL, but when I was optimizing my demo, the framerate increased significantly, while I did maybe only a few 100k push/pops per frame, processing tens of millions of triangles, in code that I assume was way too big to fully inline, but I may be wrong there. I actually had quite an elaborate demo (still in the LibStruct repo, called SoftlyLit). In the end I even dropped FTL because it was not fast enough for my purposes (proving the JIT had not optimized it away entirely), opting for passing the stack reference as an argument to the methods that needed it. I had multi-threaded demos too, that did much more than pushing and popping the stack, so the measured performance jump was observed in a real world scenario (as far as demos can be considered as such).

Having said all that, you can take the concept of FTL and implement it into LWJGL. Smiley
As for credit, you can add @author Riven to the javadoc. Pointing

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #130 - Posted 2016-03-12 19:12:51 »

As for your Unsafe hack, did you read/write in the thread's native stack directly?

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline theagentd
« Reply #131 - Posted 2016-03-12 21:53:35 »

I just updated to the latest LWJGL version, and some found some peculiarities.

 - VkInstance and VkDevice seem to want the create info struct now as well. Does this imply that the constructor itself creates the object for you? If not, what do they need that information for?

 - The VkSubmitInfo and VkPresentInfoKHR (as far as I can see) set() functions have changed. They both require a count for just one of their buffers, which I see no reason for why it has been readded. Code generator bug? VkSubmitInfo requires a waitSemaphoreCount and VkPresentInfoKHR requires a swapchainCount.

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 820



« Reply #132 - Posted 2016-03-12 22:07:44 »

- The VkSubmitInfo and VkPresentInfoKHR (as far as I can see) set() functions have changed. They both require a count for just one of their buffers, which I see no reason for why it has been readded. Code generator bug? VkSubmitInfo requires a waitSemaphoreCount and VkPresentInfoKHR requires a swapchainCount.
See: http://www.java-gaming.org/topics/engaging-the-voyage-to-vulkan/37041/msg/354303/view.html#msg354303
This is all by design. Smiley
The problem is that some count fields in VK structs (VkSubpassDescription, VkSubmitInfo, VkPresentInfoKHR and VkPipelineViewportStateCreateInfo) affect multiple buffers.
Offline theagentd
« Reply #133 - Posted 2016-03-12 22:17:05 »

See: http://www.java-gaming.org/topics/engaging-the-voyage-to-vulkan/37041/msg/354303/view.html#msg354303
This is all by design. Smiley
The problem is that some count fields in VK structs (VkSubpassDescription, VkSubmitInfo, VkPresentInfoKHR and VkPipelineViewportStateCreateInfo) affect multiple buffers.
Geh. Why can't it just validate that those buffers have identical lengths and use that length?

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 820



« Reply #134 - Posted 2016-03-12 22:22:54 »

It's not possible, because LWJGL cannot access the buffers (specifically their length) anymore once they have been set. C does not provide a length information on a void*.
Spasi and I have been discussing this very very lengthy and trying to evaluate every possible design. This so far is the best we could think of. But maybe you have a better idea. Smiley
The only solution would be to shadow the C struct fields in Java, too.

There are ways to do it, yes. But every way would require severely limiting the use of the Vulkan struct API by requiring that certain fields be set before certain other fields. This would make valid C Vulkan programs difficult to port and would result in a direct port not being valid anymore under LWJGL semantics.
Offline theagentd
« Reply #135 - Posted 2016-03-13 00:14:51 »

Forgive me for stating the obvious, but implementing this on the Java side is easy as hell. I assume the code generator doesn't support this which is why you want to avoid it?

Myomyomyo.
Offline Spasi
« Reply #136 - Posted 2016-03-13 02:26:00 »

Ehm... which benchmark loop? It's a little presumptuous to think I would make such a rookie mistake when analyzing performance. Smiley

Like I said, maybe the JVM has optimized ThreadLocal performance these days, causing the FTL performance to be only 3-4x faster than TL, but when I was optimizing my demo, the framerate increased significantly, while I did maybe only a few 100k push/pops per frame, processing tens of millions of triangles, in code that I assume was way too big to fully inline, but I may be wrong there. I actually had quite an elaborate demo (still in the LibStruct repo, called SoftlyLit). In the end I even dropped FTL because it was not fast enough for my purposes (proving the JIT had not optimized it away entirely), opting for passing the stack reference as an argument to the methods that needed it. I had multi-threaded demos too, that did much more than pushing and popping the stack, so the measured performance jump was observed in a real world scenario (as far as demos can be considered as such).

FWIW, I tested ThreadLocal from Java 6 and up: ~14ns on Java 6, ~8ns on Java 7, 8, and 9.

FTL and the unsafe implementation get that down to 2-3ns.

Having said all that, you can take the concept of FTL and implement it into LWJGL. Smiley
As for credit, you can add @author Riven to the javadoc. Pointing

Thanks!

- VkInstance and VkDevice seem to want the create info struct now as well. What do they need that information for?

LWJGL uses the apiVersion and ppEnabledExtensionNames fields to build the VKCapabilities objects for VkInstance and VkDevice. Vulkan does not provide a way to query the enabled extensions, so it has to be done like that.

Forgive me for stating the obvious, but implementing this on the Java side is easy as hell. I assume the code generator doesn't support this which is why you want to avoid it?

I would be interested to know what you mean exactly. As KaiHH said, we've explored the possible approaches extensively and the current design had the best trade-offs. It'd be great if you have a better idea that we could discuss. It's easy to implement anything in the generator, but it would have to make sense.

The latest nightly build (3.0.0 #47) includes a stack allocation API. See the org.lwjgl.system.MemoryStack class (warning: WIP + no documentation). Struct classes have been augmented with stack allocation factory methods:

1  
2  
3  
4  
5  
6  
7  
malloc(MemoryStack); // explicit stack
calloc(MemoryStack);

mallocStack(); // thread-local stack
callocStack();

// similarly for struct buffers

Example usage: a) thread-local b) explicit

One possible improvement is to remove the need to call push(). It could do it automatically the first time you allocate after the last pop().
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #137 - Posted 2016-03-13 12:50:50 »

@Spasi: why the asymmetry between nmalloc and ncalloc parameters?

Also, in LibStruct I had cases where num*size overflowed, so I converted malloc/calloc to use longs as inputs.

You also have the assumption that the 'alignment' parameter is POT - you might want to enforce that.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline Spasi
« Reply #138 - Posted 2016-03-13 13:58:50 »

why the asymmetry between nmalloc and ncalloc parameters?

The C malloc and calloc functions have the same asymmetry.

Also, in LibStruct I had cases where num*size overflowed, so I converted malloc/calloc to use longs as inputs.

Technically possible, but why would anyone try to allocate > 2GB on the stack?

You also have the assumption that the 'alignment' parameter is POT - you might want to enforce that.

Thanks, will do.
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #139 - Posted 2016-03-13 14:42:46 »

Why not grow the stack towards zero (like the native stack) ?

It makes alignment more natural too:
   pntr &= ~(potAlignment-1);



As for >2G allocations: it was a general malloc/calloc function, but indeed, for a stack it makes less sense.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline theagentd
« Reply #140 - Posted 2016-03-13 16:27:52 »

Why not grow the stack towards zero (like the native stack) ?

It makes alignment more natural too:
   pntr &= ~(potAlignment-1);
Hmm.

1  
2  
int n = alignment - 1;
address = (address + n) & (~n);

vs

1  
address = address & ~(alignment-1);


I count 4 vs 3 instructions. Might make sense to add that.

Myomyomyo.
Offline Spasi
« Reply #141 - Posted 2016-03-14 17:33:31 »

A new build is up (3.0.0 #48).

a) There's a new Configuration.THREAD_LOCAL_SPACE option (or -Dorg.lwjgl.system.tls), you can use it to set the thread-local implementation. Supported values:

- "FastThreadLocal", Riven's implementation, the default.
- "unsafe", an implementation using Unsafe.
- "ThreadLocal", standard java.lang.ThreadLocal.

I don't expect significant, if any, gains from this, but if you try all 3 in a real-world application and have performance figures to share, please post here.

b) The stack implementation has been rewritten. It now has documentation, uses correct terminology and grows "downwards" like a native stack. Also made it static in size, the previous implementation was broken. Use the Configuration.STACK_SIZE option (or -Dorg.lwjgl.system.stackSize) to set the default size. The value is in kilobytes, defaults to 32.

c) I wasted too much time on performance testing again, this time the problem was that struct allocations in tight loops were inexplicably less optimal than buffer allocations.

In both cases I verified that escape analysis eliminated object allocations, but timing and JITWatch showed worse code generation. The problem manifested even when not touching the allocated struct object at all. The problem went away if I used Unsafe.allocateInstance to create the struct object, which is what LWJGL does internally for buffers that are not allocated via ByteBuffer.allocateDirect. After a while I figured out that the problem was final fields in the struct class.

Having any final field in a class (or its super-classes) causes the JVM to emit a memory barrier after the constructor has run. To understand why and the implications of this, see All Fields are Final. Normally this is fine, it's the desirable behavior in multi-threaded environments and has virtually no impact on ordered architectures (the barrier is a no-op on x86). But:

- The instances in my tests were eliminated via escape analysis. This means, by definition, that safe publication is not an issue because the object data will only be accessed by the current thread. The JVM already eliminates synchronized locks in such cases.
- The issue continued to occur when the final fields were not even accessed. There was nothing about those fields in the generated assembly, yet the barrier was still there.

For example, in code like:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
class Data {
    int x;
    int y;
    final int foo;
}

int test() {
    Data d = new Data(...);
    return d.x + d.y;
}

You always pay the cost for that final "foo" field, even if you don't use it at all.

Note that, in my tests, the barrier was not an actual CPU instruction (as I said, no-op on x86) but a compiler barrier. That is, all the loop unrolling and loop invariant code motions that I usually see in code that used buffers, was not happening in similar code that used structs. Removing all final modifiers made all the optimizations kick in.

Luckily, there has been a lot of work on JMM-related issues in Java 9 (see Shipilev's blog post for some examples). I was able to track down a post that mentions this issue, a first attempt to fix it and, finally, the actual fix that made it into Java 9. So, good news is that the unmodified struct code runs with top performance on recent Java 9 builds. But LWJGL has to run on Java 6+, so I'll have to compromise and trade good Java code for performance. If the fix is back-ported to Java 8, I'll restore the current code. Initial testing shows the workaround is a win on all Java versions before 9.
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #142 - Posted 2016-03-14 19:14:23 »

@Spasi: impressive bug-hunting



1  
2  
int n = alignment - 1;
address = (address + n) & (~n);

vs

1  
address = address & ~(alignment-1);


I count 4 vs 3 instructions. Might make sense to add that.

Let's go one step further Smiley
1  
pntr = (pntr >> n) << n; // unset n lowest bits

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline theagentd
« Reply #143 - Posted 2016-03-14 21:30:25 »

@Spasi: impressive bug-hunting



1  
2  
int n = alignment - 1;
address = (address + n) & (~n);

vs

1  
address = address & ~(alignment-1);


I count 4 vs 3 instructions. Might make sense to add that.

Let's go one step further Smiley
1  
pntr = (pntr >> n) << n; // unset n lowest bits


Well, if you precompute ~(alignment-1), then it's only one instruction. Fairly sure if you inline the alignment with a constant argument (align(4) for example) then it'll do that for us anyway, so I don't think it's a big deal. xd

Myomyomyo.
Offline Catharsis

JGO Ninja


Medals: 76
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #144 - Posted 2016-03-16 22:04:43 »

I'm at the Khronos Vulkan sessions being streamed right now. By chance are there any concerns / questions to ask any of the bigwigs here pertaining to any present issues w/ current LWJGL support for Vulkan?

https://www.khronos.org/news/events/2016-khronos-sessions-san-francisco

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline Spasi
« Reply #145 - Posted 2016-03-16 22:49:39 »

Thanks Catharsis. I can't think of anything though, the Vulkan bindings were straightforward and haven't had any issues.
Offline theagentd
« Reply #146 - Posted 2016-03-16 23:35:36 »

MULTI-GPU SUPPORT WHEN

Myomyomyo.
Offline Catharsis

JGO Ninja


Medals: 76
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #147 - Posted 2016-03-17 06:55:00 »

MULTI-GPU SUPPORT WHEN

Let's just say I just got back from the event and a great event it was... Small plug I'm super stoked that Dan Baker's (1 of 5 Dan's in the day) / Oxide's talk on Vulkan and the slide describing engine architecture fits almost to a T how TyphonRT is structured... And I'm a little tipsy right now.. I lingered, almost uncomfortably for myself as an introvert, and a bit toward the seeming end I disappeared to show a demo of my video engine tech to the Kishonti folks who had a wall wart to power my dead phone though were interested in what it takes to make Android / mobile GPUs sweat (yep got that covered). I came back to the main reception room and was near the last one left and was invited to finish off the wine with a core Khronos member, so much to share and say... This was and may be my only contact with Khronos in 13 years of GL development and into the unknown future. Many things were discussed including the difficulties of establishing communication channels to independent voices that fight the good fight despite any direct connect; erm you know who you are in this thread...  Shocked

From the wine fueled discussion and other discussions I had with a core Nvidia driver developer multi-GPU support is primary goal #1 whether it is first exposed as an extension or Vulkan 1.1 ratified spec nonetheless is up for imminent availability.

While final glasses of wine were consumed I shared this thread and got him to bookmark it on phone with said core Khronos member and made it clear that LWJGL is the future of Vulkan for Java. I'll be so bold in stating that in the after hours of the event when beer started to be consumed and as as a fellow indie dev I imbibed, as well TANSTAFB, nonetheless I poked and prodded anyone from Google. From my understanding from opinions shared (thanks!) there will not be an official Java / SDK binding for Vulkan in Android N, so for LWJGL it's prime time to spring into support for Android as the defacto standard binding for cross-platform Vulkan support. I haven't had time to review the initial Android N pre-release to confirm if a full version of sun.misc.Unsafe is present, but that seemingly is the only barrier for LWJGL to run away with official and the only binding to support Android.

Yep... I wished I could offer more support immediately to LWJGL. I gained enough insight today to know that I have to release my video engine effort via GLES 3.1 and no longer wait for Vulkan support; the main crux being extensions for video encode via Vulkan that are not on the present horizon and could be 1-2 years out easily. For the rest of yah though I'd be super stoked to see LWJGL run away with solid cross-platform support.  Cool Pointing I'm just the latter emoji pointing to y'all...

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline ziozio
« Reply #148 - Posted 2016-03-17 18:59:04 »

I was helping out spasi on the lwjgl forums with some travis configuration to help build lwjgl on arm for the raspberry pi (I am abcde there), when I did that I did start playing around getting a travis build working with android ndk. If spasi is interest in getting a lwjgl build for vulcan on android I can help out and finish it off.
Offline KaiHH

JGO Kernel


Medals: 820



« Reply #149 - Posted 2016-03-17 23:00:35 »

Wrote a very simple Java Agent that allows you to use LWJGL 3's stack allocation without having to create stack frames manually and handle control-flow (returns and exceptions) separately by stackPush/stackPop yourself.

It automatically detects when you want to use stack allocation in a given method (looking for Struct.mallocStack/callocStack and MemoryStack.stackGet) and then provides the stack frame at the method start and frees it at the end of the method, properly handling every control flow (intermittent RETURNs in the method and exception throwing).

There are some caveats:
- you have to start the JVM with the VM argument "-javaagent:autostack.jar" (this is really annoying in my opinion, but unavoidable unless you want to have a custom build/compile step)
- it really is a 1:1 mapping between the lifecycle of Java methods/stack frames and MemoryStack stack frames, so if you decide to wrap/delegate stack allocation of structs to some other method that expect some stack to be setup by the caller which survives the callee, you're out of luck Smiley

Code: https://github.com/httpdigest/lwjgl3-autostack
Pages: 1 ... 3 4 [5] 6 7
  ignore  |  Print  
 
 

 
Riven (847 views)
2019-09-04 15:33:17

hadezbladez (5791 views)
2018-11-16 13:46:03

hadezbladez (2603 views)
2018-11-16 13:41:33

hadezbladez (6207 views)
2018-11-16 13:35:35

hadezbladez (1499 views)
2018-11-16 13:32:03

EgonOlsen (4734 views)
2018-06-10 19:43:48

EgonOlsen (5792 views)
2018-06-10 19:43:44

EgonOlsen (3276 views)
2018-06-10 19:43:20

DesertCoockie (4175 views)
2018-05-13 18:23:11

nelsongames (5501 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!