Nouveau - Apr 2016 - a few questions about OpenGL and nouveau

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.

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
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.*/


/* 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? 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...*/

    glBegin(GL_LINES);
    glColor3f(1.0, 1.0, 1.0);
    glVertex3f(0.0f, 0.0f, 0.0f);
    glVertex3f(50.0f, 50.0f, 1.0f);
    glEnd();
}

glXSwapBuffers();
}

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20160405/bc06dc54/attachment.html>

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

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>