Re: [Mesa-dev] Mesa build fails with xlib/egl
On Sun, Jul 11, 2010 at 1:18 AM, Lionel Landwerlin wrote: > Thanks for your response, it worked well. > > I have another question but first I think I need to give some context. > > I'm trying to build an environment on my laptop which mimics what I'm > going to use on an embedded target. What I expect to find on my embedded > target is a closed source libGL (EGL + GLES2.0) which is bound to the > linux frame buffer interface as native system. Hopefully I will have > access to an SDK which permits to "repackage" the GL library so it will > use x11 as native system. > Also I'm planning to use an X11 compositor to render the different > applications which run on the system, and also I expect applications to > use OpenGL for whatever stuff they need. > > In this scenario, I understand that everyone (including the xserver) > will use direct rendering (which means to me that no one is going to > forward its GL commands to the xserver, but maybe did I misunderstood > something). > > So my question is, how do I build such a system ? To be precise, what > options should I give to the configure script of Mesa ? If you are simulating the environment on your desktop, either egl_dri2 or egl_gallium should satisfy your need. But you need to use a hardware driver. Neither of the EGL drivers supports texture-from-pixmap with a software rasterizer. Both drivers support EGL_KHR_image_pixmap for t-f-p. Only egl_dri2 supports EGL_NOK_texture_from_pixmap. But it is trivial to add EGL_NOK_texture_from_pixmap support to egl_gallium. > Maybe am I wrong about this. Maybe indirect rendering will out perform > direct rendering in such configuration, so anyone comments/advices on > the subject are more than welcome. EGL does not define a protocol for indirect rendering. > Thanks again, > > -- > Lionel Landwerlin > > -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa build fails with xlib/egl
On Tue, Jul 13, 2010 at 9:40 AM, Chia-I Wu wrote: > On Sun, Jul 11, 2010 at 1:18 AM, Lionel Landwerlin > wrote: >> Thanks for your response, it worked well. >> >> I have another question but first I think I need to give some context. >> >> I'm trying to build an environment on my laptop which mimics what I'm >> going to use on an embedded target. What I expect to find on my embedded >> target is a closed source libGL (EGL + GLES2.0) which is bound to the >> linux frame buffer interface as native system. Hopefully I will have >> access to an SDK which permits to "repackage" the GL library so it will >> use x11 as native system. >> Also I'm planning to use an X11 compositor to render the different >> applications which run on the system, and also I expect applications to >> use OpenGL for whatever stuff they need. >> >> In this scenario, I understand that everyone (including the xserver) >> will use direct rendering (which means to me that no one is going to >> forward its GL commands to the xserver, but maybe did I misunderstood >> something). >> >> So my question is, how do I build such a system ? To be precise, what >> options should I give to the configure script of Mesa ? > If you are simulating the environment on your desktop, either egl_dri2 or > egl_gallium should satisfy your need. But you need to use a hardware driver. > Neither of the EGL drivers supports texture-from-pixmap with a software > rasterizer. Ok. But since I want to use a compositor, I need texture-from-pixmap... So this might require some modifications in mesa drivers and other libraries around. *What follows is crappy* My plan was to modify libdrm, so libdrm does not access the drivers anymore. Instead it will allocate buffers from some kind of server (hey looks like wayland?) which just mmaps buffers from files. So all clients/GL applications will be able to access buffers allocated by the X server. At the moment I don't understand the interactions between DRI2 and libdrm, so I don't yet understand how buffers can be accessed from clients. Although I understand how it works with DRI driver in Mesa. Does it make sense ? > > Both drivers support EGL_KHR_image_pixmap for t-f-p. Only egl_dri2 supports > EGL_NOK_texture_from_pixmap. But it is trivial to add > EGL_NOK_texture_from_pixmap support to egl_gallium. >> Maybe am I wrong about this. Maybe indirect rendering will out perform >> direct rendering in such configuration, so anyone comments/advices on >> the subject are more than welcome. > EGL does not define a protocol for indirect rendering. Yes. >> Thanks again, >> >> -- >> Lionel Landwerlin >> >> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa build fails with xlib/egl
On Tue, Jul 13, 2010 at 4:25 PM, Lionel Landwerlin wrote: > On Tue, Jul 13, 2010 at 9:40 AM, Chia-I Wu wrote: >> On Sun, Jul 11, 2010 at 1:18 AM, Lionel Landwerlin >> wrote: >>> Thanks for your response, it worked well. >>> >>> I have another question but first I think I need to give some context. >>> >>> I'm trying to build an environment on my laptop which mimics what I'm >>> going to use on an embedded target. What I expect to find on my embedded >>> target is a closed source libGL (EGL + GLES2.0) which is bound to the >>> linux frame buffer interface as native system. Hopefully I will have >>> access to an SDK which permits to "repackage" the GL library so it will >>> use x11 as native system. >>> Also I'm planning to use an X11 compositor to render the different >>> applications which run on the system, and also I expect applications to >>> use OpenGL for whatever stuff they need. >>> >>> In this scenario, I understand that everyone (including the xserver) >>> will use direct rendering (which means to me that no one is going to >>> forward its GL commands to the xserver, but maybe did I misunderstood >>> something). >>> >>> So my question is, how do I build such a system ? To be precise, what >>> options should I give to the configure script of Mesa ? >> If you are simulating the environment on your desktop, either egl_dri2 or >> egl_gallium should satisfy your need. But you need to use a hardware driver. >> Neither of the EGL drivers supports texture-from-pixmap with a software >> rasterizer. > > Ok. > But since I want to use a compositor, I need texture-from-pixmap... > So this might require some modifications in mesa drivers and other > libraries around. > *What follows is crappy* > My plan was to modify libdrm, so libdrm does not access the drivers > anymore. Instead > it will allocate buffers from some kind of server (hey looks like > wayland?) which just mmaps > buffers from files. So all clients/GL applications will be able to > access buffers allocated by > the X server. > At the moment I don't understand the interactions between DRI2 and > libdrm, so I don't yet > understand how buffers can be accessed from clients. Although I > understand how it works > with DRI driver in Mesa. > Does it make sense ? An alternative is to call XGetImage when a pixmap is bound as a texture. DRI swrast (dri_swrast.so) uses the same trick. >> >> Both drivers support EGL_KHR_image_pixmap for t-f-p. Only egl_dri2 supports >> EGL_NOK_texture_from_pixmap. But it is trivial to add >> EGL_NOK_texture_from_pixmap support to egl_gallium. >>> Maybe am I wrong about this. Maybe indirect rendering will out perform >>> direct rendering in such configuration, so anyone comments/advices on >>> the subject are more than welcome. >> EGL does not define a protocol for indirect rendering. > > Yes. > >>> Thanks again, >>> >>> -- >>> Lionel Landwerlin >>> >>> > -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri/r300: test for FEATURE defines
On Tue, Jul 13, 2010 at 9:57 AM, nobled wrote: > Fixes a fatal build error when compiling just OpenGL ES libraries, since > FEATURE_EXT_framebuffer_blit is disabled then, so the BlitFramebuffer > member doesn't exist. Is this change enough to make dri_r300 function as a GLES only driver? To be honest, I am a little reluctant to sprinkle "#if FEATURE" in the drivers at the moment. The drivers, execept for intel, have not specified GLES api support yet. Even when they do, I would hope there is a more systematic to enable/disable certain features, to effectively reduce the driver size. -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] demos / glew configure bug
I'm setting up the Mesa demos repo on a new system. autogen.sh fails because it can't find GLEW. I think autogen is looking for GLEW in /usr/include/GL/ and /usr/lib/libGLEW.a instead of using the copy of GLEW in the demos tree itself. Dan, can you fix that? $ ./autogen.sh [...] checking pkg-config is at least version 0.9.0... yes checking for GL... yes checking GL/glut.h usability... no checking GL/glut.h presence... no checking for GL/glut.h... no checking for glutInit in -lglut... no checking for GLEW... no checking GL/glew.h usability... no checking GL/glew.h presence... no checking for GL/glew.h... no configure: error: GLEW required -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] demos / glew configure bug
On 07/13/2010 08:07 AM, Brian Paul wrote: I'm setting up the Mesa demos repo on a new system. autogen.sh fails because it can't find GLEW. I think autogen is looking for GLEW in /usr/include/GL/ and /usr/lib/libGLEW.a instead of using the copy of GLEW in the demos tree itself. Dan, can you fix that? $ ./autogen.sh [...] checking pkg-config is at least version 0.9.0... yes checking for GL... yes checking GL/glut.h usability... no checking GL/glut.h presence... no checking for GL/glut.h... no checking for glutInit in -lglut... no checking for GLEW... no checking GL/glew.h usability... no checking GL/glew.h presence... no checking for GL/glew.h... no configure: error: GLEW required Digging deeper... The issue is actually in the configure script (I think). Even after copying libGLEW.a from Mesa 7.8.2 into /usr/lib/libGLEW.a (which is the same as /usr/lib64/) configure is failing: [...] checking pkg-config is at least version 0.9.0... yes checking for GL... yes checking GL/glut.h usability... no checking GL/glut.h presence... no checking for GL/glut.h... no checking for glutInit in -lglut... no checking for GLEW... no checking GL/glew.h usability... yes checking GL/glew.h presence... yes checking for GL/glew.h... yes checking for glewInit in -lGLEW... no configure: error: GLEW required I wrote a test program that just calls glewInit() and compiled it with 'gcc foo.c -lGLEW -lGL -o foo' and it worked fine. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 28790] Improve OpenGL ES 2.0 gears demo
https://bugs.freedesktop.org/show_bug.cgi?id=28790 Alexandros Frantzis changed: What|Removed |Added Attachment #36572|0 |1 is obsolete|| --- Comment #2 from Alexandros Frantzis 2010-07-13 07:43:04 PDT --- Created an attachment (id=36993) View: https://bugs.freedesktop.org/attachment.cgi?id=36993 Review: https://bugs.freedesktop.org/review?bug=28790&attachment=36993 Improve es2gears.c gears demo (version 2) Improve GLES2 port: * Refactor gear drawing. * Use correct normals for surfaces. * Improve shader. * Use perspective projection transformation. * Add FPS count. * Add comments. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] New: GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Summary: GLSL compiler tracker Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: i...@freedesktop.org This is a tracker bug for all issues that we believe will / should be fixed by the glsl2 compiler work. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Ian Romanick changed: What|Removed |Added Depends on||28913, 28839, 28837, 28833, ||28749, 28748, 28374, 28055 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 28913] [GLSL] allowing two version statements
https://bugs.freedesktop.org/show_bug.cgi?id=28913 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Ian Romanick changed: What|Removed |Added Depends on||27914, 27403, 27388, 27349, ||27286, 27265, 27261, 27219, ||27060, 27004, 26990, 26795, ||26224, 26001, 26000, 25999, ||25994, 25878, 25877, 25830, ||25829, 25827, 25826, 25808, ||25769, 25664, 24553, 24355, ||23743, 22622, 21867, 20710, ||19089, 18659, 16856, 16854 Depends on||13753, 10908 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 10908] GLSL: gl_FogParamaters gl_Fog built-in uniform not functioning
https://bugs.freedesktop.org/show_bug.cgi?id=10908 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 13753] Numerous bugs in GLSL uniform handling
https://bugs.freedesktop.org/show_bug.cgi?id=13753 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 16854] GLSL function call at global scope causes SEGV
https://bugs.freedesktop.org/show_bug.cgi?id=16854 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 16856] GLSL indexing of unsized array results in assertion failure
https://bugs.freedesktop.org/show_bug.cgi?id=16856 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 18659] Crash in shader/slang/slang_codegen.c _slang_gen_function_call_name()
https://bugs.freedesktop.org/show_bug.cgi?id=18659 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 21867] Feature request: Configurable pixel origin
https://bugs.freedesktop.org/show_bug.cgi?id=21867 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 24553] shader compilation times explode when using more () pairs
https://bugs.freedesktop.org/show_bug.cgi?id=24553 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 25994] [i915][GLSL] 'return' statement in vertex shader may cause GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=25994 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 26224] [GLSL] Cannot get location of a uniform struct member
https://bugs.freedesktop.org/show_bug.cgi?id=26224 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27261] GLSL Compiler fails on the following vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=27261 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27265] GLSL Compiler doesnt link the attached vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=27265 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27286] Mod function returns wrong value
https://bugs.freedesktop.org/show_bug.cgi?id=27286 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27403] GLSL struct causing "Invalid src register file ..." error
https://bugs.freedesktop.org/show_bug.cgi?id=27403 Ian Romanick changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Bug 29044] New: GLSL compiler tracker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bugzilla-dae...@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=29044 > >Summary: GLSL compiler tracker >Product: Mesa >Version: git > Platform: All > OS/Version: All > Status: NEW > Severity: normal > Priority: medium > Component: Mesa core > AssignedTo: mesa-dev@lists.freedesktop.org > ReportedBy: i...@freedesktop.org > > > This is a tracker bug for all issues that we believe will / should be fixed by > the glsl2 compiler work. I've created a tracker for bugs that should be fixed as part of the new GLSL compiler work. I added all the bugs that came up on the search for "GLSL" that were either core Mesa or trivially i965. I skipped a few r300 and softpipe bugs because I wasn't sure if they were more compiler or driver related. If there are other bugs that you believe are primarily compiler related, feel free to add them to the tracker. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw8jZUACgkQX1gOwKyEAw+OQACfY6JavquIa32FZoIiP3ad3aK/ fzUAnj+GbXjK8YpTPvAQH3tJrPztWvxI =N/Be -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging mesa-2d-registers
On 07/12/2010 09:23 PM, Zack Rusin wrote: Hey, this is relatively simple: Mesa GPU instructions had no way of representing 2D register arrays which was especially painful for things like geometry shaders. It's the same thing Gallium supported for a while meaning INPUT[index1][index2] syntax. So for example gl_PositionIn[index] becomes INPUT[index][gl_PositionIn], so the first index is the index within the array and the second identifies the semantic of the array. This merge finally brings working ARB_geometry_shader4 to Mesa3D! For drivers that use Gallium3D the change means absolutely nothing (of course besides the fact that if the driver had implemented Gallium's geometry shader interface then it gets ARB_geometry_shader4 support for free). There's a nice example called bezier in demos/src/glsl/bezier.c that uses geometry shaders to render a bezier curve. Oh, and also both llvmpipe and softpipe drivers support geometry shaders. Looks great, Zack! Just minor things: A bunch of the shader setup code in bezier.c could probably be replaced by calls to shaderutil.c functions. In struct prog_src_register, a few more comments about the new "2D" fields might be good (what's it for?). We could also use this new index for implementing multiple constant buffers. Perhaps just "2" instead of "2D" would be a better name? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Alex Deucher changed: What|Removed |Added Depends on|27219 | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Ian Romanick changed: What|Removed |Added Depends on||27216 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Bug in _mesa_meta_GenerateMipmap
Dnia poniedziałek 12 lipca 2010 o 23:32:37 Brian Paul napisał(a): > Maciej Cencora wrote: > > Dnia poniedziałek 12 lipca 2010 o 20:31:42 Brian Paul napisał(a): > >> Maciej Cencora wrote: > >>> Hi, > >>> > >>> while working on failing piglit tests I've stumbled on a problem with > >>> _mesa_meta_GenerateMipmap. The function creates new texture images for > >>> lower mipmap levels, but during call to glTexImage the format and type > >>> are hardcoded to GL_RGBA and GL_UNSIGNED_BYTE respectivily. And that's > >>> where the problem arise because base image (the one that other levels > >>> are generated from) could have other format and type specified (in > >>> failing test texturing/gen-teximage these are GL_RGBA, GL_FLOAT). > >>> The result is that for base image MESA_FORMAT_ARGB is chosen and > >>> for next levels it's MESA_FORMAT_RGBA_REV. Of course such texture > >>> with images of different formats is invalid and will be missampled by > >>> GPU. > >>> > >>> As the fix is not straightforward for me (not sure where to get format > >>> and type from, since the gl_texture_image doesn't hold them) could > >>> someone more familiar with core mesa take a look at this? > >> > >> Which driver are you using? > >> > >> I suspect the problem is the driver's ChooseTextureFormat() callback > >> is using more than the 'internalFormat' parameter to choose the actual > >> hardware format (i.e. it's also using the format/type params). Later, > >> when we're building the mipmap we don't know the format/type params > >> used for creating the base image so we just use > >> GL_RGBA/GL_UNSIGNED_BYTE. > >> > >> We could save those original params when glTexImage2D() is called to > >> create the base image, but that would be of no use if the base image > >> was created with glCopyTexImage2D(). > >> > >> We might just be able to "poke" in the actual format for the new image > >> to override whatever was chosen. I'll try to write a patch later... > >> > >> -Brian > > > > I'm using r300 driver. As you suspect the radeonChooseTextureFormat > > (radeon_texture.c) function takes into account format and type to avoid > > unnecessary conversions in TexImage callback. > > Here's a patch to try. Totally untested. > > -Brian It works fine. Unfortunately this solution isn't optimal at least for r100 - r600. During TexImage call memory for texture images is allocated in seperate bo's if they have different format. Later when we want to sample from such texture we need to copy data to one bo (hw needs [BaseLeve, MaxLevel] images to be stored in one continuous block when sampling from texture). I'd propose this patch as a candidate for 7.8 branch. Regards, Maciej ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] mesa-demos 8.0.1
Stable release of mesa-demos Basic documentation and dat file to dist tarball so various example could work. Brian Paul (2): add dissolve to Makefile.am index.html - some basic documentation for this stuff Jerome Glisse (3): demos: add dat file to extra dist bezier: use glew and check for ARB_geometry_shader4 set version for release 8.0.1 Zack Rusin (5): Add a geometry shader example Test the commit script. Add a new example rendering a bezier curve using a geometry shader bezier: add a menu to select the number of subdivisions at runtime bezier: make it also work with nvidia's compiler git tag mesa-demos-8.0.1 ftp://ftp.freedesktop.org/pub/mesa/demos/8.0.1/mesa-demos-8.0.1.tar.bz2 MD5: 320c2a4b6edc6faba35d9cb1e2a30bf4 mesa-demos-8.0.1.tar.bz2 SHA1: 8fc77885ae20f3b9cc22f65045a7573befbde2eb mesa-demos-8.0.1.tar.bz2 ftp://ftp.freedesktop.org/pub/mesa/demos/8.0.1/mesa-demos-8.0.1.tar.gz MD5: 2772e9bf062c5a34a7ea0cdf5cdfefce mesa-demos-8.0.1.tar.gz SHA1: 002059d1cac1b010a5715f5b40d0ab41f329369a mesa-demos-8.0.1.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJMPL2qAAoJEAlK+eqaKjJ1hgAP/3mAENo4IVPoXTAXVsrroMzU sjb75MMHSDsndnRx5pcX2dIvMXOtyLFAfs9j0NO9+wrap29Fb3O+byfaL82u+UHy fKga5J9f/Tspr8oS9ybdM5vydtGMee3EenRCwbvi7FAaiSfURStD9HzmfV8t1VBD JbIMuXyUz7JY0A69qW89IXRuC02SBoHU70VYq/O1oSPJConw5JsG//WGPyNl5Hv5 7mD+0FrUnxkwaQ3HNFT+7YR8SfEbzBsE5D6StRNLcS0TDk4fJ57XqbNHQ0HOW1QB nDisdS44LEiA4ltWX33nVBK9/p8UdjAEy0KOs6Im/8OBjgIg1QaEPblHJTwjFrKQ lv5LMTBfPNo//YwF4fboKUoFwK2HWsURQtOkeUwXMrD8o+EF+RrdPMBULmk0UJNZ cY7ZgXCNN3P1Ea232ae0ssPAafp9xXDPx76vPpzkZodzF1M/CStBYU2QSYEC0OkI sl661YkobPsFDSbRlvEnMq0bkINOXheYlSjsA6IoX3Qhl/kIrfZaq0H4S8kvOAWc kU39PsZ57EUhDvsCYz7kcAhpNh3gZmkhExQkmEbux+N1pd6qRtZnccRES3ZIRiAW HdtYcp+TKdyFNGOkHItS+/X/uIZJs4tKr9yznZy8wG1rvxbUv9JAMt/1tAPcvsKg wDo5Jfr9VPdmNRaewZ9K =RZ+g -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri/r300: test for FEATURE defines
On Tue, Jul 13, 2010 at 3:12 AM, Chia-I Wu wrote: > On Tue, Jul 13, 2010 at 9:57 AM, nobled wrote: >> Fixes a fatal build error when compiling just OpenGL ES libraries, since >> FEATURE_EXT_framebuffer_blit is disabled then, so the BlitFramebuffer >> member doesn't exist. > Is this change enough to make dri_r300 function as a GLES only driver? > > To be honest, I am a little reluctant to sprinkle "#if FEATURE" in the drivers > at the moment. The drivers, execept for intel, have not specified GLES api > support yet. Even when they do, I would hope there is a more systematic to > enable/disable certain features, to effectively reduce the driver size. I'm cool with this, to be honest. GLES support shouldn't be omitted just because most people aren't going to be using GLES on desktops. I'll ack this, but I'll wait for a bit in case there are objections to it. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] mesa-demos licensing/copying file
In order to clarify the licensing of mesa-demos i propose to add the attach copying file. I simply cut/paste the MIT license preserving the close forbidding use of silicon graphics in advertising for the software. I am not a lawyer or anythings close to that so let me know if i did somethings wrong. I think pretty much all the mesa demos author agreed on the MIT license. If i have no objections over the next 2 week i will push the COPYING file. Cheers, Jerome COPYING: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software, and that the name of Silicon Graphics, Inc. not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Optimizations in mesa shader compiler
Hello all, I just looked at the (intermediate) code produced by the shader compiler. In the last version, I did not find anything on constant propagation and constant computations. In the Intel current driver, the final gen code produces an ugly sequence of computations of constant values (known at compile time). I would like to spend some time on it but I am wondering if it is still supported or if other shader compilers are going to replace it. Cheers, Ben ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Optimizations in mesa shader compiler
To be more precise,
- The shader compiler present in src/mesa/slang is used.
- The glsl shader (randomly taken on the net) is:
void main(){
const float PI = 3.14159265358979323846264;
const float angle = 45.0;
const float rad_angle = angle*PI/180.0;
vec4 a = gl_Vertex;
vec4 b = a;
b.x = a.x*cos(rad_angle) - a.y*sin(rad_angle);
b.y = a.y*cos(rad_angle) + a.x*sin(rad_angle);
gl_Position = gl_ModelViewProjectionMatrix*b;
}
- IR Output produced is:
# Vertex Program/Shader 1
0: MOV TEMP[0].x, CONST[0].;
1: MUL TEMP[1].x, CONST[0]., TEMP[0].;
2: RCP TEMP[1].z, CONST[0].;
3: MUL TEMP[0].w, TEMP[1]., TEMP[1].;
4: MOV TEMP[0].z, TEMP[0].;
5: MOV TEMP[1].xz, INPUT[0];
6: MOV TEMP[1].xzw, INPUT[0];
7: COS TEMP[0].w, TEMP[0].;
8: MUL TEMP[2].x, INPUT[0]., TEMP[0].;
9: SIN TEMP[0].w, TEMP[0].;
10: MUL TEMP[2].y, INPUT[0]., TEMP[0].;
11: SUB TEMP[1].x, TEMP[2]., TEMP[2].;
12: COS TEMP[2].x, TEMP[0].;
13: SIN TEMP[2].y, TEMP[0].;
14: MUL TEMP[2].z, INPUT[0]., TEMP[2].;
15: MAD TEMP[2].y, INPUT[0]., TEMP[2]., TEMP[2].;
16: MUL TEMP[0], STATE[2], TEMP[2].;
17: MAD TEMP[2], STATE[1], TEMP[1]., TEMP[0];
18: MAD TEMP[0], STATE[3], TEMP[1]., TEMP[2];
19: MAD TEMP[2], STATE[4], TEMP[1]., TEMP[0];
20: MOV OUTPUT[0], TEMP[2];
21: END
*/
/* Parameters / constants */
/*
dirty state flags: 0x3
param[0] sz=3 CONST (null) = {3.14, 45, 180, 3.14}
param[1] sz=4 STATE state.matrix.mvp.transpose.row[0] = {0, 0, 0, 0}
param[2] sz=4 STATE state.matrix.mvp.transpose.row[1] = {0, 0, 0, 0}
param[3] sz=4 STATE state.matrix.mvp.transpose.row[2] = {0, 0, 0, 0}
param[4] sz=4 STATE state.matrix.mvp.transpose.row[3] = {0, 0, 0, 0}
*/
- Finally, Gen code also includes the constant computations in the shader.
Ben
From: mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org
[mesa-dev-bounces+benjamin.segovia=intel@lists.freedesktop.org] On Behalf
Of Segovia, Benjamin [benjamin.sego...@intel.com]
Sent: Tuesday, July 13, 2010 4:11 PM
To: mesa-dev@lists.freedesktop.org
Subject: [Mesa-dev] Optimizations in mesa shader compiler
Hello all,
I just looked at the (intermediate) code produced by the shader compiler. In
the last version, I did not find anything on constant propagation and constant
computations. In the Intel current driver, the final gen code produces an ugly
sequence of computations of constant values (known at compile time). I would
like to spend some time on it but I am wondering if it is still supported or if
other shader compilers are going to replace it.
Cheers,
Ben
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging mesa-2d-registers
On Tuesday 13 July 2010 12:08:15 Brian Paul wrote: > Looks great, Zack! > > Just minor things: > > A bunch of the shader setup code in bezier.c could probably be > replaced by calls to shaderutil.c functions. Ah, yea, I'll just add something there to be able to link with geometry shader. > In struct prog_src_register, a few more comments about the new "2D" > fields might be good (what's it for?). Done :) > We could also use this new index for implementing multiple constant buffers. Yea, definitely. Plus some hardware seems to prefer when shaders actually declare when temporaries are indexable. In gallium we have the TEMPX register for that, now we could also add support for that (it's the same syntax as multiple const buffers so TEMPX[which array][index]) > Perhaps just "2" instead of "2D" would be a better name? Sounds good to me. I've just changed it. I'll go ahead and merge it now. z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29052] New: [egl] eglGetConfigs should return num of available configs when parameter configs = NULL
https://bugs.freedesktop.org/show_bug.cgi?id=29052 Summary: [egl] eglGetConfigs should return num of available configs when parameter configs = NULL Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: shuang...@intel.com Created an attachment (id=37007) --> (https://bugs.freedesktop.org/attachment.cgi?id=37007) piglit case System Environment: -- Libdrm:(master)2.4.21-13-gb803918f3f77c62edf22e78cb2095be399753423 Mesa: (master)mesa_7_6_1_rc1-9251-gc4066b78c0aad41c199eb27157538c2ec9ab5bfd Xserver: (master)xorg-server-1.8.99.904-26-g3209b094a3b1466b579e8020e12a4f3fa78a5f3f Xf86_video_intel: (master)2.12.0-28-g2267e5928bd90a6997970584462bd97df447e819 Kernel: (for-linus)6f772d7e2f4105470b9f3d0f0b26f06f61b1278d Bug detailed description: - The attached piglit test case could be used to reproduce this issue. According to egl 1.4 spec, "if eglGetConfigs is called with configs = NULL, then no configurations are returned, but the total number of configurations available will be returned in num_config" -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29052] [egl] eglGetConfigs should return num of available configs when parameter configs = NULL
https://bugs.freedesktop.org/show_bug.cgi?id=29052 --- Comment #1 from Shuang He 2010-07-13 18:59:58 PDT --- Created an attachment (id=37008) View: https://bugs.freedesktop.org/attachment.cgi?id=37008 Review: https://bugs.freedesktop.org/review?bug=29052&attachment=37008 Seems this patch works for me -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging mesa-2d-registers
On Tue, Jul 13, 2010 at 6:47 PM, Zack Rusin wrote:
> On Tuesday 13 July 2010 12:08:15 Brian Paul wrote:
>> Looks great, Zack!
>>
>> Just minor things:
>>
>> A bunch of the shader setup code in bezier.c could probably be
>> replaced by calls to shaderutil.c functions.
>
> Ah, yea, I'll just add something there to be able to link with geometry
> shader.
>
>> In struct prog_src_register, a few more comments about the new "2D"
>> fields might be good (what's it for?).
>
> Done :)
>
>> We could also use this new index for implementing multiple constant buffers.
>
> Yea, definitely. Plus some hardware seems to prefer when shaders actually
> declare when temporaries are indexable. In gallium we have the TEMPX register
> for that, now we could also add support for that (it's the same syntax as
> multiple const buffers so TEMPX[which array][index])
>
>> Perhaps just "2" instead of "2D" would be a better name?
>
> Sounds good to me. I've just changed it.
>
> I'll go ahead and merge it now.
I hope you don't mind if I ask some stupid questions:
I'm wondering how this relate to tgsi_src_register::Indirect ("MOV
TEMP[0], TEMP[CONST.x]")?
Cheers Jakob.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merging mesa-2d-registers
On Tuesday 13 July 2010 22:54:08 Jakob Bornecrantz wrote:
> I'm wondering how this relate to tgsi_src_register::Indirect ("MOV
> TEMP[0], TEMP[CONST.x]")?
Well, not too much. Indirection is a method of indexing, while this is about
dimensionality of the registers or in particular adding support for two
dimensional register arrays. So forget what's in the brackets and think number
of brackets.
z
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
