注册 登录
编程论坛 汇编论坛

CPU是怎么知道哪些问题要给GPU处理的

wobianlong 发布于 2012-08-14 23:28, 1520 次点击
这个问题一直困扰着,显示器上是输出是不是在显存里面的
但是最最主要的问题是,CPU怎么判定哪些程序(代码)交给GPU啊
显卡的东西到底是从内存读取的,还是从CPU里面读取的还是CPU写进显存的
先假设某处内存中存在一个字符A,具体显示到显示器的细节是怎么实现的呢
19 回复
#2
zklhp2012-08-14 23:32
对于目前的操作系统来说 这其实是由程序或者说是代码决定的

比如firefox 你开了硬件加速 那么 一部分渲染工作就由显卡来做 如果你关了 那么渲染就由CPU来做 flash也有类似的选项

再具体 所谓的给GPU 其实就是用了这些显卡的接口或开发库 也可能用的是openGL DirectX这样的通用库来做的

总结 其实 这些不是由CPU决定的 是人或者说是编程者决定的 他想怎样就怎样


[ 本帖最后由 zklhp 于 2012-8-14 23:54 编辑 ]
#3
zklhp2012-08-14 23:36
你的疑惑 可以通过学那些DOS编程知道个大概 但现在的显卡 操作系统 都比过去的复杂多了 比如你说的这个显存罢 现在一个东西要显示到屏幕上可不止有一个缓冲罢 有在内存里的缓冲 有在显存里的 很复杂 具体的硬件实现我也不知道喽 只能大概说 基本原理还类似DOS时代的写缓存。。
#4
zklhp2012-08-14 23:39
先假设某处内存中存在一个字符A,具体显示到显示器的细节是怎么实现的呢

你还举这个例子 说明你还是停留在DOS那个图像的时代 你看看你的屏幕 这么丰富的内容 可能是由ABCD这样的简单字符组成的么。。
#5
zklhp2012-08-14 23:43
如果你很好奇 建议你学以下的东西深刻认识这个问题

1 计算机组成原理
2 linux操作系统的实现 特别是X-window的相关东西
3 openGL等图形库

如果这三个都学了 你应该能回答你问的问题 为啥学linux系统呢 因为是开放的 不过事实上相应的资料很少 所以你得会钻研 英语好 会读代码。。。

如果你只是好奇 我觉得上面的已经够多的了 具体有啥不懂你再问罢 我知道的都能说
#6
pangding2012-08-16 11:49
Z版不仅知道的多,指导的还很详细。

估计他是新手,对这个问题比较感兴趣,等他真想研究底层几天以后估计就觉得知不知道也无所谓了。即使把 DOS 那个年代的实现机制全搞清楚,也不是那么容易的。
#7
wobianlong2012-08-21 09:06
谢谢版主回答了那么多,但是我还是没怎么听懂,可能是我自己的理解问题
显卡的东西是CPU写进去的吗?还是从内存读取的?
显卡能直接和内存通信吗?
就一个C语言或者汇编程序来说?找不到具体的往显存写东西的代码,莫非是编译器?
不说输出一个字符了
说说打开一张图片的过程,我自己的理解是,CPU 通过主线 从硬盘读取一张图片,然后(放进某个内存中)需要这个过程吗?还是直接输出都显卡,图片处理程序来解读图片的字符流,又或者说那个图片处理程序会在GPU中运行?
版主讲解下 具体的过程 比如读取一个电影
#8
zklhp2012-08-21 14:24
以下是引用wobianlong在2012-8-21 09:06:46的发言:

谢谢版主回答了那么多,但是我还是没怎么听懂,可能是我自己的理解问题
显卡的东西是CPU写进去的吗?还是从内存读取的?
显卡能直接和内存通信吗?
就一个C语言或者汇编程序来说?找不到具体的往显存写东西的代码,莫非是编译器?
不说输出一个字符了
说说打开一张图片的过程,我自己的理解是,CPU 通过主线 从硬盘读取一张图片,然后(放进某个内存中)需要这个过程吗?还是直接输出都显卡,图片处理程序来解读图片的字符流,又或者说那个图片处理程序会在GPU中运行?
版主讲解下 具体的过程 比如读取一个电影

显卡的东西是CPU写进去的吗?还是从内存读取的?

应该是内存到显存罢

显卡能直接和内存通信吗?

能罢

就一个C语言或者汇编程序来说?找不到具体的往显存写东西的代码,莫非是编译器?

目前的程序没有直接的代码来操作显存的了 要么是用操作系统的API 要么用openGL一类的库 要么用显卡的API 总之 基本没有直接操作的了 都隐藏了

