X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=src%2Fexa%2Fi965%2Fnew_job_old_tricks.mdwn;h=4144cb189f63988575b75f74dc85c4c7a5378fe0;hb=5c014fe14d7a114dc525711d3236feb10f27177f;hp=5b3c99b8574ddf120fea24cfecad733cf7416af3;hpb=f8304a59f3b8d4f2620b626af03cdb23af88fded;p=cworth.org

diff --git a/src/exa/i965/new_job_old_tricks.mdwn b/src/exa/i965/new_job_old_tricks.mdwn
index 5b3c99b..4144cb1 100644
--- 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