先假设某处内存中存在一个字符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输入输出速度大打折扣也是很正常的。

GPU是新式显卡自带的处理器，性质类似于多了一颗CPU，两颗CPU如何协同工作，其实是要协议的，通常GPU无法抢主板CPU上的运算主导权，除非操作系统把运算调度给GPU进行，这是各种程序之间的配合问题，比较复杂的。

大牛的回复水平很高 这帖加个高亮罢

LED显示屏，其实就是显示卡的显示原理。早期的LED屏，用单片机控制灯的亮灭，屏中没有固化字库，那时只能通过串口把需要显示的字模送过去画图，后来很多都固化了字库，就只需要送内码了。

我在C坛曾发过这种使用软字库画图的例子程序，以前DOS程序就都是那样做的。本质上现在的图形化程序都是这样，只不过不再是过去的点阵字库罢了，提取字模的时候，要多一层运算，把数学描述字模转换为点阵再画出去，仍然是借助了强大的机器运算能力。在cmd窗口中，默认仍然是16点阵的字库，打开cmd窗口的属性设置就看到了。

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 计算的。驱动程序一般是 gpu 芯片的设计者负责编写的。
显卡应该是无法访问 cpu 内部数据的，也不能访问 cpu 的那三级缓存。它只能访问内存，而它访问哪部分内存，是由 cpu 发指令控制的。
很可能不是 cpu 写进去的，只是告诉 gpu 应该去哪读。当然读完了之后，gpu 会把相关的数据拷贝进自己的显存，之后就可以节约访问内存的成本了。显存成了 gpu 和 内存之间的缓存。这和 cpu 的缓存逻辑很像。
这有点像通电之后，灯泡会亮一样。只是电路复杂了很多，因此也会有更复杂的逻辑。早期的 DOS 也有 BIOS 程序参与，可以简单地把这些程序也看成电路的一部分。
不能。需要 cpu 参与。
编译器没有这么大能力。它调用系统接口了。而系统委托给驱动程序了。
有权限读硬盘我觉得还是只有 cpu，gpu 应该不能把。还是得等 cpu 先读进内存。至于 cpu 是不是能直接把硬盘数据写到显存去，我不是很了解 gpu 的架构。理论上也不是不可能，但我觉得可能不会这么设计。
图片处理程序不可能全在 gpu 中算，许多主代码还是在 cpu 这。比如处理键盘鼠标的输入事件，另存为之类的。这些交给 gpu 去干也没什么优势。
读取电影就更复杂了，因为它还涉及编码问题（其实图片也涉及，只是简单点）。为了做复杂的渲染，很多计算是移交 gpu 了。但依然应该不是全在 gpu 中算的。cpu 这边还有很多其它的逻辑要处理。

我不太专业。有关 cpu 的知识应该还是靠点谱的，提到 gpu 那块的东西，基本是我蒙的。其实我看这个帖子，也跟 TonyDeng 学了不少东西。

据说加亮了，我就多费点话。抢了 Z版 10分呢，呵呵，得贡献点。

呵呵 最近上网时间真少 今天看到这个帖子收益很大啊 楼主问的好 各位版主回答的更精彩 学到了不少东西
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这个中断啊

哦？ 也不知道为什么 书上给的例子 俺照抄的。

这个中断也许不是BIOS中断，而是操作系统设置的中断。