1 Reply Latest reply on Jan 5, 2011 6:51 PM by jeff_golds

    More info about fusion and 6000m mobility needed..

    oscarbarenys1

       

       

      Today 6xxxm launched so there is some mobility based on Cayman for example 6900m? or not?

      at least they ship uvd 3 so seems some are barts based right?

      Also fusion shipped today so would be good to know how to finally efficiently exploit the unified mem arch in opencl? it's viable with 2.3 sdk?

      searching binaries and headers i found cl_amd_region_address_space extension so this will be used for fusion also I see 

      #define CL_MEM_USE_PERSISTENT_MEM_AMD       (1 << 6)        // Alloc from GPU's 

      so seems related to fusion or a way to use host mem accesible from GPU directly?

      more info please..

      also I saw some days ago contradictory info about cayman suppport for multiple kernels.. some web sites says they will support running multiple opencl programs at the same time (so seems exploitable via two ocl contexts also and also some say this implies two hardware command queues and will be exposed with an opencl extension.. so searching in sdk 2.3 I found cl_agent_amd.h with seems just to be this extension to support cayman multiple kernel support right..?

      without much time to deep more insight can someone at amd show differences between two normal command queues in one opencl context and using two cl_agents wich seems similar to two contexts or two command queues?

       

      thanks..



        • More info about fusion and 6000m mobility needed..
          jeff_golds

           

          Originally posted by: oscarbarenys1 searching binaries and headers i found cl_amd_region_address_space extension so this will be used for fusion also I see 

           

          #define CL_MEM_USE_PERSISTENT_MEM_AMD       (1 << 6)        // Alloc from GPU's 

           

          so seems related to fusion or a way to use host mem accesible from GPU directly?



          Consider discrete GPUs.  The local memory on the GPU is too large to map into the CPU's address space due to 32-bit limitations (we can't assume 64-bit yet, unfortunately).  So, only a portion of it is mapped into the CPU's address space.  If you call clCreateBuffer() with the PERSISTENT flag, we will attempt to allocate the memory from the portion of GPU memory that is accessible by the CPU.  This way, when you call clEnqueueMapBuffer(), you can update the memory directly and avoid copies.

          Note that this flag is unsupported for SDK 2.3 and will have no effect.

          Jeff