不说输出一个字符了
说说打开一张图片的过程,我自己的理解是,CPU 通过主线 从硬盘读取一张图片,然后(放进某个内存中)需要这个过程吗?还是直接输出都显卡,图片处理程序来解读图片的字符流,又或者说那个图片处理程序会在GPU中运行?

应该是硬盘到内存再到显存 而实际中内存到显存一般是操作系统完成的 也不是简单的复制到显存这么简单罢 应该是通过相应的驱动实现的 然后由驱动完成内存到显存的复制

程序一般还是在CPU中运行的 目前绝大部分程序都是在CPU中运行的 少部分程序是由CPU和GPU共同完成运算的 完全GPU运行的程序目前很少

版主讲解下 具体的过程 比如读取一个电影

读取电影 CPU解码 画面经过接口给显卡 显卡再输出到显示器上 这是非【硬解】电影的播放过程

我上面一直在说的一个东西就是接口 对于非底层开发者 会用接口很重要 就好像printf()函数 这个函数怎么写的你不用关心 你会用就可以了 对于这种操作硬件的东西 更要通过接口 像DOS时代那种直接操作硬件目前已经很难实现了 即使是用汇编也一样 当然用接口也有很多缺点 带来一些问题 如果你有兴趣 可以根据我上面说的那些研究这个具体怎么实现的 不过 如果你不是专业搞底层开发 搞明白没意义 我都不是搞计算机的更不会搞明白了 呵呵
#9
TonyDeng2012-08-21 14:26
呵呵,我看你怎么答。
#10
zklhp2012-08-21 14:29
以下是引用TonyDeng在2012-8-21 14:26:56的发言:

呵呵,我看你怎么答。

大牛也来取笑我了。。
#11
TonyDeng2012-08-21 15:02
先假设某处内存中存在一个字符A,具体显示到显示器的细节是怎么实现的呢

显示卡的设计,是把显示内存中的数据呈现到显示器上。只要往显示内存中写入数据,显示卡硬件就负责呈现,是不需要CPU干预的。显示卡内存本身是RAM,可擦写的,可读可写,在早期的DOS时代,程序(典型如C程序)可以通过直接寻址把需要呈现的数据复制到显示卡内存处,这叫直接写屏,也即自己操纵硬件(汇编和C的特点就是方便这种操作)。但后期的保护式操作系统不再允许应用程序直接向显示卡内存赋值数据了,它把这段内存地址保护起来,所有需要向这个地址读写数据的程序,都必须向操作系统申请,有特权的才允许(亦即只放行显示卡驱动程序),所有应用程序,都必须通过中介层与驱动程序交换数据,委托驱动程序读写显示卡内存。这样间接操作的模式就是:应用程序利用驱动程序的接口读写显示卡数据,并输出。DOS也有这种间接模式,叫中断调用(BIOS中断),但那个时候的汉字系统之类外挂程序,往往是截获中断之后自己向显示卡内存读写,所以后期的天汇之类汉字系统比早期的CCDOS快得多,就是这个道理。间接调用必然是慢的,但现代计算机的硬件比以前高级得多,所以整体看起来比以前直接写屏还快,就不觉得慢了,如果现代Windows系统运行在旧式那种规模的计算机上,图形模式就无法忍受了。

所以,你的这个问题是这样:应用程序在某处内存中有一个字符A,它要显示到显示器上,应用程序通过系统提供的输入输出函数把这个字符通过参数传递给驱动程序,再由驱动程序把数据写到对应的显示卡内存处,结果就出来了。

显示卡历来有两种模式,一种是文本模式,一种是图形模式。文本模式是在显示卡的ROM中固化了文字(英文字母或汉字)的图案,只要告诉显示卡要输出的文字的编码,显示卡就自动从ROM中把字模图案调出来画到显示器上。图形模式是应用程序自己把需要输出的图案画出来,比文本模式慢得多。所以,这里你显示的A以怎样的字型和方式显示出来,是跟模式有关的。

