Issues using OpenGL with an AI

Issues using OpenGL with an AI

Here is where ideas can be collected for the skirmish AI in development

Moderators: hoijui, Moderators

Post Reply
aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Issues using OpenGL with an AI

Post by aeonios » 21 Dec 2015, 16:31

I had some problems with painting the threatmap being pathologically slow (as in dragging spring down to 1fps) using java's built-in graphics functionality, so I ended up implementing my own GL-based 2D graphics library because there wasn't one that I could find.

While I got the library basically working I'm having problems using GL from the AI due to the fact that all of its code is called from events. A GL Context created during init() becomes unreachable from update(), and if I try to unbind the context at the end of init to make it available later it causes spring to crash immediately after init() returns (some graphics-related dll error).

Does anyone have any idea how to deal with this sort of thing?
0 x

User avatar
AF
AI Developer
Posts: 20667
Joined: 14 Sep 2004, 11:32

Re: Issues using OpenGL with an AI

Post by AF » 21 Dec 2015, 22:24

I believe you're the first to try this, but AIs have never been given a render/draw callin. My recommendation would be to draw it in a widget or gadget, and send the data over the interface
0 x

lamer
Posts: 146
Joined: 08 Mar 2014, 23:13

Re: Issues using OpenGL with an AI

Post by lamer » 22 Dec 2015, 00:41

I think mantis issue is related. The heck glfwMakeContextCurrent(NULL) for? Try

Code: Select all

previousContext = glfwSomethingGetCurrentContext();
...init...
glfwMakeContextCurrent(previousContext);
Regardless, CircuitAI's DebugDrawer.cpp proves that context switch works.
0 x

aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Issues using OpenGL with an AI

Post by aeonios » 22 Dec 2015, 09:25

lamer wrote:I think mantis issue is related. The heck glfwMakeContextCurrent(NULL) for? Try

Code: Select all

previousContext = glfwSomethingGetCurrentContext();
...init...
glfwMakeContextCurrent(previousContext);
Regardless, CircuitAI's DebugDrawer.cpp proves that context switch works.
Tried it, failed. glfw does not see spring's context so I can't save/restore it. It just ends up binding to no context which crashes spring again.

You can only have one context active in a thread, and each context can only be active in one thread at a time. Therefore in order to pass a context from thread A to thread B first you have to unbind it from A (using glfwMakeContextCurrent(NULL)) and then make it current in B. For whatever reason the events that AIs are called through behave like threads wrt gl context, so if I create a context during init() it will no longer be available during update().

Also, I can save and restore the GL context that I manage, but I cannot make spring do the same for its own.

EDIT: I think a better solution might be to spawn a new thread and keep all my GL content there. That way (in theory) spring couldn't tamper with it anymore. On the other hand that requires putting all of the ai's implementation behind synchronized methods. x.x
0 x

lamer
Posts: 146
Joined: 08 Mar 2014, 23:13

Re: Issues using OpenGL with an AI

Post by lamer » 22 Dec 2015, 11:56

You can only have one context active in a thread, and each context can only be active in one thread at a time.
Not exactly, threads has nothing to do with context. In simple case: there is GPU controled by OpenGL which is a state machine. Context describes its state. All there is to do is properly switch state descriptors (contexts). Here's how it is possible to achieve:
On init:

Code: Select all

previousContext = glfwSomethingGetCurrentContext();
aiContext = glfwSomethingCreateContext();
glfwMakeContextCurrent(aiContext);
...init...
glfwMakeContextCurrent(previousContext);
On update:

Code: Select all

previousContext = glfwSomethingGetCurrentContext();
glfwMakeContextCurrent(aiContext);
...update...
glfwMakeContextCurrent(previousContext);
Context switch in AI already done and working (except it goes through SDL bindings, like Kloot mentioned):
Circuit's init, update, release.

