mesa3d-dev Mailing List for Mesa3D (Page 848)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I tried this email:  da...@ti...
but it bounced back .. anyone know his current/working  email?

thanks

Chris Edgington wrote:
> 
> I'm working with the xf 4.0.1 kit. The file doc/specs/GL/libGL.txt talks about source code
> existing in xc/lib/GL/mesa/src, but I don't have any source in that folder. I do see the
> files mentioned in the libGL.txt but they are in xc/extras/Mesa/src. Did I not unpack my
> source right (maybe I'm supposed to have some links to those files) or does the libGL.txt
> need updated?

Look in xc/extras/Mesa/src instead.

The xc/lib/GL/mesa/src/ directory is made during the compile process (symlinks
back to xc/extras)

-Brian

I'm working with the xf 4.0.1 kit. The file doc/specs/GL/libGL.txt talks about source code
existing in xc/lib/GL/mesa/src, but I don't have any source in that folder. I do see the
files mentioned in the libGL.txt but they are in xc/extras/Mesa/src. Did I not unpack my
source right (maybe I'm supposed to have some links to those files) or does the libGL.txt
need updated?

Thanks,
-Chris

While I am trying to figure out why 3.3 does not work with Q3demo (but
works w/ Q3test or SOF, but for some reason the top 40-80 scan lines are
cut off.. that's another weird thing.. maybe because I have X4.0.1 ?)
I stumbled accross this weirdness:

with all the Mesa's that come w/ Q3test and Q3Demo and Q3A they will
default at 640x480x16bit colordepth and 16bit Zbuffer on my Voodoo2.

For some reason when I use 3.3 with Q3test and Q3demo (before it crashes) 
they report that they have a 24bit Zbuffer!?  Now maybe i am confused, but
doesn't the Voodoo2 have a maximum of 16bit zbuffer (either integer and
floating point? I think that's what Gary Tarolli told me)

Another problem I noticed is that the FXMesa module is version 0.30 but it
does not detect (or at least report) the right settings for my Voodoo2:

One of the old ones:
GL_VENDOR: Brian Paul
Mesa CVA Extension (C) 1999 Keith Whitwell
GL_RENDERER: Mesa Glide v0.30 Voodoo_Graphics 0 CARD/4 FB/4 TM/2 TMU/NOSLI
GL_VERSION: 1.2 Mesa 3.1 beta

as opposed to the new one:

GL_VENDOR: Brian Paul
GL_RENDERER: Mesa Glide v0.30 Voodoo_Graphics 0 CARD/0 FB/0 TM/2 TMU/NOSLI
GL_VERSION: 1.2 Mesa 3.3

0mb of Framebuffer? 2Mb of texture memory?  At least it got my 2TMU's
right. It obviously works ok, but I am wondering why it does this?

Ok, I just tried Mesa 3.2.1 and Voodoo2 and q3demo and it worked ok.

Next I will have to get Mesa 3.3 from CVS i guess ..

If you have compiled your Win32 Mesa dlls with Glide:
do you think you can make your Win32 dlls of Mesa 3.3 available somehwere
for download ?   THe reason is that when I had Wine working (stopped when
i installed TDFX DRI argg), I was able to use the mesa.dll (3.0) to get
quite a few Win32  OpenGL apps to work w/ Wine. But of course 3.0 was
messed up in many respects so the programs had many visual artifacts etc
etc .. It would be appreciated. Thanks

Mesa 3.3 from the release date (The current DEVELOPMENT release of Mesa is
version 3.3, released on July 21, 2000.) and q3demo will not work on my
Voodoo2.

Basically I compiled 3.3 with latest CVS glide headers, and glide 2.53-3
(as well as my own compile of glide from CVS). q3demo crashes with a sig
11 while  q3test and Soldier of Fortune work fine, as well as my own apps.

I don't have any thread support built-into Mesa. This happens with both no
debug info or with all debug info in the libs.

The weird thing is this does not happen with libMesa 3.3 beta that came
with either Q3demo, Q3test or Q3A (i forget where i got it), or any other
libGL's up to 3.2   I will get 3.2.1 and test this out and report back.

If someone could point me to a document on how to debug dynamically loaded
libs maybe I can narrow down the problem.

Thanks

Pavol Federl wrote:
> 
> I am trying to compile the mesa widget from the Mesa-3.2.1 distro, but
> the sources seem to be missing. There is only the ChangeLog file in the
> Mesa-3.2.1/widgets-mesa/src/ directory...

It was accidently omitted.  Grab Mesa 3.1 or older.  The widget
sources haven't changed.

-Brian

I am trying to compile the mesa widget from the Mesa-3.2.1 distro, but
the sources seem to be missing. There is only the ChangeLog file in the
Mesa-3.2.1/widgets-mesa/src/ directory...

Pavol

Bill Baxter wrote:
> 
> I noticed that the driver function OptimizeImmediatePipeline doesn't
> seem to be called from anywhere inthe Mesa source.
> OptimizePrecaclPipeline gets called at the end of
> build_full_precalc_pipeline in pipeline.c.  So I would have expected
> to see build_full_immediate_pipeline call OptimizeImmediatePipeline at
> the end too.  Is there some reason for it not being called?

Basically the two optimize pipeline calls should/will be removed in favour of
the build pipeline calls.  Can you use these instead?

Keith

I noticed that the driver function OptimizeImmediatePipeline doesn't
seem to be called from anywhere inthe Mesa source.
OptimizePrecaclPipeline gets called at the end of
build_full_precalc_pipeline in pipeline.c.  So I would have expected
to see build_full_immediate_pipeline call OptimizeImmediatePipeline at
the end too.  Is there some reason for it not being called?

--Bill

Bill Baxter wrote:
> 
> I'm guessing that in terms of raw triangle performance, though,
> display lists would be just as fast or faster than CVA.  Is that true?

Not necessarily.  It really depends on a whole bunch of things,
including things like your hardware capabilities (some hardware can
process display lists directly) and the driver implementations of
display lists and CVA.

On the other hand, some of the good ol' SGI hardware could process
immediate mode triangles very fast as well.  You'd have to ask one of
the local ex-SGI luminaries about that, though ;-)

-- Gareth

Thanks for the responses.  

> At least Quake 2 and Quake 3 use EXT_compiled_vertex_array.  It's
> generally considered the fastest way to render in OpenGL on the PC
> platform at the moment.

I'm guessing that in terms of raw triangle performance, though,
display lists would be just as fast or faster than CVA.  Is that true?

So is the flexibility of CVA also a key reason for their use?  With
CVA I imagine one can do software culling at the triangle level and
send just the visible subset down the pipe with DrawElements.  Whereas
with display lists it's either CallList or don't CallList.

--Bill Baxter

Bill Baxter wrote:
> 
> Sorry to be such a bother, but I think I may have partially found the
> answer to my question.  Am I correct in thinking that CVA is just the
> support for Non-ARB GL Extension number 97 as described by this
> document?:
>  http://oss.sgi.com/projects/ogl-sample/registry/EXT/compiled_vertex_array.txt
> 
> I wasn't aware of this extension.  Is it commonly used in the real
> world?  There seems to be an awful lot of code in Mesa to support it
> given that only one sample/demo uses it as far as I can see
> (isosurf.c).  Heh, I wonder if that means Quake uses it.

Seeing as Keith's not answering email, I'll field this one.

Compiled vertex arrays are essentially used by the application to lock
down one or more of the arrays (vertex, texture coords etc) when they
aren't going to change.  This allows the driver (Mesa, in this case) to
preprocess the arrays and store them in this preprocessed form, rather
than having to process the arrays each time say glDrawElements() is
called.  Let's just say this can be a lot faster if used correctly. 
Compiling the arrays into some optimized form might result in
hardware-format arrays in local or AGP memory on a hardware T&L card,
for instance.  Doing this once, and then rendering many primitives with
calls to glDrawElements() or equivalent, is pretty darned fast.

At least Quake 2 and Quake 3 use EXT_compiled_vertex_array.  It's
generally considered the fastest way to render in OpenGL on the PC
platform at the moment.

isosurf had CVA and other specialized paths implemented to test this
functionality in Mesa.  It's nice to be able to exercise these paths
with a simple demo program.

-- Gareth

On Fri, Aug 04, 2000 at 04:42:06PM -0400, Bill Baxter wrote:

> I wasn't aware of this extension.  Is it commonly used in the real
> world?  There seems to be an awful lot of code in Mesa to support it

Yes. Nearly every performance critical application does.

> given that only one sample/demo uses it as far as I can see
> (isosurf.c).  Heh, I wonder if that means Quake uses it.

Yes.

m.

-- 
Programmer             "Ha ha." "Ha ha." "What are you laughing at?"
Loki Software                      "Just the horror of being alive."
http://lokigames.com/~briareos/                   - Tony Millionaire

Sorry to be such a bother, but I think I may have partially found the
answer to my question.  Am I correct in thinking that CVA is just the
support for Non-ARB GL Extension number 97 as described by this
document?: 
 http://oss.sgi.com/projects/ogl-sample/registry/EXT/compiled_vertex_array.txt

I wasn't aware of this extension.  Is it commonly used in the real
world?  There seems to be an awful lot of code in Mesa to support it
given that only one sample/demo uses it as far as I can see
(isosurf.c).  Heh, I wonder if that means Quake uses it.

--Bill Baxter

Is there any document which explains the philosophy and general mode
of operation of CVAs in Mesa?  I'm having trouble getting the big
picture of why they exist, what they do, and how they relate to dlists
and client-side arrays.

Thanks,
--Bill Baxter

me...@bi... wrote:
> 
> Here are the rest of the changes I made to get 3.3 to compile under
> windows.  I don't have a 3dfx card, so I just modified the GDI
> (src/Windows) renderer.  With these changes you should be able to
> build the mesa32 target.
> 
> Files changed:
> 
> win32/rules/lib.mesa.core
> src/glheader.h
> src/windows/wmesa.c
> src/windows/wgl.c

patch on Linux doesn't seem to like your patches.  I applied what
I could by hand though (lib.mesa.core and wgl.c) and have checked
them into Mesa CVS.

Perhaps you can make another patch relative to CVS.  A context-
diff might work better.

-Brian

Alessandro Pisani wrote:
> 
> I downloaded both Mesa3.2.1 and Mesa3.3 and tried to compile them for Win32
> using MS-VC 6.0-SP4; here there is a list of problems I found (which were
> not present in Mesa 3.2, I mean) :
> 
> Light problems (Mesa 3.x):
> 1a) In both Mesa 3.2.1 and Mesa 3.3 , due to the revert to GLU 1.1, win32
> makefiles contains some "orphans" (like tess_clip.*, tess_wind.*, etc etc)
> This email has a patched win32/rules/lib.mesaglu.core attached.
> 
> 1b) ...there is also to change the src-glu/mesaGLU.def (GLU32.DLL is not
> generated noither via win32/nmake.mak nor via src-glu/makefile.fx) or you
> will get some unresolved externals errors in linking.
> This email has a patched src-glu/mesaGLU.def AND a pathed
> win32/res/mesaglu32.def attached (I only rem some lines)
> 
> Heavy problems (Mesa 3.3 only):
> 1) win32 makefiles updated in 3.2.1 are NOT present (why?)
> 2) GL/mesa_wgl.h file is MISSING (again, this was present in Mesa3.2.1)
> 3) VC start compiling but stop after a while with fatal errors (i.e. : HDC
> and HGLRC types redefined in glheader.h from
> E:\PROGRA~1\MICROS~2\VC98\INCLUDE\windef.h )
> 
> This does not happen in Mesa 3.2.1 in which gl.h was not splitted into gl.h
> and glheader.h :( I'm investigating on this... but it is really hard, at
> least for me.
> 
> PS: Brian told me some people complained about the CR/LF files I posted
> some time ago. Sorry, this is caused by my working in DOS/Win32 instead of
> Linux (my Linux partition is actually KO :sob!: ). Use this to fix the
> file: sh -c "mv filename _tmpfile; tr -d \\\r < _tmpfile > filename; rm
> _tmpfile"

OK, I think I've fixed all the problems you list.  I've checked the
changes into both the Mesa 3.4 branch and 3.5 trunk in CVS.

-Brain

Here are the rest of the changes I made to get 3.3 to compile under
windows.  I don't have a 3dfx card, so I just modified the GDI
(src/Windows) renderer.  With these changes you should be able to
build the mesa32 target.

Files changed:

win32/rules/lib.mesa.core
src/glheader.h
src/windows/wmesa.c
src/windows/wgl.c

Diffs:

X:\work\Mesa3D_PC_CVS\Mesa\WIN32\RULES>cvs diff lib.mesa.core
Index: lib.mesa.core
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/WIN32/RULES/lib.mesa.core,v
retrieving revision 1.3
diff -r1.3 lib.mesa.core
6,14c6,17
< MESA_CORE = accum.c alpha.c alphabuf.c api1.c api2.c apiext.c\
<    attrib.c bbox.c bitmap.c blend.c buffers.c clip.c colortab.c config.c conte
xt.c\
<    copypix.c cva.c depth.c dlist.c drawpix.c enable.c enums.c eval.c\
<    extensions.c feedback.c fog.c get.c hash.c hint.c image.c light.c\
<    lines.c logic.c masking.c matrix.c mmath.c mthreads.c pb.c pipeline.c\
<    pixel.c pointers.c points.c polygon.c quads.c rastpos.c readpix.c\
<    rect.c scissor.c shade.c span.c stages.c state.c stencil.c teximage.c texob
j.c texstate.c\
<    texture.c translate.c triangle.c varray.c vb.c vbcull.c vbfill.c\
<    vbindirect.c vbrender.c vbxform.c vector.c vertices.c winpos.c xform.c zoom
.c
---
> MESA_CORE = aatriangle.c hash.c pixeltex.c texture.c\
>    accum.c debug_xform.c highpc.c points.c texutil.c alpha.c depth.c\
>    hint.c polygon.c translate.c alphabuf.c dispatch.c image.c quads.c\
>    triangle.c attrib.c dlist.c imaging.c rastpos.c varray.c bbox.c\
>    drawpix.c light.c readpix.c vb.c bitmap.c enable.c lines.c rect.c\
>    vbcull.c blend.c enums.c logic.c scissor.c vbfill.c buffers.c\
>    eval.c lowpc.c shade.c vbindirect.c clip.c extensions.c masking.c\
>    span.c vbrender.c colortab.c feedback.c matrix.c stages.c vbxform.c\
>    config.c fog.c mem.c state.c vector.c context.c get.c mmath.c\
>    stencil.c vertices.c convolve.c glapi.c pb.c teximage.c winpos.c\
>    copypix.c glapinoop.c pipeline.c texobj.c xform.c cva.c glthread.c\
>    pixel.c texstate.c zoom.c

X:\work\Mesa3D_PC_CVS\Mesa\src>cvs diff glheader.h
Index: glheader.h
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/src/glheader.h,v
retrieving revision 1.11
diff -r1.11 glheader.h
132a133,134
> #include <windef.h>
> /*
139a142
> */
141d143
<
156a159,160
> /* mesa_wgl includes gl.h which includes glext.h */
> #define GL_GLEXT_PROTOTYPES
159,160d162
<
<

X:\work\Mesa3D_PC_CVS\Mesa\src\Windows>cvs diff wmesa.c
Index: wmesa.c
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/src/Windows/wmesa.c,v
retrieving revision 1.3
diff -r1.3 wmesa.c
87c87
< #pragma warning ( disable : 4133 4761 )
---
> #pragma warning ( disable : 4100 4133 4761 )
433,435c433,436
< // TODO: I modified this function to match the prototype in dd.h. (swansma@geo
cities.com)
< //       dd.h does not explain what the return type is so I could not set this to the proper
< //       value.
---
>
> // TODO: I modified this function to match the prototype in
> //       dd.h. (sw...@ge...)
>
445a447,449
>     GLbitfield colorBits =
>       (DD_FRONT_LEFT_BIT | DD_FRONT_RIGHT_BIT |
>        DD_BACK_LEFT_BIT  | DD_BACK_RIGHT_BIT);
448a453,454
>       if (mask & colorBits)
>       {
529a536
>       }
530a538
>     ENDPROFILE(clear)
532,535c540
<         ENDPROFILE(clear)
<
<               return mask;    // TODO: I doubt this is correct. dd.h doesn't explain what this should
<                               //       be...
---
>     return mask & ~colorBits; // return which buffers "software" must clear
602c607,622
< static GLboolean set_buffer( GLcontext* ctx, GLenum mode )
---
> static GLboolean set_draw_buffer( GLcontext* ctx, GLenum mode )
> {
>    STARTPROFILE
>    /* TODO: this could be better */
>    if (mode==GL_FRONT_LEFT || mode==GL_BACK_LEFT) {
>       return GL_TRUE;
>    }
>    else {
>       return GL_FALSE;
>    }
>    ENDPROFILE(set_draw_buffer)
> }
>
>
> static void set_read_buffer( GLcontext* ctx, GLframebuffer *colorBuffer,
>                              GLenum mode )
605a626
> /*
612c633,634
<    ENDPROFILE(set_buffer)
---
> */
>    ENDPROFILE(set_read_buffer)
1179c1201,1202
<     ctx->Driver.SetBuffer = set_buffer;
---
>     ctx->Driver.SetDrawBuffer = set_draw_buffer;
>     ctx->Driver.SetReadBuffer = set_read_buffer;
1367c1390,1394
<     c->gl_buffer = gl_create_framebuffer( c->gl_visual );
---
>     c->gl_buffer = gl_create_framebuffer( c->gl_visual,
>                                           c->gl_visual->DepthBits > 0,
>                                           c->gl_visual->StencilBits > 0,
>                                           c->gl_visual->AccumRedBits > 0,
>                                           c->gl_visual->AlphaBits > 0 );
2155a2183
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2197a2226
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2239a2269
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2278a2309
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2318a2350
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2358a2391
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2611a2645
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2650a2685
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2691a2727
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2725a2762
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2761a2799
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE
2801a2840
> #define DEPTH_TYPE DEFAULT_SOFTWARE_DEPTH_TYPE

