From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDZGi-00015R-ER for qemu-devel@nongnu.org; Tue, 20 Jan 2015 08:54:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDZGd-0001Gn-94 for qemu-devel@nongnu.org; Tue, 20 Jan 2015 08:54:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38663) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDZGd-0001Gg-1C for qemu-devel@nongnu.org; Tue, 20 Jan 2015 08:54:51 -0500 Message-ID: <54BE5E27.7040807@redhat.com> Date: Tue, 20 Jan 2015 08:54:47 -0500 From: Max Reitz MIME-Version: 1.0 References: <1421674603-31575-1-git-send-email-kraxel@redhat.com> <1421674603-31575-5-git-send-email-kraxel@redhat.com> <54BD2B3A.1090508@redhat.com> <1421751643.3606.30.camel@nilsson.home.kraxel.org> In-Reply-To: <1421751643.3606.30.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 4/7] console-gl: add opengl rendering helper functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, Anthony Liguori On 2015-01-20 at 06:00, Gerd Hoffmann wrote: > Hi, > >>> +static GLchar texture_blit_vert_src[] =3D >>> + "\n" >>> + "#version 300 es\n" >>> + "\n" >>> + "in vec2 in_position;\n" >>> + "in vec2 in_tex_coord;\n" >> You could calculate the texture coordinate from the position in the >> shader, but this is mostly my premature optimization instinct kicking = in >> instead of a real performance difference considering how few vertices >> there are in this case. > Still makes sense. Done. > >>> + "out vec2 ex_tex_coord;\n" >>> + "\n" >>> + "void main(void) {\n" >>> + " gl_Position =3D vec4(in_position.x, in_position.y, 0.0, 1.0= );\n" >> vec4(in_position, 0.0, 1.0) *cough* > Done. > >> This looks like a list for GL_TRIANGLES instead of GL_TRIANGLE_STRIP. >> For GL_TRIANGLE_STRIP, you first define one whole triangle (by >> specifying each of the three vertices) and after that, each vertex >> results in a new triangle drawn (whose two other vertices are the two >> vertices preceding the last one). > Thanks for the nice description. > > So the trick to get it done with only four vertexes is to put the > correct points (which are going to be shared by both triangles) into th= e > middle. I've played around with it a bit without success (and before m= y > new opengl book arrived), and this 6-point version worked ... Hm, I did write a working solution in my reply, didn't I? It was: { -1,=20 -1, 1, -1, -1, 1, 1, 1 } for in_position[] and { 0, 1, 1, 1, 0,=20 0, 1, 0 } for in_tex_coord[]. At least it worked for me. You haven't (explicitly) enabled face culling, but remember that while=20 normally counter-clockwise faces are backfaces and thus culled, the=20 direction is inverted for every triangle; so the first triangle needs to=20 be CCW, the second CW, the third CCW again, and so on. Maybe that's why=20 it didn't work for you... >>> + glUseProgram(gls->texture_blit_prog); >>> + l_position =3D glGetAttribLocation(gls->texture_blit_prog, "in_p= osition"); >>> + l_tex_coord =3D glGetAttribLocation(gls->texture_blit_prog, "in_= tex_coord"); >>> + glVertexAttribPointer(l_position, 2, GL_FLOAT, GL_FALSE, 0, in_p= osition); >>> + glVertexAttribPointer(l_tex_coord, 2, GL_FLOAT, GL_FALSE, 0, in_= tex_coord); >> I think it is disallowed to refer to non-OpenGL buffers here in the co= re >> profile. The 4.4 core specification states (section 10.3, vertex >> arrays): "Vertex data are placed into arrays that are stored in the >> server=E2=80=99s address space"; the 4.4 compatibility specification s= tates: >> "Vertex data may also be placed into arrays that are stored in the >> client=E2=80=99s address space (described here) or in the server=E2=80= =99s address space". > Got this from gles sample code, so that should be ok ;) > > I've also seen code explicitly storing vertex data in a buffer, which I > assume is more efficient, but I decided to not care for now, especially > given the small number of vertexes we are processing here. > >>> + return gl_create_link_program(vert_shader, frag_shader); >> Minor thing: You are free to delete the shaders after they have been >> linked into the program (because the references will be lost when this >> function returns). > Done. > >>> + switch (surface->format) { >>> + case PIXMAN_BE_b8g8r8x8: >>> + case PIXMAN_BE_b8g8r8a8: >>> + surface->glformat =3D GL_BGRA_EXT; >> If you want to avoid the _EXT, you could use GL_RGBA here and >> texture().bgra in the fragment shader. However, this would require a >> different shader for the 32 bit and the 16 bit formats (because the 16 >> bit format has the right order, apparently). > At least it worked in testing. > >> I haven't been able to really test 16 bit mode (forcing 16 bit mode in >> hw/display/vga.c doesn't count...), so I'm trusting you this works. > -kernel /boot/vmlinux-$whatever -append vga=3D0x314 > > Makes the kernel run vesafb with 800x600 @ 16bpp, and thanks to the > little friendly penguin in the upper left corner (CONFIG_LOGO=3Dy) you = can > easily spot colors being messed up. Thanks! Max