Though switching context has own cost (not sure if that cost matters if it's done once per second or so).

EDIT: With gadget and AI<->Lua communication you don't even need to switch context. OpenGL in spring-AI is an ugly hax.
Last edited by lamer on 22 Dec 2015, 16:13, edited 2 times in total.
0 x

User avatar
AF
AI Developer
Posts: 20667
Joined: 14 Sep 2004, 11:32

Re: Issues using OpenGL with an AI

Post by AF » 22 Dec 2015, 12:49

I'd recommend lua <-> AI comms. AIs themselves are intended to be headless, with a handful of call-ins to allow for limited debugging. I'd much prefer it if AIs sent the relevant data to the game in such a way that it's stored in the replays. Imagine an end user giving you a replay and being able to run the replay and see all the data displayed without needing the AI installed, just the widgets. It'd be a massive boon to AI debugging and tweaking
0 x

aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Issues using OpenGL with an AI

Post by aeonios » 22 Dec 2015, 16:31

I tried using glfwGetCurrentContext to save and restore spring's context, and spring still crashed. I'm not entirely sure why, but it's probably because I'm using lwjgl/glfw instead of sdl. I also tried running all of the openGL code in separate threads and binding the context to each as needed, which crashed both the ai and spring.

Using lua is stupid. AIs don't have the rights to use lua, and I'd have to have my stupid hacked drawing gadget accepted into zk stable even though the ai isn't even part of the game right now. That also pisses me off because I just spent 3 weeks writing a stupid 2D graphics library so that I could make this work. Not to mention I'd have to take extra measures to avoid cheating and the lua gadget would be horribly disconnected from the ai's main logic.

At this point the only thing I could try would be to either port the library to SDL (which I have no idea about, except that it has a java interface.. probably) or to give up on having a debugging interface at all and use direct arrays to store threatmap data.

EDIT: nevermind, the SDL bindings for java are terrible and don't include anything remotely related to openGL. Arrays it is.
0 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Issues using OpenGL with an AI

Post by gajop » 22 Dec 2015, 17:31

aeonios wrote:Using lua is stupid.
+1
AIs should still be able to run in headless. I guess this is only for your development needs.

Your thing seems like a bug/feature request.

EDIT: I've read up on the mantis issue you made. Seems you're a bit out of luck :P
0 x

hokomoko
Spring Developer
Posts: 575
Joined: 02 Jun 2014, 00:46

Re: Issues using OpenGL with an AI

Post by hokomoko » 22 Dec 2015, 18:37

Headless runs LuaUI.
0 x

Kloot
Spring Developer
Posts: 1864
Joined: 08 Oct 2006, 16:58

Re: Issues using OpenGL with an AI

Post by Kloot » 22 Dec 2015, 19:40

Not OpenGL though (all stubbed), so relying on it+Lua for your AI's decision making would give you a nasty surprise in HL mode anyway.
0 x

User avatar
AF
AI Developer
Posts: 20667
Joined: 14 Sep 2004, 11:32

Re: Issues using OpenGL with an AI

Post by AF » 22 Dec 2015, 22:02

OpenGL is a graphics library, it shouldn't be used to perform AI logic. Visualising what's happening inside an AI is tooling, and the AI interface is ill suited to raw OpenGL work, as is rebuilding the entire lua UI toolchain in a new interface and language
Using lua is stupid. AIs don't have the rights to use lua, and I'd have to have my stupid hacked drawing gadget accepted into zk stable even though the ai isn't even part of the game right now. That also pisses me off because I just spent 3 weeks writing a stupid 2D graphics library so that I could make this work. Not to mention I'd have to take extra measures to avoid cheating and the lua gadget would be horribly disconnected from the ai's main logic.
That would be stupid, you'd write a gadget that hands stuff off into widget land, and have it do nothing but provide a method to hand off data to widgets. Having the gadget itself do the rendering would be a logistical nightmare, running your AI debugging on every single machine.. it makes no sense. Widgets are the far better approach.

Said gadget would also be useful for other purposes that are unrelated to debugging and tweaking AI performance
0 x

aeonios
Posts: 202
Joined: 03 Feb 2015, 14:27

Re: Issues using OpenGL with an AI

Post by aeonios » 23 Dec 2015, 09:26

OpenGL is a graphics library, it shouldn't be used to perform AI logic. Visualising what's happening inside an AI is tooling, and the AI interface is ill suited to raw OpenGL work, as is rebuilding the entire lua UI toolchain in a new interface and language
I'm not the first to use GPGPU and I certainly won't be the last. That said I give up on this crap. Arrays seem to be fast enough in general and actually getting GL to work without breaking spring is something I'm not going to bother doing. I've already wasted 3 weeks of my time doing things besides making my AI better and I'm sick of it.
0 x

Kloot
Spring Developer
Posts: 1864
Joined: 08 Oct 2006, 16:58

Re: Issues using OpenGL with an AI

Post by Kloot » 23 Dec 2015, 11:37

GPGPU can be done with more libs than just raw GL.

We've all wasted time on something at some point or another, get over it.
0 x

User avatar
AF
AI Developer
Posts: 20667
Joined: 14 Sep 2004, 11:32

Re: Issues using OpenGL with an AI

Post by AF » 23 Dec 2015, 12:55

Ah you're not interested in rendering things visually in the engine, you mean to use stuff like OpenCL? I see
0 x

Post Reply

Return to “AI”