X:\work\Mesa3D_PC_CVS\Mesa\src\Windows>cvs diff wgl.c
Index: wgl.c
===================================================================
RCS file: /cvsroot/mesa3d/Mesa/src/Windows/wgl.c,v
retrieving revision 1.2
diff -r1.2 wgl.c
33a34
> #define GL_GLEXT_PROTOTYPES
34a36
> #include <GL/glext.h>
47,48d48
< #define MAX_MESA_ATTRS        20
<
93c93
<    { (PROC)glBlendFuncSeparateINGR,           "glBlendFuncSeparateINGR"
},
---
>    { (PROC)glBlendFuncSeparateEXT,            "glBlendFuncSeparateEXT"
},

me...@bi... wrote:
> 
> I got mesa 3.3 working on Windows (built and linked to opengl32.dll).
> One more bit of difficulty I ran into was with header inclusion order.
> 
> - glapi.c needs a bunch of prototypes for extenstions to compile
>   correctly.
> - glext.h has them, but they only get compiled in if
>   GL_GLEXT_PROTOTYPES is defined.
> 
> The chain of inclusion with glapi under Windows/MSVC goes like this:
> 
>  glapi.c includes glheader.h,
>    which includes mesa_wgl.h,
>    which includes gl/gl.h,
>    which includes gl/glext.h (since GL_GLEXT_LEGACY is not defined).
> 
> But nowhere in there does GL_GLEXT_PROTOTYPES get defined. It currently
> gets defined in glheader.h just AFTER the inclusion of mesa_wgl.h
> after which glheader includes gl.h and glext.h directly.  So I fixed
> by defining GL_GLEXT_PROTOTYPES it just before #including mesa_wgl.h in
> glheader.h.  Sound ok?

