<div dir="ltr"><div><div>Hi, TBH not even I know what do I want :))) </div>The "dirty...", "I think, but am not sure..." and "The gallium state tracker..." paragraphs are enough "food for thought" for me. </div><div>I'll spend eons digging it... Thank you. </div></div><div class="gmail_extra"> <div class="gmail_quote">2016-04-05 14:54 GMT-04:00 Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Apr 5, 2016 at 2:38 PM, Daniel Melo Jorge da Cunha <<a href="mailto:dmjcunha@gmail.com">dmjcunha@gmail.com</a>> wrote: > Hi... I know... glBegin/glEnd is deprecated but I have an old computer 32bit > CPU, > running fedora 19, mesa-9.2.4, NV63... any help are welcomed. I've fixed a *ton* of nv3x/nv4x issues since then, I'd recommend giving Mesa 11.2.0 a whirl. > > Please forgive if I misuderstood everything. > > So I have a simple OpenGL program that draws a black background and a white > line... I will write the code of myline() inside of main() so as I can > learn. > > main (..) { > X and glX stuff... > > /* at this moment I think what was sent to the card was the > nv30_screen_create(...) > that valgrind--mmt outputs 0x4e000 in the first line of valgrind--mmt hex > until You'll want to use demmt, part of envytools. It should auto-decode stuff. If it doesn't, let me know (and send me the mmt). > PUSH_DATA (push, NV05_SIFM_COLOR_CONVERSION_TRUNCATE); which happens to be > line 65 > of valgrind--mmt output */ > > glViewport(...); > > void mydrawline(void) > { > glClearColor(0.0, 0.0, 0.0, 1.0); > glClear(GL_COLOR_BUFFER_BIT); > > /* at this point I guess it ends up calling nv30_clear(...) which calls > BEGIN_NV04(push, NV30_3D(CLEAR_DEPTH_VALUE), 3); and the valgrind--mmt > output is > 0xcfd8c in line 281 of the valgrind-mmt's output file. > As I can see there is 215 lines (from 66 to 280) of valgrind--mmt that I do > not know > from where is it coming. I could dig in nv30_state_validate(...) but at this > moment I > think nv30->dirty is 0 so validate->func(nv30) is not called. Help, > please.*/ dirty definitely shouldn't be 0... it has to bind a framebuffer at least. > > > /* This I guess is mesa stuff... */ > glMatrixMode(GL_PROJECTION); > glLoadIdentity(); > glOrtho(0, 300, 0, 300, -1, 1); > glMatrixMode(GL_MODELVIEW); > > /*Here another question. Does glBegin end up calling a driver code like > BEGIN_NV04(...) that instructs the card to get the next 3 floats for color > more 3 for the first vertex and another 3 for the other? Also at this moment > the video card memory is already mapped (I guess...) so are these floats > fetched > by the pusher of the card and draw the line, possibly when glXSwapBuffers is > called? > Is the glColor(...) (the three floats) stored in the mmapped twice, one for > each > vertex? I think, but am not sure, that it will come in as a constant attribute (i.e. a VBO attribute with stride 0). > HELP I'M LOST :( This mine consideration is wrong... I guess... > st_draw.c > coments that all "rendering" is done through st_draw_vbo() which would end > up > calling nv30_draw_vbo() which would send data to the card... but where is > the > missing link?? The floats (for the vertices and color) are already mapped by > ctx->Driver.MapBufferRange...*/ The gallium state tracker does not support immediate vertex submission. There's a "vbo" layer in front of it which converts immediate vertex submissions into writes to a VBO, which is then bound and drawn with. You may be interested in doing GALLIUM_TRACE=foo.xml [on a debug mesa build] which will create an xml file of all the state tracker calls. It will show you the VBO setup, etc. State is only emitted at draw time (or something like blits, clears, etc). So doing glViewport() does nothing. It dirties internal state, which is then emitted at draw time. TBH I'm not sure what your actual question is... but hope I've answered at least some of it? -ilia </blockquote></div> </div>