Am 2014-03-09 05:07, schrieb Eric Anholt:
diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c
new file mode 100644
index 000..be2c2af
--- /dev/null
+++ b/glamor/glamor_vbo.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge,
Markus Wick mar...@selfnet.de writes:
This is a bit too small imo. iirc glamor was used to split up renderings
to 64k vertices, not 64k bytes.
What is the cache implact on too big buffers? i965 must fall through to
LLC, so will it pollute the L1+L2 caches?
For non-coherent gpus, write
Markus Wick mar...@selfnet.de writes:
Am 2014-03-09 05:07, schrieb Eric Anholt:
diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c
new file mode 100644
index 000..be2c2af
--- /dev/null
+++ b/glamor/glamor_vbo.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+
We should be uploading any vertex data using this kind of upload
style, since it saves a bunch of extra copies of our vertex data.
v2:
- Add a simple comment about what the function does.
- Use get_vbo_space()'s return in trapezoids, instead of dereffing
glamor_priv-vb (by Markus Wick).