AngleArc 用一个连接弧画一条线
Arc 画一个圆弧
BeginPath 启动一个路径分支
CancelDC 取消另一个线程里的长时间绘图 *** 作
Chord 画一个弦
CloseEnhMetaFile 关闭指定的增强型图元文件设备场景,并将新建的图元文件返回一个句柄
CloseFigure 描绘到一个路径时,关闭当前打开的图形
CloseMetaFile 关闭指定的图元文件设备场景,并向新建的图元文件返回一个句柄
CopyEnhMetaFile 制作指定增强型图元文件的一个副本(拷贝)
CopyMetaFile 制作指定(标准)图元文件的一个副本
CreateBrushIndirect 在一个LOGBRUSH数据结构的基础上创建一个刷子
CreateDIBPatternBrush 用一幅与设备无关的位图创建一个刷子,以便指定刷子样式(图案)
CreateEnhMetaFile 创建一个增强型的图元文件设备场景
CreateHatchBrush 创建带有阴影图案的一个刷子
CreateMetaFile 创建一个图元文件设备场景
CreatePatternBrush 用指定了刷子图案的一幅位图创建一个刷子
CreatePen 用指定的样式、宽度和颜色创建一个画笔
CreatePenIndirect 根据指定的LOGPEN结构创建一个画笔
CreateSolidBrush 用纯色创建一个刷子
DeleteEnhMetaFile 删除指定的增强型图元文件
DeleteMetaFile 删除指定的图元文件
DeleteObject 删除GDI对象,对象使用的所有系统资源都会被释放
DrawEdge 用指定的样式描绘一个矩形的边框
DrawEscape 换码(Escape)函数将数据直接发至显示设备驱动程序
DrawFocusRect 画一个焦点矩形
DrawFrameControl 描绘一个标准控件
DrawState 为一幅图象或绘图 *** 作应用各式各样的效果
Ellipse 描绘一个椭圆,由指定的矩形围绕
EndPath 停止定义一个路径
EnumEnhMetaFile 针对一个增强型图元文件,列举其中单独的图元文件记录
EnumMetaFile 为一个标准的windows图元文件枚举单独的图元文件记录
EnumObjects 枚举可随同指定设备场景使用的画笔和刷子
ExtCreatePen 创建一个扩展画笔(装饰或几何)
ExtFloodFill 在指定的设备场景里,用当前选择的刷子填充一个区域
FillPath 关闭路径中任何打开的图形,并用当前刷子填充
FillRect 用指定的刷子填充一个矩形
FlattenPath 将一个路径中的所有曲线都转换成线段
FloodFill 用当前选定的刷子在指定的设备场景中填充一个区域
FrameRect 用指定的刷子围绕一个矩形画一个边框
GdiComment 为指定的增强型图元文件设备场景添加一条注释信息
GdiFlush 执行任何未决的绘图 *** 作
GdiGetBatchLimit 判断有多少个GDI绘图命令位于队列中
GdiSetBatchLimit 指定有多少个GDI绘图命令能够进入队列
GetArcDirection 画圆弧的时候,判断当前采用的绘图方向
GetBkColor 取得指定设备场景当前的背景颜色
GetBkMode 针对指定的设备场景,取得当前的背景填充模式
GetBrushOrgEx 判断指定设备场景中当前选定刷子起点
GetCurrentObject 获得指定类型的当前选定对象
GetCurrentPositionEx 在指定的设备场景中取得当前的画笔位置
GetEnhMetaFile 取得磁盘文件中包含的一个增强型图元文件的图元文件句柄
GetEnhMetaFileBits 将指定的增强型图元文件复制到一个内存缓冲区里
GetEnhMetaFileDescription 返回对一个增强型图元文件的说明
GetEnhMetaFileHeader 取得增强型图元文件的图元文件头
GetEnhMetaFilePaletteEntries 取得增强型图元文件的全部或部分调色板
GetMetaFile 取得包含在一个磁盘文件中的图元文件的图元文件句柄
GetMetaFileBitsEx 将指定的图元文件复制到一个内存缓冲区
GetMiterLimit 取得设备场景的斜率限制(Miter)设置
GetNearestColor 根据设备的显示能力,取得与指定颜色最接近的一种纯色
GetObjectAPI 取得对指定对象进行说明的一个结构
GetObjectType 判断由指定句柄引用的GDI对象的类型
GetPath 取得对当前路径进行定义的一系列数据
GetPixel 在指定的设备场景中取得一个像素的RGB值
GetPolyFillMode 针对指定的设备场景,获得多边形填充模式
GetROP2 针对指定的设备场景,取得当前的绘图模式
GetStockObject 取得一个固有对象(Stock)
GetSysColorBrush 为任何一种标准系统颜色取得一个刷子
GetWinMetaFileBits 通过在一个缓冲区中填充用于标准图元文件的数据,将一个增强型图元文件转换成标准windows图元文件
InvertRect 通过反转每个像素的值,从而反转一个设备场景中指定的矩形
LineDDA 枚举指定线段中的所有点
LineTo 用当前画笔画一条线,从当前位置连到一个指定的点
MoveToEx 为指定的设备场景指定一个新的当前画笔位置
PaintDesk 在指定的设备场景中描绘桌面墙纸图案
PathToRegion 将当前选定的路径转换到一个区域里
Pie 画一个饼图
PlayEnhMetaFile 在指定的设备场景中画一个增强型图元文件
PlayEnhMetaFileRecord 回放单独一条增强型图元文件记录
PlayMetaFile 在指定的设备场景中回放一个图元文件
PlayMetaFileRecord 回放来自图元文件的单条记录
PolyBezier 描绘一条或多条贝塞尔(Bezier)曲线
PolyDraw 描绘一条复杂的曲线,由线段及贝塞尔曲线组成
Polygon 描绘一个多边形
Polyline 用当前画笔描绘一系列线段
PolyPolygon 用当前选定画笔描绘两个或多个多边形
PolyPolyline 用当前选定画笔描绘两个或多个多边形
Rectangle 用当前选定的画笔描绘矩形,并用当前选定的刷子填充
RoundRect 用当前选定的画笔画一个圆角矩形,并用当前选定的刷子在其中填充
SelectClipPath 将设备场景当前的路径合并到剪切区域里
SelectObject 为当前设备场景选择图形对象
SetArcDirection 设置圆弧的描绘方向
SetBkColor 为指定的设备场景设置背景颜色
SetBkMode 指定阴影刷子、虚线画笔以及字符中的空隙的填充方式
SetBrushOrgEx 为指定的设备场景设置当前选定刷子的起点
SetEnhMetaFileBits 用指定内存缓冲区内包含的数据创建一个增强型图元文件
SetMetaFileBitsEx 用包含在指定内存缓冲区内的数据结构创建一个图元文件
SetMiterLimit 设置设备场景当前的斜率限制
SetPixel 在指定的设备场景中设置一个像素的RGB值
SetPixelV 在指定的设备场景中设置一个像素的RGB值
SetPolyFillMode 设置多边形的填充模式
SetROP2 设置指定设备场景的绘图模式。与vb的DrawMode属性完全一致
SetWinMetaFileBits 将一个标准Windows图元文件转换成增强型图元文件
StrokeAndFillPath 针对指定的设备场景,关闭路径上打开的所有区域
StrokePath 用当前画笔描绘一个路径的轮廓。打开的图形不会被这个函数关闭
UnrealizeObject 将一个刷子对象选入设备场景之前,如刷子的起点准备用SetBrushOrgEx修改,则必须先调用本函数
WidenPath 根据选定画笔的宽度,重新定义当前选定的路径
-
-然后要吐槽下st官方的ide。真的。用得我极度不爽。所以后来转战iar。结果发现iar没法批量生产-
-因为iar少程序貌似一定要在工程下。不能直接将hex文件烧写进板子里。所以最后还是要用stvp来批量烧。
首先要准备好你的烧写文件。hex或者s19。文件。(用iar或者stvd生成的,前提必须保证你程序没问题-
-这个肯定不用说)。
第一步:然后打开stvp
。打开之后是这样的
第二步:点击option
byte
。rop
on。这个是每次烧写完将flash锁住。以免别人读你的ic。
还有如果你晶振是24m的。waitstate
要打开。然后点file->save。然后保存。切记这个保存的是optioin
byte!!如果你时钟是24m。或者程序要加锁。一定要生成这个hex文件。
目录:
第一章:第二代及以后的GPU工作流程简介
第二章:DirectX8和DirectX9 GPU的传统流水线
第三章:顶点和像素 *** 作指令
第四章:传统GPU指令的执行
第五章:统一渲染架构
第六章:G80和R600的统一渲染架构实现
第七章:G80与R600效能对比
第八章:尴尬的中端--Geforce8600简析
前面4章 我将先简要介绍下DirectX8/9显卡的核心----图形处理单元GPU的工作流程和指令处理情况
从第5章开始讨论统一渲染架构、新一代DirectX10 GPU的特性,G80/Geforce8800与R600/RadeonHD2900XT的架构具体实现及其区别。最后将会对中端最受关注的Geforce8600进行相应的简单分析。
第一章:第二代及以后的GPU工作流程简介
简单(而不一定绝对科学)的说:GPU主要完成对3D图形的处理--图形的生成渲染。
GPU的图形(处理)流水线完成如下的工作:(并不一定是按照如下顺序)
顶点处理:这阶段GPU读取描述3D图形外观的顶点数据并根据顶点数据确定3D图形的形状及位置关系,建立起3D图形的骨架。在支持DX8和DX9规格的GPU中,这些工作由硬件实现的Vertex Shader(定点着色器)完成。
光栅化计算:显示器实际显示的图像是由像素组成的,我们需要将上面生成的图形上的点和线通过一定的算法转换到相应的像素点。把一个矢量图形转换为一系列像素点的过程就称为光栅化。例如,一条数学表示的斜线段,最终被转化成阶梯状的连续像素点。
纹理帖图:顶点单元生成的多边形只构成了3D物体的轮廓,而纹理映射(texture mapping)工作完成对多变形表面的帖图,通俗的说,就是将多边形的表面贴上相应的,从而生成“真实”的图形。TMU(Texture mapping unit)即是用来完成此项工作。
像素处理:这阶段(在对每个像素进行光栅化处理期间)GPU完成对像素的计算和处理,从而确定每个像素的最终属性。在支持DX8和DX9规格的GPU中,这些工作由硬件实现的Pixel Shader(像素着色器)完成。
最终输出:由ROP(光栅化引擎)最终完成像素的输出,1帧渲染完毕后,被送到显存帧缓冲区。
总结:GPU的工作通俗的来说就是完成3D图形的生成,将图形映射到相应的像素点上,对每个像素进行计算确定最终颜色并完成输出。
第二章:DirectX8和DirectX9 GPU的传统流水线
前面的工作流程其实已经说明了问题。本章来总结一下,承前启后。
传统的GPU功能部件我们不妨将其分为顶点单元和像素流水线两部分。
顶点单元由数个硬件实现的Vertex Shader组成。
传统的像素流水线由几组PSU(Pixel Shader Unit)+TMU+ROP组成。
于是,传统的GPU由顶点单元生成多边形,并由像素流水线负责像素渲染和输出。
对于像素流水线需要做的说明是:虽然传统的流水线被认为=1PSU+1TMU+1ROP,但这个比例不是恒定的,例如在RadeonX1000(不包括X1800)系列中被广为称道的3:1黄金架构,PSU:TMU:ROP的数量为3:1:1。一块典型的X1900显卡具有48个PSU,16个TMU和16个ROP。之所以采用这种设计方法,主要考虑到在当今的游戏中,像素指令数要远远大于纹理指令的数量。ATI凭借这个优秀的架构,成功击败了Geforce7,在DX9后期取得了3D效能上的领先。
总结:传统的GPU由顶点单元生成多边形,像素流水线渲染像素并输出,一条像素流水线包含PSU,TMU,和ROP(有的资料中不包含ROP),比例通常为1:1:1,但不固定。
第三章:顶点和像素 *** 作指令
GPU通过执行相应的指令来完成对顶点和像素的 *** 作。
熟悉OpenGL或Direct3D编程的人应该知道,像素通常使用RGB三原色和alpha值共4个通道(属性)来描述。而对于顶点,也通常使用XYZ和W 4个通道(属性)来描述。因而,通常执行一条顶点和像素指令需要完成4次计算,我们这里成这种指令为4D矢量指令(4维)。当然,并不是所有的指令都是4D指令,在实际处理中,还会出现大量的1D标量指令以及2D,3D指令。
总结:由于定点和像素通常用4元组表示属性,因而顶点和像素 *** 作通常是4D矢量 *** 作,但也存在标量 *** 作。
第四章:传统GPU指令的执行
传统的GPU基于SIMD的架构。SIMD即Single Instruction Multiple Data,单指令多数据。
其实这很好理解,传统的VS和PS中的ALU(算术逻辑单元,通常每个VS或PS中都会有一个ALU,但这不是一定的,例如G70和R5XX有两个)都能够在一个周期内(即同时)完成对矢量4个通道的运算。比如执行一条4D指令,PS或VS中的ALU对指令对应定点和像素的4个属性数据都进行了相应的计算。这便是SIMD的由来。这种ALU我们暂且称它为4D ALU。
需要注意的是,4D SIMD架构虽然很适合处理4D指令,但遇到1D指令的时候效率便会降为原来的1/4。此时ALU 3/4的资源都被闲置。为了提高PS VS执行1D 2D 3D指令时的资源利用率,DirectX9时代的GPU通常采用1D+3D或2D+2D ALU。这便是Co-issue技术。这种ALU对4D指令的计算时仍然效能与传统的ALU相同,但当遇到1D 2D 3D指令时效率则会高不少,例如如下指令:
ADD R0xyz , R0,R1 //此指令是将R0,R1矢量的x,y,z值相加 结果赋值给R0
ADD R3x , R2,R3 //此指令是将R2 R3矢量的w值相加 结果赋值给R3
对于传统的4D ALU,显然需要两个周期才能完成,第一个周期ALU利用率75% ,第二个周期利用率25%。而对于1D+3D的ALU,这两条指令可以融合为一条4D指令,因而只需要一个周期便可以完成,ALU利用率100%。
但当然,即使采用co-issue,ALU利用率也不可能总达到100%,这涉及到指令并行的相关性等问题,而且,更直观的,上述两条指令显然不能被2D+2D ALU一周期完成,而且同样,两条2D指令也不能被1D+3D ALU一周期完成。传统GPU在对非4D指令的处理显然不是很灵活。
总结:传统的GPU中定点和像素处理分别由VS和PS来完成,每个VS PS单元中通常有一个4D ALU,可以在一个周期完成4D矢量 *** 作,但这种ALU对1D 2D 3D *** 作效率低下,为了弥补,DX9显卡中ALU常被设置为1D+3D 2D+2D等形式。
第五章:统一渲染架构
相对于DirectX 9来说,最新的DirectX 10最大的改进在于提出了统一渲染架构,即Unified Shader。
传统的显卡GPU一直采用分离式架构,顶点处理和像素处理分别由Vertex Shader和Pixel Shader来完成,于是,当GPU核心设计完成时,PS和VS的数量便确定下来了。但是不同的游戏对于两者处理量需求是不同的,这种固定比例的PS VS设计显然不够灵活,为了解决这个问题,DirectX10规范中提出了了统一渲染架构。
不论是顶点数据还是像素数据,他们在计算上都有很多共同点,例如通常情况下,他们都是4D矢量,而且在ALU中的计算都是没有分别的浮点运算。这些为统一渲染的实现提供了可能。
在统一渲染架构中,PS单元和VS单元都被通用的US单元所取代,nVidia的实现中称其为streaming processer,即流处理器,这种US单元既可以处理顶点数据,又可以处理像素数据,因而GPU可以根据实际处理需求进行灵活的分配,这样便有效避免了传统分离式架构中VS和PS工作量不均的情况。
总结:统一渲染架构使用US(通常为SP)单元取代了传统的固定数目的VS和PS单元,US既可以完成顶点 *** 作,又可以完成像素 *** 作,因而可以根据游戏需要灵活分配,从而提高了资源利用率。
第六章:G80和R600的统一渲染架构实现
以下我们着重讨论G80和R600的统一着色单元而不考虑纹理单元,ROP等因素。
G80 GPU中安排了16组共128个统一标量着色器,被叫做stream processors,后面我们将其简称为SP。每个SP都包含有一个全功能的1D ALU。该ALU可以在一周期内完成乘加 *** 作(MADD)。
也许有人已经注意到了,在前面传统GPU中VS和PS的ALU都是4D的,但在这里,每个SP中的ALU都是1D标量ALU。没错,这就是很多资料中提及的MIMD(多指令多数据)架构,G80走的是彻底的标量化路线,将ALU拆分为了最基本的1D 标量ALU,并实现了128个1D标量SP,于是,传统GPU中一个周期完成的4D矢量 *** 作,在这种标量SP中需4个周期才能完成,或者说,1个4D *** 作需要4个SP并行处理完成。
这种实现的最大好处是灵活,不论是1D,2D,3D,4D指令,G80得便宜其全部将其拆成1D指令来处理。指令其实与矢量运算拆分一样。
例如一个4D矢量指令 ADD R0xyzw , R0,R1 R0与R1矢量相加,结果赋R0
G80的编译器会将其拆分为4个1D标量运算指令并将其分派给4个SP:
ADD R0x , R0,R1
ADD R0y , R0,R1
ADD R0z , R0,R1
ADD R0w, R0,R1
综上:G80的架构可以用128X1D来描述。
R600的实现方式则与G80有很大的不同,它仍然采用SIMD架构。
在R600的核心里,共设计了4组共64个流处理器,但每个处理器中拥有1个5D ALU,其实更加准确地说,应该是5个1D ALU。因为每个流处理器中的ALU可以任意以1+1+1+1+1或1+4或2+3等方式搭配(以往的GPU往往只能是1D+3D或2D+2D)。ATI将这些ALU称作streaming processing unit,因而,ATI宣称R600拥有320个SPU。
我们考虑R600的每个流处理器,它每个周期只能执行一条指令,但是流处理器中却拥有5个1D ALU。ATI为了提高ALU利用率,采用了VLIW体系(Very Large Instruction Word)设计。将多个短指令合并成为一组长的指令交给流处理器去执行。例如,R600可以5条1D指令合并为一组5DVLIW指令。
对于下述指令:
ADD R0xyz , R0,R1 //3D
ADD R4x , R4,R5 //1D
ADD R2x , R2,R3 //1D
R600也可以将其集成为一条VLIW指令在一个周期完成。
综上:R600的架构可以用64X5D的方式来描述。
总结:G80将 *** 作彻底标量化,内置128个1D标量SP,每个SP中有一个1D ALU,每周期处理一个1D *** 作,对于4D矢量 *** 作,则将其拆分为4个1D标量 *** 作。
R600仍采用SIMD架构,拥有64个SP,每个SP中有5个1D ALU,因而通常声称R600有320个PSU,
每个SP只能处理一条指令,ATI采用VLIW体系将短指令集成为长的VLIW指令来提高资源利用率,例如5条1D标量指令可以被集成为一条VLIW指令送入SP中在一个周期完成。
第七章:G80与R600效能对比
从前一章的讨论可以看出,R600的ALU规模64X5D=320明显比G80的128X1D=128要大,但是为何在实际的测试中,基于R600的RadeonHD2900XT并没有取得对G80/Geforce8800GTX的性能优势?本章将试图从两者流处理器设计差别上来寻找答案,对于纹理单元,ROP,显存带宽则不做重点讨论。事实上,R600的显存带宽也要大于G80。
我们将从频率和执行效能两个方面来说明问题:
1、频率:G80只拥有128个1D流处理器,在规模上处于绝对劣势,于是nVidia采用了shader频率与核心频率异步的方式来提高性能。Geforce8800GTX虽然核心频率只有575MHZ,但shader频率却高达1375MHZ,即SP工作频率为核心频率的两倍以上,而R600则相对保守地采用了shader和核心同步的方式,在RadeonHD2900XT中,两者均为740MHZ。这样一来,G80的shader频率几乎是R600的两倍,于是就相当于同频率下G80的SP数加倍达到256个,与R600的320个接近了很多。在处理乘加(MADD)指令的时候,740MHZ的R600的理论峰值浮点运算速度为:740MHZ6452=4736GFLOPS 而shader频率为1350MHZ的G80的浮点运算速度为:1350MHZ12812=3456GFLOPS,两者的差距并不像SP规模差距那么大。
2、执行效能:G80虽说shader频率很高,但由于数量差距悬殊,即使异步也无法补回理论运算速率的差距。于是,要寻找答案,还要从两者流处理器的具体设计着手。
在G80中,每个矢量 *** 作都会被拆分为1D标量 *** 作来分配给不同的SP来处理,如果不考虑指令并行性等问题,G80在任何时刻,所有SP都是充分利用的。而R600则没这么幸运,因为每个流处理器只能同时处理一条指令,因而R600要将短指令合并为能充分利用SP内5DALU运算资源的VLIW指令,但是这种合并并不是总能成功。目前没有资料表明R600可以将指令拆开重组,也就是说,R600不能每时每刻都找到合适的指令拼接为5D指令来满载他的5D SP,这样的话我们假设处理纯4D指令的情况,不能拆分重组的话,R600每个SP只能处理一条4D指令,利用率80%,而对于G80,将指令拆开成1D *** 作,无论何时都能100%利用。而且,R600的结构对编译器的要求很高,编译器必须尽可能寻找Shader指令中的并行性,并将其拼接为合适的长指令,而G80则只需简单拆分即可。
另外还需要说明的一点是,R600中每个SP的5个1D ALU并不是全功能的,据相关资料,每组5个ALU中,只有一个能执行函数运算,浮点运算和Multipy运算,但不能进行ADD运算,其余的4各职能执行MADD运算。而G80的每个1D ALU是全功能的,这一点也在一定程度上影响了R600的效能。
总结:虽然R600的ALU规模远大于G80,但G80的SP运行频率几乎是R600的两倍,而且G80的体系架构采用完全标量化的计算,资源利用率更高,执行效能也更高,因而总体性能不落后于R600。
第八章:尴尬的中端--Geforce8600简析
在新一代中端显卡中,最早发布也是最受关注的莫过于nVidia的G84---Geforce8600系列。
但是相比其高高在上的价格,它的性能表现实在不尽如人意,很多测试中均落后于价格低于它的老一代高端显卡Geforce7900GS。本章将利用前面讨论的结论对G84核心的SP处理能力作简要地分析。
G84是G80核心的高度精简版本,SP数量从G80的128个锐减为32个,显存位宽也降为1/3--128bit。
抛开显存位宽和TMU ROP,我们着重看SP,G84的SP频率与核心频率也不相同,例如8600GT,核心频率只有540MHZ,shader频率却高达1242MHZ,即核心频率的两倍多,我们粗略按两倍记,则G84核心相当于核心shader同步的64(个1D标量) SP,而传统的VS和PS中ALU是4D的,于是可以说G84的计算能力相当于传统VS和PS总数为64/4=16的显卡,粗略比较,它与Geforce7600(PS+VS=17)的计算能力相近。但当然,事实这样比较是有问题的,因为在G7X中,每个PS中有两个4D ALU,因而7600的运算能力高于传统PS+VS=17的显卡。下面的计算就说明了问题:(MADD *** 作)
对于7600GT ,VS为4D+1D PS为4D+4D 核心频率560MHZ 理论峰值浮点运算速度:
560MHZ(12(4+4)+5(1+4))2=13552GFLOPS
而对于8600GT:1242MHZ3212=794GFLOPS
由此可见,8600GT的峰值运算速度甚至远低于上代的7600GT,更不用跟7900GS相比了。但是,实际情况下,迫于传统架构所限,G7X满载的情况基本不可能出现,G7X的实际运算速率要远低于理论值,而对于G8X架构,执行效率则高很多,实际运算速率会更加接近理论极限。而且支持SM40的G8X寄存器数目也要远多于G7X,众多效率优势,使得Geforce8600GT仅凭借少量的SP就足以击败上代中端7600GT。
但是作为DX10显卡,仅仅击败7600GT显然不是最终目标,仅32SP的它在计算量要求空前之高的DX10游戏中表现极差,根本不能满足玩家要求。
总结:8600GT性能上取代7600GT的目标凭借着高效的统一渲染架构总算勉强完成,但过少的SP数量使得其显然难以击败上代高端,更不用说流畅运行DX10游戏了,而高高在上的价位更使其处境不利,归根到底,nVidia对G84 SP数量的吝啬以及过高的价格定位造就了Geforce8600的尴尬,因此,就目前的情况来看,选用8600系列显然不如Geforce7900和RadeonX1950GT来的划算。
处理身份z申请的时间一般约需10个工作天(星期六及公众假期除外)。
一般程序如下:
18岁或以上人士须填写申请表格ROP1(可在网上下载或亲到办事处领取)
填表後要预约服务
向人事登记办事处申领香港身份z的预约期为24个工作天。
可网上预约服务,或
申请人亦可使用24小时电话预约服务热线进行预约。
持单程证由内地来港的人士须前往人事登记处—九龙办事处办理首次登记身份z手续
证明文件
申请人在办理登记时须出示以下属於本人的文件正本:
新抵港人士在办理登记时须出示以下属於本人的文件正本:
单程证(只适用於持单程证由内地来港的新抵港人士)
有效旅行证件、护照、入境证或誓章,以确认申请人在香港的居留身份
如申请人是因身份z已损坏或污损而申请补领新证,则须出示其已损坏或污损的身份z。
申请程序
当申请人抵达人事登记办事处时,应到接待处领取筹号及申请表格。如申请人已预约了办证时间,请告知接待处职员有关预约时段及身份z明文件号码或出示预约确认通知书。在等候登记员接见期间,请小心阅读及填妥申请表格。
请参考:
1 港方: 香港身份z , 回乡证 (正&副本) , 48x33mm 免冠近照3张
2 内地方: 户口簿 (机印字体 , 不接受手写旧板) , 身份z (正&副本) , 48x33mm 免冠近照3张 , 港澳通行证 (正&副本)
3 有效结婚证明文件
(香港注册: 入境处ROP122 - 登记事项证明书费用:385 or 经本港中国委托公证人出具的夫妻关系(结婚)证明声明书 )
4 港方亲笔写的邀请信 (遨请内地方赴港定居团聚 , 用黑色墨水笔写 , 不可用原子笔)
各地公安尚有可能需要其他文件 , 包括:
- 由香港寄出至内地方的信封一个 (一定要有邮 chop , 寄空邮挂号以保证收到)
- 夫妻生活照数张
1、首先我们打开Keil μVision编译器,新建一个工程,然后保存在硬盘上的位置,然后选择Atmel-AT89C51单片机为模型,并启动器添加STARTUPA51文件,然后在当前目录下新建一个C文件,并将其添加入工作路径。
2、导入51单片机的头文件以及LCD1602的头文件。
3、创建一个延时函数,可以传入想要具体延时的时长,其内部实现是由一个二重循环,两个循环的次数相乘积。
4、然后创建写命令的函数,指定RS和E同时为0时,才可以写入命令,设定完成后,将com写入输出端口,规定写命令时,E为正脉冲,然后空 *** 作一个机器周期等待机器反应。
5、然后创建写数据的函数,规定写数据时,E为正脉冲,规定当RS=1和RW=0时才可以写入数据,然后将数据从输出端口输出,最后让E产生正跳变。
6、然后创建初始化LCD1602的函数,指定显示模式位两行显示,57,8位数据、整体显示,无光标,无闪烁、写入一个字符后地址指针加1,最后进行清屏 *** 作。
7、最后在主函数中首先执行LCD1602的初始化函数,首先创建一个无限循环,然后添加两个字符串,这里以两行显示百度经验的网址为例,再进行延时以及使用清屏函数进行刷新。
接下来笔者将着重介绍一下基于SM30的HDR技术,究竟给我们的3D世界带来怎么样的震撼呢首先来看一下SM30:SM30是Shader Model 30版本的意思,这其中包括了Vertex Shader30和Pixel Shader30,以及ROP着色器。与上一个版本Directx90b中的SM20规范相比,30规范的指令则增加到了32,768 与当初20支持的96条指令比起来简直是跨越了一个层次。实际应用于游戏,当你在丛林中漫步的时候可以看到头顶上的树叶在你的步q上实时投下斑驳的阴影;在一些宏大的室内场景里,身型巨大的怪物的影子投射在你身边的墙上,预示着它的到来;熔岩场景中熔岩口上方的腾腾的热气模糊和扭曲了后方的影像。
SM30游戏效果
而基于SM30下的HDR技术全称为High Dynamic Range,即高动态范围,比如所谓的高动态范围图像(HDRI)或者高动态范围渲染(HDRR)。动态范围是指信号最高和最低值的相对比值。目前的16位整型格式使用从“0”(黑)到“1”(白)的颜色值,但是不允许所谓的“过范围”值,比如说金属表面比白色还要白的高光处的颜色值。在HDR的帮助下,我们可以使用超出普通范围的颜色值,因而能渲染出更加真实的3D场景。HDR的技术出发点就是让计算机能够显示更接近于现实的画面质量。目前在民用领域看到最多HDR技术应用的必然是游戏了。
HDR实效演示
HDR的基本工作原理:HDR是一种新的模型,它可以将画面中的每个象素色彩和亮度值用实际物理参数或是线性函数来表示。这样每个参数都可以用实际数值来表示,而且不再限定整数。
—————————————————————————————
Shaders其实是一段象素或顶点的着色程序。因此一般而言,shader程序有两大类:象素着色程序和顶点着色程序。这些程序包含了特殊的效果,能够作用到基本的几何对象上。例如:一个包含水状特征的着色程序,应用到蓝色贴图上,就会形成水纹效果;同理可知,一个包含玻璃状特征的着色程序,应用到一个多边形中,就会产生透明。依此类推,不一而同。
正是由于着色程序的广泛使用,才使得今天的游戏画面,比3、4年前要丰富逼真的多。另外因为所有的着色程序都是可编程的,因此游戏开发人员能够通过自己加工,在游戏中实现各种各样,极具个性的画面。而NVIDIA和ATI公司也为各自的产品提供了优化后的着色程序标准库,从而方便程序员的调用,减轻了开发的负担。
不同版本之间的Shader Modal也有所不同。最大的差别在于,所允许的着色程序长度在不断增加,着色程序的长度也就是能够被执行的指令数量。最开始的Shader Modal11规格显得还比较简陋,在撰写代码的时候非常严格,同样提供的语句也较少。到了Shader Modal2x,程序员可以使用循环语句来避免编写重复的代码。
到了Shader Modal30就允许程序员使用if-then这样的条件语句。因此随着版本的变迁,程序员所编写出来的着色程序可以更加小巧。而各个版本之间的技术变迁亦十分平滑,只有2x和30规格前后变化较大,后者增加了顶点贴图查询功能,能够使用置换贴图。
虽然Shader Modal软件规格在不断的修订发展,不过显卡厂商对新技术的支持却不尽相同。相比而言,硬件厂商的应用技术的策略,更多的受到市场因素的左右和影响。而急于推出带有最新技术的产品,也会伴随着相应的风险。例如:NVIDIA当前支持Shader Modal30的硬件就伴随着大量的噪音,而且新产品售价偏高。
正因为如此,市场上超过半数的显卡都还不能够运行Shader Modal30的程序。游戏开发人员也就不会冒冒然采用新技术,当然那些想要标新立异,引领潮流的游戏公司自然会成为新技术探险的先行者。例如现在已经能够看到采用Shader Modal30的游戏—Far Cry(孤岛惊魂),采用Shader Modal30中提升渲染速度的技术来改善性能。
由于Shader Modal30中有多项技术旨在改进性能,因此运行在2x规格下,比较吃力的着色程序,在30中会得到较好的性能表现。后来Far Cry发布了一个补丁,来支持HDR光源(高动态范围光源),这就是30所特有的技术了。
HDR
HDR并不是想许多玩家理解的那样就是简单的“高亮”,不是让画面有更大的亮度或是对比度,大家都知道,当人从黑暗的地方走到阳光下时,我们的眼睛会不由自主的迷起来,那是因为在黑暗的地方,人为了更好的分辨物体,瞳孔张开很大,以便吸收光线;而突然到了光亮处瞳孔来不及收缩,视网膜上的视神经无法承受如此多的光线,人自然会迷上眼睛阻止大量光线冲击视神经。我们的眼睛非常敏感,而PC就不具备这种功能。所以,HDR的最终效果因该是亮处的效果是鲜亮的,而黑暗处你也可以清晰的分辨物体的轮廓,位置和深度,而不是以前的一团黑。动态、趋近真实的物理环境是HDR的特效表现原则。
这里说明,并不是支持SM30的显卡才支持HDR,其实SM20都能实现对HDR的支持,区别在于SM20实现HDR的过程复杂,要消耗一定的VPU或者GPU的资源,而且过程复杂,大大增加程序员的负担并会使圆形速度变慢,具体原因请看上面关于SM的介绍
以上就是关于C语言,windows程序在窗口上绘图全部的内容,包括:C语言,windows程序在窗口上绘图、怎么用st visual programmer 擦除程序、关于GPU的问题!等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)