中断,接近于直接操纵硬件(视具体中断而定),所以在现代操作系统中,用旧式的汇编写中断调用,不成功是不奇怪的,因为操作系统极可能不容许你这样做。应该改用API,那就是新式的中断模式。有容有个问题涉及的中断,其实也是这个原因。DOS下TC2.0很多输入输出函数是直接写屏的,在移植到Windows版本之后,这些输入输出函数已经被Windows截获强制改用API了(只是写程序的人自己不知道而已),某些软件再怎么模拟DOS,都不可能百分百跟DOS一样让你直接操纵硬件,此时某些代码无法执行也是很正常的,同样,Windows下的TC输入输出速度大打折扣也是很正常的。
#12
TonyDeng2012-08-21 15:07
GPU是新式显卡自带的处理器,性质类似于多了一颗CPU,两颗CPU如何协同工作,其实是要协议的,通常GPU无法抢主板CPU上的运算主导权,除非操作系统把运算调度给GPU进行,这是各种程序之间的配合问题,比较复杂的。
#13
zklhp2012-08-21 16:15
大牛的回复水平很高 这帖加个高亮罢
#14
TonyDeng2012-08-21 16:31
LED显示屏,其实就是显示卡的显示原理。早期的LED屏,用单片机控制灯的亮灭,屏中没有固化字库,那时只能通过串口把需要显示的字模送过去画图,后来很多都固化了字库,就只需要送内码了。

我在C坛曾发过这种使用软字库画图的例子程序,以前DOS程序就都是那样做的。本质上现在的图形化程序都是这样,只不过不再是过去的点阵字库罢了,提取字模的时候,要多一层运算,把数学描述字模转换为点阵再画出去,仍然是借助了强大的机器运算能力。在cmd窗口中,默认仍然是16点阵的字库,打开cmd窗口的属性设置就看到了。
#15
pangding2012-08-22 00:44
T版 讲得比较深了,楼主尽量理解就好。

我不说 gpu,我说 cpu,这样楼主可能容易领会一点:
    cpu 访问内存是个比较简单的一行为,但这个过程可能也不是像想像的这么简单。因为楼主很可能也知道,cpu 和 内存 之间一般都有三级缓存,也就是说内存其实可以看成第四级缓存。你下达读内存的指令,其实并不一定是读了内存,有可能只读了一级缓存,有可能读到了二级缓存,也有可能是真读了内存。你下令写内存,也是一样,很可能根本没真的写进内存。但总之有一点,硬件会保证最终你要的效果,我一定帮你做到,至于过程你无法控制。这是硬件的电路逻辑,可以靠软件(就是指操作系统)控制是否开启,但开启这后,连操作系统也无法更改它的逻辑行为。操作系统的最最底层需要一部分代码,实现硬件要求系统维护的数据结构,但这些代码一般只占内核代码的很少一部分。
    必须深入了解某种类型 cpu 的硬件能够提供哪些功能,以及如何开启或关闭它们。一但需要开启或者关闭,硬件又要求系统维护的相关数据结构,以及应该如何维护。这些硬件提出的接口,一般称为 cpu 的架构。比较有名的架构包括 PowerPC, ARM, SPARC, x86 之类的。还有比如早期的 PDP(unix 最早在其上实现)。我其实也只对 intel 的 x86 架构了解的相对多一点而已。由于它们的架构,下层硬件的执行逻辑就会大相径庭。难道要让程序员换个环境连基本的访问内存也做不到吗?这就需要驱动程序。这有点像反过来的,操作系统为了能在各种硬件上运行,也规定了一套接口。而驱动程序的工作是这样,用 cpu 提供的接口实现操作系统规定的接口。这样当系统调用接口,就会由驱动程序驱动硬件来完成指定的任务。换个架构的话,只需要提供另一套驱动程序即可。驱动可以由生产这种硬件的厂商编码,也可以由熟悉这种架构的第三方编码。
    总之需要在这种操作系统里编程的人,只用知道操作系统的接口即可,再底层的不是说不用学,是学了也没用。除非是想满足好奇心(比如我这样的就学了些 x86 架构的东西),或者是你要去写驱动程序。早期 MS DOS 的系统过度依赖硬件,完全没有移植性。甚至很多东西推给程序员实现,是因为那会微软刚起步,系统极为简陋原始。后来推出的早期的 windows 也一样,也只能在 intel 的架构上运行。结成了大家所谓 wintel 联盟的东西。但是现在的 windows 系统好像移植性上去了,不过我也不是很了解 windows。

    楼主可能觉得我在转移话题。是的,因为对于显示的问题,我只是稍微了解一点老 DOS 时使用的那种机制。而那种机制,现在也淘汰了。但是道理是一样的。显卡的硬件也有硬件接口,也需要驱动程序在图形库和显卡的硬件接口间建立联系,当然的联系的过程中,需要 cpu 辅助。这样写程序的人就只管调图形库就行了。如果机器没有 gpu,那么实际安装的驱动程序其实是把相关的东西翻译成了 cpu 的硬件接口,并让 cpu 去算了。如果有显卡,又有正确地安装驱动程序,那么它会覆盖掉老的驱动程序。再执行的时候,就可以调用显卡来运算了。所以用不用显卡算,不是写这个程序的人决定的,也不是写图形库的人决定的。所有人都只有一个目的,让程序能正确高效的执行。

    现在再看看楼主的问题:
