小生资历浅薄，不讨论该主题的重要性与未来的意义，只是个人兴趣爱好平日对这个问题思考了很多，总觉得要写点东西记录下来。框架还没有定型，只是记录自己设计的过程。
系统要跨平台，首先得将平台相关的实现与平台无关的实现分离。鄙文就对资源管理的平台先关与平台无关的分离做一些浅薄的论述。Texture和Buffer的管理将在随后两篇文章中讨论。
通常引擎会这样封装一个资源，来达到跨平台的目的
struct ITexture; // abstruct interface class D3DTexture : public ITexture
{
// dummy
private:
ID3D11Texture2D* m_textureInterface;
}; class GLTexture : public ITexture
{
// dummy
private:
unsigned int m_nRefCount;
int m_nTexture;
};
然后再运行期的时候由factory根据自己的渲染器来决定创建哪一个实现，剩下就交给The magic of virtual function.
然而这种设计没有将平台相关的代码与平台无关的代码分离。事实上，平台相关的代码是平台无关代码的实现，泛化关系有着比较高的耦合度。其次就是OO的设计问题。一般情况下在确定渲染平台后的程序运行时，是不存在ITexture指向不同平台实现的情况的。（例如在DX平台中有两个ITexture实例，一个指向D3DTexture，一个指向GLTexture）。虽然程序中是不会犯这种逻辑错误，但是OO给了这种可能。因此，我们在这里完全不需要运行期的分派(虚函数)。
基于上面两个问题的考量，首先我们要把平台相关与平台无关的代码分离。他们之间用一个ID联系着。
class texture
{
private:
int id_;
}; namespace directx
{
std::map<int, texture> textures; //当然，这个容器可能封装在某个manager中
}
首先，泛化关系变成了桥接关系，中间以一个ID作为索引的协议，耦合度降低了很多。并且平台无关的实现完全不知道平台相关的实现细节。其次，没有运行期的分派(虚函数)，完全阻止了OO设计带来运行期错误实例创建的可能性。小生也是不喜欢用虚函数，如果能用std::function和这种类似设计代替的都不会用虚函数。
在渲染框架中，资源都是统一管理的，甚至可以说在一个渲染框架中，GPU对象都是可以统一管理的。比如我们可以使用一个共同的基类object来抽象GPU的对象，其中有Resource，Sampler，Shader。Resource又分Texture和Buffer. 而Texture和Buffer又有各自的泛化。
object的抽象存在的意义就是统一管理引用计数，管理对象类型和RTTI等。下面我们用modern c++已有的组件来给出一个实现。
namespace pipeline
{
//
enum class object_type
{
texture_1d,
texture_2d,
texture_3d,
texture_cube,
texture_1d_array,
texture_2d_array,
texture_cube_array, // ....
// dummy
// .... vertex_shader,
sampler,
}; // enable_shared_from_this是为了使用shared_ptr来完成引用计数
class object : public std::enable_shared_from_this<object>
{
public:
static constexpr uint32_t invalid_handle()
{
return -;
} public:
// object统一管理不给出默认构造函数
object() = delete;
// 可能会从object来西沟一个对象
virtual ~object() = default;
// 没有拷贝语义
object(object const&) = delete;
object& operator= (object const&) = delete;
// 能有move语义
object(object&&) = default;
object& operator= (object&&) = default; protected:
// 不公开构造object的方法
object(object_type type, string const& name)
: type_(type)
, id_(invalid_handle())
, name_(name)
{ } public:
object_type type() const noexcept
{
return type_;
} string& name() noexcept
{
return name_;
} string const& name() const noexcept
{
return name_;
} uint32_t& id() noexcept
{
return id_;
} uint32_t id() const noexcept
{
return id_;
} private:
object_type type_;
uint32_t id_;
string name_;
};
};
object通常要用一个object manager来统一管理。管理object的创建，回收。这里小生借鉴了modern C++ desing一书中的工厂来实现。
namespace pipeline
{
class graphics_object_manager
{
typedef std::map<string, object*> object_container;
typedef std::function<object*(string const& name)> function_type;
typedef std::map<object_type, function_type> function_container;
public: // shader_ptr使用的自定义deleter，最终是用manager来回收
struct deleter
{
void operator() (object* obj) const noexcept
{
assert(nullptr != obj);
graphics_object_manager::get().delete_object(obj->name(), obj);
}
}; // singleton 暂时不考虑多线程
static graphics_object_manager& get()
{
static graphics_object_manager factor;
return factor;
} // 创建函数
auto get_object(string const& name, object_type type) -> std::shared_ptr<object>
{
auto itr = objects_.find(name);
object* created_object = nullptr;
std::shared_ptr<object> obj; if (objects_.end() == itr)
{
auto func_itr = functinos_.find(type);
if (functinos_.end() == func_itr)
throw std::exception{}; created_object = func_itr->second(name);
objects_[name] = created_object; obj.reset(created_object, deleter{});
}
else
{
created_object = itr->second;
if(type != created_object->type())
throw std::exception{};
}
return created_object->shared_from_this();
} // 注册一个对象类型的创建方法
bool register_creator(object_type type, function_type f)
{
auto itr = functinos_.end();
auto result = false;
std::tie(itr, result) = functinos_.emplace(type, f);
return result;
} // 有注册当然也有反注册
void unregister_creator(object_type type)
{
auto itr = functinos_.find(type);
if (functinos_.end() != itr)
functinos_.erase(itr);
} // 当shader_ptr析构返现引用计数为0是，会由注册的deleter来调用manager的回收函数
void delete_object(std::string const& name, object* object)
{
assert(nullptr != object); auto itr = objects_.find(name);
if (itr == objects_.end())
throw std::exception{}; if (itr->second != object)
throw std::exception{}; delete object;
objects_.erase(itr);
} private:
object_container objects_;
function_container functinos_;
};
}
register_creator和unregister_creator注册一个泛化仿函数到manager中来负责某一个object_type的创建工作。这是一个消除switch case的良好设计，不仅会可以让代码看起来更简洁优雅，更重要的是它消除create函数的集中管来带来的高耦合。详细请参看Modern C++ design.
get_object函数是一个创建函数，如果在容器中发现已有同名对象，做一个类型检查就返回出来。当没有时，manager会查找object_type为type的创建函数(std::function对象)，创建它。并从裸指针通过shared_from_this返回shader_ptr对象。shared_from_this必须要对该指针已经创建了一个shared_ptr才能调用，不然会抛出异常，所以我们创建了一个临时的shared_ptr对象，并注册deleter。函数返回的时候shared_ptr还没有析构，所以shared_from_this能返回一个有效的shared_ptr. 因此我们在manager中只用裸指针来管理这些对象了。
delete_object是当shared_ptr析构时发现引用计数为0，由pipeline::graphics_object_manager::deleter仿函数调用的，是在创建object的时候向shared_ptr注册的。
下面就是resource类的设计了，先给出代码再来谈谈自己的设计。
namespace pipeline
{
enum class device_access
{
none,
read,
write,
read_write,
}; template <typename Impl>
class resource : public object
{
protected:
resource(string const& name)
: object(Impl::type(), name)
, size_()
, data_()
, cpu_access_(device_access::none)
, gpu_access_(device_access::none)
{
} public: byte const* data() const
{
return data_.data();
} byte size() const
{
return size_;
} device_access cpu_access() const
{
return cpu_access_;
} device_access& cpu_access()
{
return cpu_access_;
} device_access gpu_access() const
{
return gpu_access_;
} device_access& gpu_access()
{
return gpu_access_;
} protected:
size_t size_; // 32bit integral for x86 & 64bit integral for x64
std::vector<byte> data_;
device_access cpu_access_;
device_access gpu_access_;
};
}
resource抽象在buffer和texture之上的。GPU资源就是一堆内存和CPU与GPU的访问权限。只所以要用模板是因为，这里无法保证运行期的LSP，Impl模板参数是实际的资源参数，并使用CRTP传递下来的。这样就保证了其实际类型不会丢失，还能用来计算object_type.
本文先到这里，后面阐述texture与buffer设计的文章还会对这里的设计做展开分析。