I run Opengl at the lowest level. No libraries. I have to figure everything out
for myself. Can one of you pro's tell me what this quote from the Khronos
group means. I think it would help me. "Applications are responsible for
providing the synchronization across API calls when objects are accessed
from different execution threads." I think this would help me get things
working. Thanks much, Kiptron
You can use threads for generate multiple objects on the screen.
Each thread use data who can be shared between all threads.
It is here there is a problem of synchronisation,a thread could have need of a particular data during a certain time.
If another thread change this data,You could have unpredictable results on the screen.
Thank you for responding Tou. So how do I do this synchronization ?
Thanks Kiptron
There are quite a number of methods. When you launch a thread, it is kind of a separate program that acts without caring for the main program. One simple method is to let the thread do its work, and before it returns (i.e. it finishes), the thread sends a message to the main program.
MyDownloadThread proc
....
invoke SendMessage, hMainWindow, WM_READY, 123, 456
ret
MyDownloadThread endp
WndProc ...
.if uMsg==WM_READY
print "thread has ended", 13, 10
.endif
Thanks for getting back to me JJ. I am trying to understand what you posted. In my
case the called thread is an API call inside of the graphics driver so I can't get inside
it to modify the code to issue a sendmessage prior to the return, so I don't really
understand what you are referring to. Do I issue a sendmessage prior to calling
the API function ? When calling an API function(proc) is that a different thread than
my own normal masm project code ? Stay well over there. The last time we spoke
was in February and Covid was running wild back then. De Ja Vu all over again.! Kiptron
Good to see you folks. :biggrin:
Once you have a handle on what my friend, Jochen, mentioned,
you will find there are two important concepts to grasp to write threaded code:
1) Thread Lock may occur, where one thread endlessly waits for the other to respond
2) Bus Lock is a hardware condition that allows two threads to communicate without simultaneous interference
Ignore the fact that both terms use the word, "Lock".
Totally unrelated - lol
We don't have to teach you about thread lock.
The first time you write locked code and debug it, you will avoid it by yourself. :badgrin:
Bus Lock is different, we use specific instructions and/or functions to communicate between threads.
Personally, I find the XOR instruction easy.
When used between a register and a memory location,
the bus is naturally locked to prevent interference from another thread.
Holy Moly - Jochen has 2,000 more posts than me !!! :sad:
You guys lost me. You mean something like xor qword ptr[rbx], rax ? That is a normal instruction
that will zero any common bits in source and destination. Usual stuff. It will not lock any buss that I
know of. At what point do you run this instruction ? I'm just trying to get API calls to run properly.
Thanks again Kiptron
Quote from: kiptron on October 30, 2020, 12:29:32 PMIn my
case the called thread is an API call inside of the graphics driver so I can't get inside
it to modify the code to issue a sendmessage prior to the return
Can you show us the piece of code where you do that? Just the CreateThread part.
Have you looked at WaitForSingleObject (https://docs.microsoft.com/en-us/windows/win32/sync/using-event-objects) already?
@DednDave: Welcome back, my friend - it's time to catch up :biggrin: :thup:
Hello dedndave,happy to see you again !
Hi kiptron,
Maybe you can make use of this: "Critical Section Objects"
The critical section of a piece of code is a place where only one thread of execution is allowed to be at a time, to prevent things like race conditions.
https://docs.microsoft.com/en-us/windows/win32/sync/critical-section-objects
Hi Dave, where have you been for so long? :thumbsup:
Hi guys, I have not been clear I guess. I have one simple question which needs a yes
or no answer. All of us make API calls all the time. These calls usually go into some dll
somewhere in system memory. I will call that the "called code". Our little masm app. is
the "calling code". Right ? A no-brainer so far. Is that "called code" a different execution
thread than our masm code which called it.? If not, then my little app is only one thread
and there is no other thread involved and this is not the issue causing instability and
protection faults. Thanks Kiptron
You don't need to worry about system API functions, they reside in memory and are callable without having to bother about if they are threaded or not. If you have not started any new threads apart from your main app, then threading considerations are not needed.
Thank you Hutch, Very clear and simple. Does this apply to an API like Opengl
as well ? I obtain address pointers to the modern calls which are not included in
the original 1991 release of Opengl. Usually programmers rely on higher level
libraries to obtain these addresses but I do it all manually. Stubborn I guess Kiptron
Appreciate that I do very little graphics work apart from images so I am not the right person to ask about the guts of OpenGL but if it is a DLL that gets loaded into memory and has callable functions, its no different to any other DLL that does the same. I don't know what OS version you are using but the assumptions of long ago can come back and bite you when the inner workings of the OS have changed and all you can ever rely on is the published interface for the function you are calling.
Hi kiptron,
Hutch is right, OpenGL calls are not threads. You call the API, and your program sits there and waits until the API has done the job. That's also called synchronous.
In contrast, when you open a thread with CreateThread, it is like a separate program that acts independently of your main program. A nanosecond after the invoke CreateThread, your program continues. The "other" program, in the meantime, may have a lot to do, like downloading some megabytes from the web. This is what threads are good for: doing heavy tasks in the background while the main program continues undisturbed.
Thanks JJ and Hutch Yes, all these issues started after I switched to Win 10 64.
Back in the 32 bit days, things ran fine. Same extensions, same code, no sweat.
As I mentioned to Hutch a while back, the hardware vendors are stopping support
for Opengl in favor of Vulkan, so their driver writers are focusing their time on that
I am sure. I found the learning curve of Vulkan to be insanely complex. I could not
make heads or tails out of it. Thanks guys Kiptron
QuoteI found the learning curve of Vulkan to be insanely complex
Hi,
kiptron!
For write Vulkan-programs need a special video card? Can I use a standard VGA-adapter built into the motherboard? Where can I find Vulkan-programming examples or tutorials? Is it possible to rewrite the NeHe lessons and the redbook for openGL for Vulkan programming?
What I would be inclined to do instead of making direct hardware calls is to start testing the actual libraries to see if that gives you more reliable performance. Even when the OS has made changes, the libraries generally access the correct addresses and this may give you a bit more life with OpenGL.
Hi Mikl, From what I have learned, the Khronos group has taken over the maintenence
and documentation of Vulkan. Any modern computer has the drivers for it depending on
the manufacturer of the graphics chips. It should not matter if it is motherboard hardware
or an add on card. Vulkan works nothing like Opengl. The configuration and initialization
made my head spin. There are probably libraries to do these chores for you. I know very
little about it. If you can understand it, set up a demo and share it with us. As I mentioned,
it is the graphics API of the future. As you may have noticed, I posted a simple Opengl demo
a while back. It worked for maybe half the members who tried it. That demo used only the
old original API. For the cool modern functions like custom shaders, texturing, arrays for
high speed rendering for animation and games you need the extensions. Opengl has it's
own compiler and linker for shader creation. GLSL is the C like shader language. It's all
going away apparently. Running these modern extensions is what is giving me trouble
and causing instability and protection faults. I think this is because my AMD drivers have
mistakes and errors because they have given up on Opengl. Very sad for us old programmers. Kiptron
rendering you need to request the pointers for these calls.