Convert prefix directives to new syntax.

[cworth.org] / src / exa / i965 / new_job_old_tricks.mdwn

diff --git a/src/exa/i965/new_job_old_tricks.mdwn b/src/exa/i965/new_job_old_tricks.mdwn
index 5b3c99b8574ddf120fea24cfecad733cf7416af3..4144cb189f63988575b75f74dc85c4c7a5378fe0 100644 (file)
--- a/src/exa/i965/new_job_old_tricks.mdwn
+++ b/src/exa/i965/new_job_old_tricks.mdwn
@@ -1,6 +1,6 @@
-[[meta title="A new job, but old performance fixes"]]
+[[!meta title="A new job, but old performance fixes"]]
 
-[[tag exa performance i965]]
+[[!tag exa performance i965]]
 
 Many readers have heard already, but it will be news to some that I
 recently changed jobs. After just short of 4 years with Red Hat, I've
@@ -68,7 +68,7 @@ So here was one piece that just hadn't been finished yet. The driver
 was still just using a single vertex buffer that it allocates
 upfront---and a tiny buffer---just big enough for a single rectangle
 for a single composite operation. And so the driver was waiting for
-each composite operation to finish before reusing the bugger. And the
+each composite operation to finish before reusing the buffer. And the
 change to GEM had made this problem even more noticeable. And Eric
 even had a partially-working patch to fix this---simply allocating a
 much larger vertex buffer and only doing the sync when wrapping around
@@ -84,7 +84,7 @@ So, with that in place the only thing left to decide was how large of
 a vertex buffer to allocate upfront. And that gives me an excuse to
 put in a performance plot:
 
-[[img vertex_buffers.png]]
+[[!img vertex_buffers.png]]
 
 So the more the better, (obviously), until we get to 256 composite
 operations fitting into a single buffer. Then we start losing