CPU怎么判定哪些程序(代码)交给GPU啊
你清楚答案了吗?最终其实是驱动程序安排 cpu 把相关的内容移交 gpu 计算的。驱动程序一般是 gpu 芯片的设计者负责编写的。
显卡的东西到底是从内存读取的,还是从CPU里面读取的还是CPU写进显存的
显卡应该是无法访问 cpu 内部数据的,也不能访问 cpu 的那三级缓存。它只能访问内存,而它访问哪部分内存,是由 cpu 发指令控制的。
很可能不是 cpu 写进去的,只是告诉 gpu 应该去哪读。当然读完了之后,gpu 会把相关的数据拷贝进自己的显存,之后就可以节约访问内存的成本了。显存成了 gpu 和 内存之间的缓存。这和 cpu 的缓存逻辑很像。
先假设某处内存中存在一个字符A,具体显示到显示器的细节是怎么实现的呢
这有点像通电之后,灯泡会亮一样。只是电路复杂了很多,因此也会有更复杂的逻辑。早期的 DOS 也有 BIOS 程序参与,可以简单地把这些程序也看成电路的一部分。
显卡能直接和内存通信吗?
不能。需要 cpu 参与。
就一个C语言或者汇编程序来说?找不到具体的往显存写东西的代码,莫非是编译器?
编译器没有这么大能力。它调用系统接口了。而系统委托给驱动程序了。
说说打开一张图片的过程,我自己的理解是,CPU 通过主线 从硬盘读取一张图片,然后(放进某个内存中)需要这个过程吗?还是直接输出都显卡,图片处理程序来解读图片的字符流,又或者说那个图片处理程序会在GPU中运行?
版主讲解下 具体的过程 比如读取一个电影
有权限读硬盘我觉得还是只有 cpu,gpu 应该不能把。还是得等 cpu 先读进内存。至于 cpu 是不是能直接把硬盘数据写到显存去,我不是很了解 gpu 的架构。理论上也不是不可能,但我觉得可能不会这么设计。
图片处理程序不可能全在 gpu 中算,许多主代码还是在 cpu 这。比如处理键盘鼠标的输入事件,另存为之类的。这些交给 gpu 去干也没什么优势。
读取电影就更复杂了,因为它还涉及编码问题(其实图片也涉及,只是简单点)。为了做复杂的渲染,很多计算是移交 gpu 了。但依然应该不是全在 gpu 中算的。cpu 这边还有很多其它的逻辑要处理。

我不太专业。有关 cpu 的知识应该还是靠点谱的,提到 gpu 那块的东西,基本是我蒙的。其实我看这个帖子,也跟 TonyDeng 学了不少东西。
#16
pangding2012-08-22 00:45
据说加亮了,我就多费点话。抢了 Z版 10分呢,呵呵,得贡献点。
#17
有容就大2012-08-22 21:11
呵呵 最近上网时间真少 今天看到这个帖子收益很大啊 楼主问的好 各位版主回答的更精彩 学到了不少东西
T版还提到了我那个问题 觉得很受启发 当时学中断那一章 写一些小程序 在MASMPlus下运行常常会弹出一个
说什么遇到无效的命令
比如这个
程序代码:
assume cs:code

code segment
     start:  mov ax, 1234h
             int 7ch
             add ax, ax
             adc dx, dx
             mov ax, 4c00h
             int 21h
code ends

end start
--
只有本站会员才能查看附件,请 登录
只有本站会员才能查看附件,请 登录

#18
zklhp2012-08-22 21:38
以下是引用有容就大在2012-8-22 21:11:21的发言:

呵呵 最近上网时间真少 今天看到这个帖子收益很大啊 楼主问的好 各位版主回答的更精彩 学到了不少东西
T版还提到了我那个问题 觉得很受启发 当时学中断那一章 写一些小程序 在MASMPlus下运行常常会弹出一个
说什么遇到无效的命令
比如这个
assume cs:code
 
code segment
     start:  mov ax, 1234h
             int 7ch
             add ax, ax
             adc dx, dx
             mov ax, 4c00h
             int 21h
code ends
 
end start--

我查了查 貌似也没有7c这个中断啊
#19
有容就大2012-08-22 23:27
回复 18楼 zklhp
哦? 也不知道为什么 书上给的例子 俺照抄的。
#20
hu9jj2012-08-23 07:35
这个中断也许不是BIOS中断,而是操作系统设置的中断。
1