Multithreading / SetData(......

[HierGibtEsDrachen]

in version 1.12. bekomme ich eine exception (manchmal) wenn ich aus einem separaten Thread versuche Vertex- und IndexBuffer anzulegen.

{"Die Objektsynchronisationsmethode wurde von einem nicht synchronisierten Codeblock aufgerufen."} | System.Threading.SynchronizationLockException

bei engenious.Helper.Execute.UiExecutor.Dispose()
bei engenious.Graphics.IndexBuffer.SetData[T](T[] data, Int32 startIndex, Int32 elementCount)
...

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

in version 1.38 bekomme ich

{"No context is current in the calling thread (ThreadId: 6)."} | OpenTK.Graphics.GraphicsContextMissingException,

diese kommt aber nicht bei 1.12

bei OpenTK.Graphics.OpenGL.ErrorHelper..ctor(IGraphicsContext context)
bei OpenTK.Graphics.OpenGL.GL.GenBuffer()
bei engenious.Graphics.VertexBuffer..ctor(GraphicsDevice graphicsDevice, VertexDeclaration
vertexDeclaration, Int32 vertexCount, BufferUsageHint usage)
...

der relevante teil des stacktrace, der rest ist eigener code.

[jvbsl]

Ist das in Octo oder nicht? Weil wenn nicht in Octo, dann ist gerade dein Code entscheidend. Außerdem auch was für ne GPU du hast(und bei mehreren auf welcher gerendert wird)

[HierGibtEsDrachen]

hmm, die threads laufen auf der cpu, oder hab ich grad was falsch verstanden?
das ist nicht octo, aber ist von der terrain generierung ähnlich.
(ein richtig smoothes voxel terrain ist mir zu hardcore)

ist nur eine Graphikkarte
amd e1-1500 apu with radeom (tm) hd graphics 1.48 GHz
Windows 10 / 64 bit

[jvbsl]

GRRR immer diese AMD grafikkarten, hab ich halt leider auch keine parat und für die hab ich tatsächlich eine Änderung vorgenommen was threadsynchronisation anbelangt. Jedoch nicht mit dem UiExecutor und die Fehlermeldung weist darauf hin, dass sich die Instanz des lock-objekts geändert haben könnte?!
Jedoch könnte das nur ThreadingHelper.Context sein, die Variable ändert sich aber nur beim start. Ohje das wird nen blöder bug -.-

[HierGibtEsDrachen]

hmm ja sorry das sind so gesehen zwei issues für zwei verschiedene versionen halt :/
ist glaub ich ein bisschen verwirrend.
No context is current in the calling thread
könnte sein, aber das läuft eine weile und schmiert dann ab, jap das ist ein geiler bug :P

[jvbsl]

die sehen beide nach sehr wenig Spaß aus. Da wäre es fast am besten, wenn du mir ne möglichkeit geben würdest über AnyDesk oder TeamViewer mit engenious rumzuspielen.

Aber meine Vermutung liegt für beide im ThreadingHelper, wobei das nach einer weile auftreten mich doch sehr verwirrt^^

Naja aber für heute bin ich erst mal raus^^