I would like to know, can the GPU transmit information back to memory or to the cpu?
Is there a way to trick the GPU into doing so?
Thanks
- Olumide
[This message has been edited by Olumide (edited 09-14-2003).]
Hi !
Modern GPU’s can do all kind of wonders, but the OpenGL api sets some limits on what is available, could you be more specific about what you want to do ?
For example: glReadPixels will transfer data from a framebuffer to RAM.
Mikael
Thanks Mikael
Can the GPU communicate with the CPU?
- Olumide
Originally posted by Olumide:
[b]Thanks Mikael
Can the GPU communicate with the CPU?
- Olumide[/b]
What do you mean by saying “communicate”?
ASFAIK GPU can’t just use CPU resources directly. They are indepented from each other. But in fact, CPU does communicate in some way with GPU beacuse it calculates some portions of data which then are send to GPU for a later processing. Hope it helps. 
Originally posted by Orzech:
ASFAIK GPU can’t just use CPU resources directly … CPU does communicate in some way with GPU beacuse it calculates some portions of data which then are send to GPU for a later processing. Hope it helps.
Not quite. What I will like to know is. CAN THE GPU SEND BACK INFORMATION TO THE CPU???
Thanks
- Olumide
[This message has been edited by Olumide (edited 09-15-2003).]
what kind of information you want to transfer ?
feedback and buffer reads are the only way to read back some computed data.
maybe super buffer extension will help you but it’s not yet writen.
No it cant, the GPU doesnt even know that there is a CPU.
The GPU only gets told to do something by a client (which happens to be the CPU eventhough the GPU dosent know that) and then the results >can< get retrieved by a client (which would be the CPU again).
Is that what you wanted to know?
Well, maybe Olumide should first learn to communicate with other human beings, before he wants his GPU to communicate with his CPU.
Jan.
Originally posted by Jan2000:
[b]Well, maybe Olumide should first learn to communicate with other human beings, before he wants his GPU to communicate with his CPU.
Jan.[/b]
Thanks. I Thought these groups were meant to interface those who do not know i.e. people like me (never mind the “Frequent contributor” tag) with people who know (like “Honk”).
[This message has been edited by Olumide (edited 09-15-2003).]
I think Jan is referring to the fact that you were not very specific in your question, and you never really did answer anyone’s question when asked “what information?”
You know what? I haven’t been on this forum much recently but I noticed that it was nicer some time ago. Do you have similar feelings?
I think the beginner forums are still pretty friendly. If you are talking about this thread in particular, how do you feel it’s not friendly, outside of Jan’s post, which I could see as being taken that way.
For the most part, people tried to answer your question, but also tried to get more information to you to understand what it is that you wanted exactly. Your question was pretty generalized and could have been interpretted multiple ways.
If anything your response where you said, “CAN THE GPU SEND BACK INFORMATION TO THE CPU???” could be interpretted as being somewhat hostile. Kind of like saying, “JUST ANSWER MY QUESTION, DAMMIT!” The problem is, most of us don’t know what your real question is because you wouldn’t explain further.
Originally posted by Deiussum:
… If anything your response where you said, “CAN THE GPU SEND BACK INFORMATION TO THE CPU???” could be interpretted as being somewhat hostile. Kind of like saying, “JUST ANSWER MY QUESTION, DAMMIT!” The problem is, most of us don’t know what your real question is because you wouldn’t explain further.
Oh I see. I’m sorry I did not realize restating my question in CAPS could be offensive. Someone on the Advanced forun finally answered my question (See http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/010429.html)) Interrupts can be used to send information from any device (GPU included) to the CPU. However, because such bi-diectional communication is probably not written into current (graphics card) drivers, a new there will be the need to write a new device driver to perform this sort of thing.
- Olumide
I am friendly as long as someone asks a question in a friendly way AND shows that he trys to solve his own problem. Clearly that was not the point in this case, or else Olumide would not have posted “Can the GPU communicate with the CPU?” (his second post) or “What I will like to know is. CAN THE GPU SEND BACK INFORMATION TO THE CPU???” (his third post).
If he was really interessted in solving his problem, he would have tried to explain what he really means with “communicate”.
In general it´s ok to ask a question wrong or without enough details, as long as one shows respect for others, who try to help, by answering THEIR questions.
With my post i only wanted to remind him, that this is a forum where people help each other FOR FREE (and in their spare-time). He should not take their help for granted.
If you now think i am a hostile, unfriendly and selfish idiot, take a look at other threads, were i try to help others as good as i can.
Jan.
Yes the GPU can trigger an interrupt but thats nothing I would call “communication” is more “raising a flag to seek attention”, no data is beeing passed its really just a “somebody check my status” signal.
Since this all happens deep inside the driver at RING0 (privileged execution level) a discussion if that can be used as a “communication link” is a complete mood point since its out of your reach anyway.
Originally posted by Honk:
[b]Yes the GPU can trigger an interrupt but thats nothing I would call “communication” is more “raising a flag to seek attention”, no data is beeing passed its really just a “somebody check my status” signal.
Since this all happens deep inside the driver at RING0 (privileged execution level) a discussion if that can be used as a “communication link” is a complete mood point since its out of your reach anyway.[/b]
I know this is a priviledged instruction and system calls are no avaliable to affect it, but wouldnt this bi-directional communication be possible if someone wrote a new device driver? (Such a driver could pass back extra information to the CPU.)
- Olumide
we still doesnt know what you want… a callback for each vertex/pixel would surely make the operations slower than doint it all on the cpu, you want to do batches, and if you really need the result back at some moment, a glflush wouldn ensure that you have the result on the next codeline, or you could make use of nvidias glFence to ask if its done, else continue with the cpu task and ask again a bit later.
the gpu works on batches so getting the result from one operation wont do any good. With floatingpoint buffers that are accessable from the CPU ( i guess that superbuffers adresses that) you can get the whole batchs result in one read and then you can gain from the GPU speed.
Originally posted by Olumide:
[b]
I know this is a priviledged instruction and system calls are no avaliable to affect it, but wouldnt this bi-directional communication be possible if someone wrote a new device driver? (Such a driver could pass back extra information to the CPU.)
- Olumide[/b]
Write a device driver to do what?
Hook into which IRQ (before or after) the original driver served the IRQ?
And then read:
-Which information out of
-Which registers/mmio’s?
Or do you want the “new” device driver to replace the original driver (good luck with that…)
Let alone that the GPU only triggers an IRQ at certain >fixed< situations (vsync for example) so you cant program the GPU to trigger an IRQ on demand.
No, no way dude! Just drop that idea.
In case you want to perform some scientific calculations on the GPU check this out:
http://www.google.com/search?q=GPU+scientific+calculation
What they basicly do (in a simplified version): They obuse textures to feed their data to the gpu and then “render” thoose to floating point buffers using fragment shaders (which perform the “scientific calculation”) and then read the result back.
However this only works for certain calculations and is not an option for a general purpose solution (i.e. you cant branch).
If you need a “one-size-fits-all” solution you are out of luck.
Until you care to explain what >exactly< you are trying to do, I refuse to waste anymore time on this.
The entire execution can never leave control of the CPU. Please don’t visualize that the GPU is a complete processing unit. Seen from the hardware point of view, it is just like u’r NIC card or sound card. If a communication is required the GPU raises an IRQ and the OS switches the execution context to the device driver code. Next what happens depends upon the way the driver is coded. The driver can simply acknowledge the IRQ and all data that the GPU wanted to communicate can be lost.
(ps: But this dosen’t happen, does it? )
Originally posted by Olumide:
[b] Oh I see. I’m sorry I did not realize restating my question in CAPS could be offensive. Someone on the Advanced forun finally answered my question (See http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/010429.html)) Interrupts can be used to send information from any device (GPU included) to the CPU. However, because such bi-diectional communication is probably not written into current (graphics card) drivers, a new there will be the need to write a new device driver to perform this sort of thing.
- Olumide
[/b]
In case you didn’t know, all caps is generally used to denote shouting. Shouting the exact same question you asked before implys exhasperation. Not answering anyone else’s follow-up questions, but getting exhasperated that your own isn’t getting answered to your satisfaction is rude, to say the least.