[Nouveau] a few questions about OpenGL and nouveau

[Daniel Melo Jorge da Cunha]

Hi, TBH not even I know what do I want :)))

The "dirty...", "I think, but am not sure..." and "The gallium
state tracker..." paragraphs are enough "food for thought" for me.

I'll spend eons digging it... Thank you.

2016-04-05 14:54 GMT-04:00 Ilia Mirkin <imirkin at alum.mit.edu>:

> On Tue, Apr 5, 2016 at 2:38 PM, Daniel Melo Jorge da Cunha
> <dmjcunha at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20160405/448bdbab/attachment-0001.html>