扫盲，什么是graphic core--来自qualcomm的一篇邮件

http://lwn.net/Articles/394665/

Qualcomm 2D/3D graphics driver

For about a year and a half, the Qualcomm Linux team has been working to supportthe OpenGL ES 3D core in the Snapdragon processor.  The hardware made its debutin the Nexus One and has subsequently been used in a few other commercialproducts since then.  To support the 3D GPU we wrote a kernel based driver tomanage all the usual graphics concerns - interrupts, command streams, contextswitching, etc, etc.  You can see the latest and greatest incarnationof our driver here:https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;...I'm writing this email because we think it is high time that we get off thebench, into the game and push support for the Qualcomm graphics cores to themainline kernel. We are looking for advice and comment from the community onthe approach we have taken and what steps we might need to take, if any, tomodify the driver so it can be accepted.  I'm going to offer up a quickdescription of the hardware and describe our current approach as well as ourcurrent development plan for the summer.  Our goal is to start pushing thiscode upstream as quickly as possible, so comments and flames would be greatlyappreciated.=====The hardware layout is reasonably straight forward.  The GPU is, as expected,a platform device located on the same die as the processor.  The registers aremapped into the physical address space of the processor.  There device alsoshares memory with the main processor; there is no dedicated memory on boardfor the GPU. The GPU has a built in MMU for mapping paged memory.Some processor variants also have a separate 2D core attached.  The 2D core isalso a platform device with shared memory and a MM. While the general interfaceis similar to the 3D core, the 2D GPU has its own separate pipeline andinterrupt.The core of the driver is a home-grown ioctl() API through a character devicewe call /dev/kgsl.   Like other GPU drivers, all the heavy lifting is done bythe userspace drivers so the core set of ioctls are mainly used to access thehardware or to manage contexts:IOCTL_KGSL_DEVICE_GETPROPERTYIOCTL_KGSL_DEVICE_REGREADIOCTL_KGSL_DEVICE_REGWRITEIOCTL_KGSL_RINGBUFFER_ISSUEIBCMDSIOCTL_KGSL_DEVICE_WAITTIMESTAMPIOCTL_KGSL_CMDSTREAM_READTIMESTAMPIOCTL_KGSL_DRAWCTXT_CREATEIOCTL_KGSL_DRAWCTXT_DESTROYIn the early days of the driver, any memory used for the GPU (command buffers,color buffers, etc) were allocated by the user space driver through PMEM (asimple contiguous memory allocator written for Android; seedrivers/misc/pmem.c).  PMEM is not ideal because the contiguous memory it usesneeds to be carved out of bootmem at init time and is lost to the generalsystem pool, so the driver was switched to use paged memory allocated viavmalloc() and mapped into the GPU MMU.  As a result, a handful of additionalioctls were put into the driver to support allocating and managing the memory.When we started our X11 effort last year, we needed a DRM driver to supportDRI2.  We added a DRM skeleton to the existing GPU driver (this was the drivingforce behind the platform DRM patches I've sent out periodically).  The DRMdriver allocates its own memory for buffers to support GEM, and the buffers aremapped into the GPU MMU prior to rendering.  It is important to note that theDRM driver only provides GEM and basic DRM services - the userspace graphicslibraries still run rendering through the /dev/kgsl interface.Then, when support came along for the 2D core, it turned out that most of thesupport code was identical to that for the 3D GPU, with only a few differencesin how the command streams and interrupts were processed.  The 2D and 3D codewere merged together to form the driver that I linked above.  The ioctl callsremained the same, and a "device" member was added to each structure todetermine which core the call was destined for.  Each device has its own MMU,but each MMU shares the same pagetables.It has been argued that having the 2D and the 3D together is silly since theyare separate platform devices and they should be treated as such - theproposal is to have multiple device nodes, one for each device. Each devicewill have its iomapped registers, MMU pagetables, etc; while sharing genericsupport code in the driver:/dev/kgsl/0/dev/kgsl/1etc..I think that if we did this design we would also need to have an additionaldevice to allocate memory buffers which will make it easier for us to sharememory between cores (X11 in particular does a lot of simultaneous 2D and 3D).I also think that the memory allocator should be transitioned to a standarddesign (probably TTM).  Of course for X11 the DRM/GEM driver would still beused with GEM turning into a wrapper for the shared memory allocator.Thanks for reading,JordanPS:  About the name: our userspace drivers uses a HAL called GSL (for graphicssupport layer).  Elements of that HAL is what you see today in the kerneldriver, so we called it KGSL (Kernel GSL).  We used to have the driver indrivers/char/msm_kgsl/ but we were convinced to move it to drivers/gpu/msm,which is already a great improvement in naming and in location.  I presumethat one of the conditions of upstreaming would be to rename everything tosomething a little bit more descriptive and a little bit less cryptic.