Yes, that seems to work fine.  I'm checking in the change to
the Mesa 3.4 branch and 3.5 trunk.

-Brian

I got mesa 3.3 working on Windows (built and linked to opengl32.dll).
One more bit of difficulty I ran into was with header inclusion order.

- glapi.c needs a bunch of prototypes for extenstions to compile
  correctly. 
- glext.h has them, but they only get compiled in if
  GL_GLEXT_PROTOTYPES is defined.

The chain of inclusion with glapi under Windows/MSVC goes like this:

 glapi.c includes glheader.h,
   which includes mesa_wgl.h,
   which includes gl/gl.h,
   which includes gl/glext.h (since GL_GLEXT_LEGACY is not defined).

But nowhere in there does GL_GLEXT_PROTOTYPES get defined. It currently
gets defined in glheader.h just AFTER the inclusion of mesa_wgl.h
after which glheader includes gl.h and glext.h directly.  So I fixed
by defining GL_GLEXT_PROTOTYPES it just before #including mesa_wgl.h in
glheader.h.  Sound ok?

--Bill Baxter

"James A. Treacy" wrote:
> 
> There is no source in mesa-widgets/src in mesa 3.2.1.
> Is this intentional and if so, why?

It was an accident.  I've fixed the tar Makefile for
future versions.  The files can be grabbed from a previous
version of Mesa, they haven't changed.

-Brian

My bad.  The only EXT func that's actually gone that Windows/wgl.c
refers to is glBlendFuncSeparateINGR, but the name just seems to have
been changed to glBlendFuncSeparateEXT.  My grep missed the rest
because of the NAME() macro business. 

I'll take a look at the RELNOTES-3.3.

Thanks,
Bill Baxter

me...@bi... wrote:
> 
> I'm trying to get Mesa 3.3 compiling under windows.  Someone kindly
> mentioned they got this working with a trivial change, but it doesn't
> seem to be so easy to me.  Namely the driver interface has changed
> a bit so src/Windows doesn't compile any more.

Right, the device driver needs a number of updates.  See the
docs/RELNOTES-3.3 file.

> The extensions table in src/Windows/wgl.h has references to gl*EXT
> functions, but they don't exist anymore in 3.3.  It looks like I could
> either get these functions dynamically from a context, or I could use
> _mesa_*EXT versions.  What's the right thing to do?

Can you provide concrete examples of what the problem is?

-Brian

2000	Jan	Feb	Mar (10)	Apr (28)	May (41)	Jun (91)	Jul (63)	Aug (45)	Sep (37)	Oct (80)	Nov (91)	Dec (47)
2001	Jan (48)	Feb (121)	Mar (126)	Apr (16)	May (85)	Jun (84)	Jul (115)	Aug (71)	Sep (27)	Oct (33)	Nov (15)	Dec (71)
2002	Jan (73)	Feb (34)	Mar (39)	Apr (135)	May (59)	Jun (116)	Jul (93)	Aug (40)	Sep (50)	Oct (87)	Nov (90)	Dec (32)
2003	Jan (181)	Feb (101)	Mar (231)	Apr (240)	May (148)	Jun (228)	Jul (156)	Aug (49)	Sep (173)	Oct (169)	Nov (137)	Dec (163)
2004	Jan (243)	Feb (141)	Mar (183)	Apr (364)	May (369)	Jun (251)	Jul (194)	Aug (140)	Sep (154)	Oct (167)	Nov (86)	Dec (109)
2005	Jan (176)	Feb (140)	Mar (112)	Apr (158)	May (140)	Jun (201)	Jul (123)	Aug (196)	Sep (143)	Oct (165)	Nov (158)	Dec (79)
2006	Jan (90)	Feb (156)	Mar (125)	Apr (146)	May (169)	Jun (146)	Jul (150)	Aug (176)	Sep (156)	Oct (237)	Nov (179)	Dec (140)
2007	Jan (144)	Feb (116)	Mar (261)	Apr (279)	May (222)	Jun (103)	Jul (237)	Aug (191)	Sep (113)	Oct (129)	Nov (141)	Dec (165)
2008	Jan (152)	Feb (195)	Mar (242)	Apr (146)	May (151)	Jun (172)	Jul (123)	Aug (195)	Sep (195)	Oct (138)	Nov (183)	Dec (125)
2009	Jan (268)	Feb (281)	Mar (295)	Apr (293)	May (273)	Jun (265)	Jul (406)	Aug (679)	Sep (434)	Oct (357)	Nov (306)	Dec (478)
2010	Jan (856)	Feb (668)	Mar (927)	Apr (269)	May (12)	Jun (13)	Jul (6)	Aug (8)	Sep (23)	Oct (4)	Nov (8)	Dec (11)
2011	Jan (4)	Feb (2)	Mar (3)	Apr (9)	May (6)	Jun	Jul (1)	Aug (1)	Sep	Oct (2)	Nov	Dec
2012	Jan	Feb	Mar	Apr	May	Jun	Jul (3)	Aug	Sep (1)	Oct	Nov	Dec
2013	Jan (2)	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (7)	Nov (1)	Dec
2014	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec