Re: [Mesa-dev] [ANNOUNCE] mesa-demos 8.1.0
> git tag: mesa-demos-8.1.0 > > http://mesa.freedesktop.org/archive/individual/mesa/mesa-demos-8.1.0.tar.bz2 > MD5: 37d7a5af7d7bb517df42dfecad75250c mesa-demos-8.1.0.tar.bz2 > SHA1: 15cf60cc09a85a87c201628b623ca26990a41f2f mesa-demos-8.1.0.tar.bz2 > SHA256: 8f5cce12547ac50347355d91307cc402962531f9e04bec1282c6229e604efa86 > mesa-demos-8.1.0.tar.bz2 > > http://mesa.freedesktop.org/archive/individual/mesa/mesa-demos-8.1.0.tar.gz > MD5: 7eb47284f273d94e5fa23a83117f85cd mesa-demos-8.1.0.tar.gz > SHA1: ecd2cbacb74c9522be5e43b1f01212aad61e778e mesa-demos-8.1.0.tar.gz > SHA256: 482eff9cba3524133202d09d60b1c5d367ec12680b81bebd85f12e20a9e165df > mesa-demos-8.1.0.tar.gz Okay Andreas pointed out the URL are wrong, ftp://freedesktop.org/pub/mesa/demos/8.1.0/mesa-demos-8.1.0.tar.bz2 and ftp://freedesktop.org/pub/mesa/demos/8.1.0/mesa-demos-8.1.0.tar.gz Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] mesa-demos 8.1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 New release of mesa demos repo (8.1.0). I'm mainly releasing this to pick up the newer glxinfo changes for core profiles. But apparantly we haven't released in ages so the log is below! Dave. Aaron Plattner (1): glxgears: Honor -fullscreen in initial reshape Alan Coopersmith (1): Allow builders to specify GLEW_CFLAGS & GLEW_LIBS Alex Wu (2): eglut: Add wayland support opengles2: Add es2gears_wayland target Alexandre Demers (1): glxinfo: add -s flag to print one extension per line Andreas Boll (4): index.html: upgrade from legacy html to HTML 4.01 strict build: add '&component=Demos' to bugzilla link demos: add missing binaries to .gitignore build: require glew 1.5.4 Benjamin Franzke (3): eglkms: Use gbm instead of EGL_MESA_drm_image eglkms: Destroy resources eglkms: Restore saved crtc Brian (1): xdemos: fix a bunch of unused variable warnings Brian Paul (77): updated docs with prerequisites such as glew 1.5.4 or later fp-tri: initialize the texture uniforms trivial: added tri-tex-1d.c test stex3d: print 'f' key info textures: added another filter mode arbocclude2: assorted clean-ups, indenting, etc pointcoord: use 'o' key to toggle point sprite origin spriteblast: added fragment program option openvg: add lion-render.h to SOURCES line-xor: test line drawing in XOR mode mipmap_tunnel: new test to examine mipmap filtering rename clear.c to clear-color.c tri-edgeflag-array: test glEdgeFlagPointer() stex3d: added out-of-memory error checks glxinfo: check for extension support before querying limits shadow_sampler: probe/print pixel value, fix GL version check egl: add compile-time extension checking, use eglGetProcAddress fire: call glutDestroyWindow() simplex-noise: test of GLSL "webgl-noise" noise2: reindent shader for simplex-noise.c demo tests/shader-interp: convert perspective interpolation to linear shader-interp: don't rely on gl_FragCoord.w util: add LinkShaders3() geom-wide-lines, geom-sprites - geometry shader demos shadow-sample: an old GLSL shadow sampler test drawstencil: test writing stencil image with fragment shader geom-wide-lines: add keys to toggle GS on/off, line width geom-sprites: remove dead code, some clean-ups geom-stipple-lines: do line stipple with geometry/fragment shaders arbocclude2: silence some warnings sotest: silence warnings vstest: silence warnings slang/Makefile: add src/util include path bezier: check for GL_ARB_geometry_shader4 extension vp-tris: use larger buffer to handle longer programs mipmap_tunnel: add support for GL_EXT_texture_filter_anisotropic glxinfo: minor whitespace fixes glxinfo: use X Bool, True, False everywhere to be consistent cuberender: demo rendering to cube map faces for environment mapping cuberender: set texture wrap mode to GL_CLAMP_TO_EDGE tests/clip: a simple interactive clipping test trivial/tri-edgeflag-pv: test provoking vertex effect on edge flags linehacks: do stipple, wide, smooth lines with hacks viewmemory: view uninitialized video memory point-sprite: clean-up, set GL_COORD_REPLACE_ARB mode redbook: add missing progs to Makefile.am polys: destroy window before exiting tri-2101010: include glut_wrap.h as other demos do glinfo: query/print GL_SHADING_LANGUAGE_VERSION mipmap_limits: print current params on screen mipmap_limits: fix keyboard info string glxinfo: query/print GL_ARB_framebuffer_object limits wglinfo: query/print GL_ARB_framebuffer_object limits util: add gl_wrap.h and glu_wrap.h to libutil_la_SOURCES util: add GL_FLOAT_MAT4 support, more sampler types shtest: fix docs and code with respect to var names and types geom-outlining: add demo of polygon outlining with a geometry shader rubberband: add a glFlush() call to display the front-buffer drawing fp-tri: s/Display/Draw/ to avoid collision with X Display glsl/identity: clean out unused code arbfslight: re-indent the code trivial: set glClearColor alpha=1.0 glsl/identity: remove more unused stuff cubemap: add some fflush(stdout) calls for Windows mipmap_limits: add some fflush(stdout) calls for Windows clear-fbo: clean-up the code, print pixel color for debugging clear-fbo: call fflush(stdout) for Windows add missing programs to trivial/Makefile.am geom-stipple-lines: use a float[16] uniform for the pattern line-smooth: add flat/smooth shading control shtest: allow compiling only a VS or only a FS trivial/tri-z-clip: test near/far triangle clipping glxinfo: add support for creating/querying core-profile conte
[Mesa-dev] [Bug 61417] Clover doesn't export the OPENCL_1.0 Symbol
https://bugs.freedesktop.org/show_bug.cgi?id=61417 Francisco Jerez changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Francisco Jerez --- I don't think that an OpenCL-compliant implementation is required to do that... I might be wrong though. Can you provide a reference to some specification document discussing this topic? -- 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 61415] Clover ignores --with-opencl-libdir path
https://bugs.freedesktop.org/show_bug.cgi?id=61415 --- Comment #1 from Francisco Jerez --- It isn't supposed to do that, use "--libdir" to change the installation path of libOpenCL.so, "--with-opencl-libdir" just sets the installation path of the auxiliary libraries that are used internally by the OpenCL implementation. I guess the parameter description is a bit unclear about this, I'll fix it... -- 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] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!
Hi All, The final spec has had enum values assigned and been published on Khronos: http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt Thanks to all who've provided input. Cheers, Tom > -Original Message- > From: mesa-dev-bounces+tom.cooksey=arm@lists.freedesktop.org > [mailto:mesa-dev- > bounces+tom.cooksey=arm@lists.freedesktop.org] On Behalf Of Tom Cooksey > Sent: 04 October 2012 13:10 > To: mesa-dev@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; dri- > de...@lists.freedesktop.org; linux-me...@vger.kernel.org > Subject: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - New draft! > > Hi All, > > After receiving a fair bit of feedback (thanks!), I've updated the > EGL_EXT_image_dma_buf_import spec > and expanded it to resolve a number of the issues. Please find the latest > draft below and let > me > know any additional feedback you might have, either on the lists or by > private e-mail - I > don't mind > which. > > I think the only remaining issue now is if we need a mechanism whereby an > application can > query > which drm_fourcc.h formats EGL supports or if just failing with EGL_BAD_MATCH > when the > application > has use one EGL doesn't support is sufficient. Any thoughts? > > > Cheers, > > Tom > > > 8< > > > Name > > EXT_image_dma_buf_import > > Name Strings > > EGL_EXT_image_dma_buf_import > > Contributors > > Jesse Barker > Rob Clark > Tom Cooksey > > Contacts > > Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org) > Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com) > > Status > > DRAFT > > Version > > Version 4, October 04, 2012 > > Number > > EGL Extension ??? > > Dependencies > > EGL 1.2 is required. > > EGL_KHR_image_base is required. > > The EGL implementation must be running on a Linux kernel supporting the > dma_buf buffer sharing mechanism. > > This extension is written against the wording of the EGL 1.2 > Specification. > > Overview > > This extension allows creating an EGLImage from a Linux dma_buf file > descriptor or multiple file descriptors in the case of multi-plane YUV > images. > > New Types > > None > > New Procedures and Functions > > None > > New Tokens > > Accepted by the parameter of eglCreateImageKHR: > > EGL_LINUX_DMA_BUF_EXT > > Accepted as an attribute in the parameter of > eglCreateImageKHR: > > EGL_LINUX_DRM_FOURCC_EXT > EGL_DMA_BUF_PLANE0_FD_EXT > EGL_DMA_BUF_PLANE0_OFFSET_EXT > EGL_DMA_BUF_PLANE0_PITCH_EXT > EGL_DMA_BUF_PLANE1_FD_EXT > EGL_DMA_BUF_PLANE1_OFFSET_EXT > EGL_DMA_BUF_PLANE1_PITCH_EXT > EGL_DMA_BUF_PLANE2_FD_EXT > EGL_DMA_BUF_PLANE2_OFFSET_EXT > EGL_DMA_BUF_PLANE2_PITCH_EXT > EGL_YUV_COLOR_SPACE_HINT_EXT > EGL_SAMPLE_RANGE_HINT_EXT > EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT > EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT > > Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute: > > EGL_ITU_REC601_EXT > EGL_ITU_REC709_EXT > EGL_ITU_REC2020_EXT > > Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute: > > EGL_YUV_FULL_RANGE_EXT > EGL_YUV_NARROW_RANGE_EXT > > Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT & > EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes: > > EGL_YUV_CHROMA_SITING_0_EXT > EGL_YUV_CHROMA_SITING_0_5_EXT > > > Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation) > > Add to section 2.5.1 "EGLImage Specification" (as defined by the > EGL_KHR_image_base specification), in the description of > eglCreateImageKHR: > >"Values accepted for are listed in Table aaa, below. > > +-++ > | | Notes | > +-++ > | EGL_LINUX_DMA_BUF_EXT | Used for EGLImages imported from Linux | > | | dma_buf file descriptors | > +-++ >Table aaa. Legal values for eglCreateImageKHR parameter > > ... > > If is EGL_LINUX_DMA_BUF_EXT, must be a valid display, > must be EGL_NO_CONTEXT, and must be NULL, cast into the type > EGLClientBuffer. The details of the image is specified by the attributes > passed into eglCreateImageKHR. Required attributes and their values are as > follows: > > * EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in > pixels > > * EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as > specified > by drm_f
[Mesa-dev] [Bug 61415] Clover ignores --with-opencl-libdir path
https://bugs.freedesktop.org/show_bug.cgi?id=61415 Mike Lothian changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #2 from Mike Lothian --- Doesn't --libdir change the installation directory for all libraries not just the OpenCL ones? -- 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 61417] Clover doesn't export the OPENCL_1.0 Symbol
https://bugs.freedesktop.org/show_bug.cgi?id=61417 Mike Lothian changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #2 from Mike Lothian --- I have no idea about the spec - I was just trying to bench mark Clover to compare it against other implementations I'm not sure if it's strictly required but I'm guessing all the other ones that have been bench marked have this symbol -- 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 61415] Clover ignores --with-opencl-libdir path
https://bugs.freedesktop.org/show_bug.cgi?id=61415 --- Comment #3 from Francisco Jerez --- (In reply to comment #2) > Doesn't --libdir change the installation directory for all libraries not > just the OpenCL ones? Yes, exactly. -- 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] [PATCH] draw: make sure pipeline is revalidated when sampler views or samplers change.
- Original Message - > From: Roland Scheidegger > > Since with llvm execution parts of sampler view and sampler state is baked > into > the shader, we need to revalidate otherwise the wrong shader might get used. > (Not completely sure but I think this would not be required for non-llvm > case, > along with everything else in these functions.) > This caused bugs in piglit arb_texture_buffer_object-formats, because we > never > noticed that the view format changed. > --- > src/gallium/auxiliary/draw/draw_context.c |4 > src/gallium/auxiliary/gallivm/lp_bld_sample.c |3 ++- > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/auxiliary/draw/draw_context.c > b/src/gallium/auxiliary/draw/draw_context.c > index c2b6851..528543b 100644 > --- a/src/gallium/auxiliary/draw/draw_context.c > +++ b/src/gallium/auxiliary/draw/draw_context.c > @@ -764,6 +764,8 @@ draw_set_sampler_views(struct draw_context *draw, > debug_assert(shader_stage < PIPE_SHADER_TYPES); > debug_assert(num <= PIPE_MAX_SHADER_SAMPLER_VIEWS); > > + draw_do_flush( draw, DRAW_FLUSH_STATE_CHANGE ); > + > for (i = 0; i < num; ++i) >draw->sampler_views[shader_stage][i] = views[i]; > for (i = num; i < PIPE_MAX_SHADER_SAMPLER_VIEWS; ++i) > @@ -783,6 +785,8 @@ draw_set_samplers(struct draw_context *draw, > debug_assert(shader_stage < PIPE_SHADER_TYPES); > debug_assert(num <= PIPE_MAX_SAMPLERS); > > + draw_do_flush( draw, DRAW_FLUSH_STATE_CHANGE ); > + > for (i = 0; i < num; ++i) >draw->samplers[shader_stage][i] = samplers[i]; > for (i = num; i < PIPE_MAX_SAMPLERS; ++i) > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample.c > b/src/gallium/auxiliary/gallivm/lp_bld_sample.c > index 5322397..ef0631c 100644 > --- a/src/gallium/auxiliary/gallivm/lp_bld_sample.c > +++ b/src/gallium/auxiliary/gallivm/lp_bld_sample.c > @@ -117,7 +117,8 @@ lp_sampler_static_texture_state(struct > lp_static_texture_state *state, > state->level_zero_only = !view->u.tex.last_level; > > /* > -* FIXME: Handle the remainder of pipe_sampler_view. > +* the layer / element / level parameters are all either dynamic > +* state or handled transparently wrt execution. > */ > } > > -- > 1.7.9.5 > Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: status of my work on the shader optimization
On 02/24/2013 11:25 PM, Vadim Girlin wrote: On 02/24/2013 11:01 PM, Henri Verbeet wrote: On 24 February 2013 17:07, Vadim Girlin wrote: If you'd like to help me with debugging the issues on cayman, then please read the "regression debugging" section in the r600-sb branch notes [1] (or possibly more up-to-date source here - [2]), it explains how to find the exact shader that causes regression. After locating the guilty shader, you only need to prepend R600_DUMP_SHADERS=2 R600_SB_DUMP=3 to the command line to produce the full dump for that shader, then please send it to me, and I'll do my best to fix the issue. I briefly looked at it yesterday, but ran out of time. I did find out that all of the failures except one (in loop_index_test()) go away if I skip the if-conversion pass. I have the impression that the PRED_SET* instructions like PRED_SETNE_INT don't behave quite the way the ISA docs claim they do wrt. the value written to the destination register, but instead seem to behave more like the regular SET* instructions in that regard. I didn't properly test this, so it's more of a theory at this point, and may just be wrong. Of course we don't really want to use the PRED_SET* instructions to begin with if we're not going to actually use the predicate, so we'll probably just want to convert them to SET* instructions anyway. Yeah, I see now, I missed the fact that PRED_SETcc instructions on cayman can't be used as simple ALU instructions without side effects, they always update exec_mask. Well, it seems I misunderstood the docs, in fact PRED_SET instructions can be used when UPDATE_EXEC_MASK=0. I just thought that ALU_WORD1_OP2_EXECUTE_MASK encoding is always used with them, and in the description of this encoding value 0 for UPDATE_EXEC_MASK is marked as "reserved", so I thought that they should always have UPDATE_EXEC_MASK=1. Now I think you are right and probably the cause is that the value written to dst register is not what I expect. Anyway, I think the best solution is still the same as you mentioned - get rid of PRED_SETcc instructions when the update of exec mask or predicate is not required. Vadim Somewhat related to that, wined3d generates GLSL of the form "dst = (src0 < src1) ? 1.0 : 0.0;" for the D3D "slt" instruction (and similar code for instructions like sge, etc.). The TGSI for that looks pretty awful, first doing a SLT, converting the result to an integer, and then branching on that to assign either 1.0 or 0.0 again. The if-conversion pass is fairly helpful there in the sense that it at least gets rid of the branches, but you still end up with a sequence like SETGE, FLT_TO_INT, PRED_SETNE_INT, CNDE_INT, while all that's really needed is the SETGE. That's probably best addressed in either the GLSL compiler or the GLSL -> TGSI stage though. I just implemented the simplest way of if-conversion for now, but the first thing that I'm going to add to the (currently empty) peephole pass is the optimization of SETcc, PRED_SETcc, etc, including the conversions between float/int bools, to get rid of all unnecessary operations. Unfortunately I won't be able to test with that system again until at least Thursday, so it'll be a while before I can actually do anything about it. Well, I see the problem now, so there is no need for any special testing until I'll implement something to fix it. Anyway, you helped me to understand what's wrong, thanks. Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61415] Clover ignores --with-opencl-libdir path
https://bugs.freedesktop.org/show_bug.cgi?id=61415 --- Comment #4 from Mike Lothian --- Out of interest what are the auxiliary libraries? As I'm not getting anything in that directory -- 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] Khronos Conformance test
Hi, We have run the Khronos test suite on for OpenGLES2.0. There are few failures in the GL tests because of the difference in the images generated. We have found that the images generated using our development board are good in quality rather than the reference images generated. This is the case with acos, asin and sin. We would like to know how the conformance of the OpenGLES2.0 would be decided for the corresponding tests. Regards Mahesh CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61318] Can't compile GLU 32bit on 64bit
https://bugs.freedesktop.org/show_bug.cgi?id=61318 --- Comment #6 from Alexandre Demers --- (In reply to comment #5) > This sounds to me like a libtool issue, bug #50754 has possible fix you > could try for this. For now, I'm just setting PKG_CONFIG_PATH to the 32 bit or the 64 bit path as needed. However, I know by default both my paths are set in the PKG_CONFIG_PATH variable and I was a trick I used to fix a similar problem with mesa. -- 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 61412] glCallLists performance extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #1 from Brian Paul --- glBitmap, not glCallLists, is probably the real issue. It might be helpful to see the "OpenGL renderer string" from glxinfo to identify the GPU. I suspect the i965 driver needs some sort of glBitmap caching mechanism (similar to what's in the gallium state tracker) to improve performance. -- 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 61395] glEdgeFlag can't be set to false
https://bugs.freedesktop.org/show_bug.cgi?id=61395 --- Comment #1 from Brian Paul --- This patch should fix it. Posted for review. diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py index 1b7d6ad..ff6e108 100644 --- a/src/mesa/main/get_hash_params.py +++ b/src/mesa/main/get_hash_params.py @@ -412,7 +412,7 @@ descriptor=[ [ "DEPTH_SCALE", "CONTEXT_FLOAT(Pixel.DepthScale), NO_EXTRA" ], [ "DOUBLEBUFFER", "BUFFER_INT(Visual.doubleBufferMode), NO_EXTRA" ], [ "DRAW_BUFFER", "BUFFER_ENUM(ColorDrawBuffer[0]), NO_EXTRA" ], - [ "EDGE_FLAG", "LOC_CUSTOM, TYPE_BOOLEAN, 0, NO_EXTRA" ], + [ "EDGE_FLAG", "LOC_CUSTOM, TYPE_BOOLEAN, 0, extra_flush_current" ], [ "FEEDBACK_BUFFER_SIZE", "CONTEXT_INT(Feedback.BufferSize), NO_EXTRA" ], [ "FEEDBACK_BUFFER_TYPE", "CONTEXT_ENUM(Feedback.Type), NO_EXTRA" ], [ "FOG_INDEX", "CONTEXT_FLOAT(Fog.Index), NO_EXTRA" ], -- 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] [PATCH] mesa: flush current state when querying GL_EDGE_FLAG
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=61395 Note: This is a candidate for the stable branches. --- src/mesa/main/get_hash_params.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py index 1b7d6ad..ff6e108 100644 --- a/src/mesa/main/get_hash_params.py +++ b/src/mesa/main/get_hash_params.py @@ -412,7 +412,7 @@ descriptor=[ [ "DEPTH_SCALE", "CONTEXT_FLOAT(Pixel.DepthScale), NO_EXTRA" ], [ "DOUBLEBUFFER", "BUFFER_INT(Visual.doubleBufferMode), NO_EXTRA" ], [ "DRAW_BUFFER", "BUFFER_ENUM(ColorDrawBuffer[0]), NO_EXTRA" ], - [ "EDGE_FLAG", "LOC_CUSTOM, TYPE_BOOLEAN, 0, NO_EXTRA" ], + [ "EDGE_FLAG", "LOC_CUSTOM, TYPE_BOOLEAN, 0, extra_flush_current" ], [ "FEEDBACK_BUFFER_SIZE", "CONTEXT_INT(Feedback.BufferSize), NO_EXTRA" ], [ "FEEDBACK_BUFFER_TYPE", "CONTEXT_ENUM(Feedback.Type), NO_EXTRA" ], [ "FOG_INDEX", "CONTEXT_FLOAT(Fog.Index), NO_EXTRA" ], -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] New EGL extension: EGL_EXT_platform_display
On 02/24/2013 11:46 PM, Pekka Paalanen wrote:> On Tue, 19 Feb 2013 08:20:51 -0800 > Chad Versace wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I'm seeking feedback on an EGL extension that I'm drafting. The ideas have >> already been discussed at Khronos meetings to a good reception, but I want >> feedback from Mesa developers too. >> >> Summary >> - --- >> The extension, tentatively named EGL_EXT_platform_display, enables EGL >> clients >> to specify to which platform (X11, Wayland, gbm, etc) an EGL resource >> (EGLDisplay, EGLSurface, etc) belongs when the resource is derived from >> a platform-native type. As a corollary, the extension enables the creation of >> EGL resources from different platforms within a single process. >> >> >> Feedback >> - >> I'd like to hear feeback about the details below. Do you see any potential >> problems? Is it lacking a feature that you believe should be present? >> >> >> Details >> - --- >> The draft extension defines the following new functions: >> >> // This is the extenion's key function. >> // >> EGLDisplay >> eglGetPlatformDisplayEXT(EGLenum platform, void *native_display); >> >> // The two eglCreate functions below differ from their core counterparts >> // only in their signature. The EGLNative types are replaced with void*. >> // This makes the signature agnostic to which platform the native >> resource >> // belongs. >> >> EGLSurface >> eglCreatePlatformWindowSurfaceEXT(EGLDisplay dpy, >> EGLConfig config, >> void *native_window, >> const EGLint *attrib_list); >> >> EGLSurface >> eglCreatePlatformPixmapSurface(EGLDisplay dpy, >>EGLConfig config, >>void *native_pixmap, >>const EGLint *attrib_list); >> >> Valid values for `platform` are defined by layered extensions. For >> example, EGL_EXT_platform_x11 defines EGL_PLATFORM_X11, and >> EGL_EXT_platform_wayland defines EGL_PLATFORM_WAYLAND. >> >> Also, the layered extensions specify which native types should be passed as >> the native parameters. For example, EGL_EXT_platform_wayland specifies that, >> when calling eglCreatePlatformWindowSurfaceEXT with a display that was >> derived >> from a Wayland display, then the native_window parameter must be `struct >> wl_egl_window*`. Analogously, EGL_EXT_platform_x11 specifies that >> native_window must be `Window*`. >> >> >> Example Code for X11 >> - >> // The internal representation of the egl_dpy, created below, remembers that >> // it was derived from an Xlib display. >> >> Display *xlib_dpy = XOpenDisplay(NULL); >> EGLDisplay *egl_dpy = eglGetPlatformDisplayEXT(EGL_PLATFORM_X11, xlib_dpy); >> >> EGLConfig config; >> eglChooseConfig(egl_dpy, &config, ...); >> >> // Since egl_dpy remembers that it was derived from an Xlib display, when >> // creating the EGLSurface below libEGL internally casts the >> // `(void*) &xlib_win` to `Window*`. >> >> Window xlib_win = XCreateWindow(xlib_dpy, ...); >> EGLSurface egl_surface = eglCreatePlatformWindowSurfaceEXT(egl_dpy, config, >>(void*) &xlib_win, >>NULL); >> >> Example Code for Wayland >> - >> // The internal representation of the egl_dpy, created below, remembers that >> // it was derived from a Wayland display. >> >> struct wl_display *wl_dpy = wl_display_connect(NULL); >> EGLDisplay *egl_dpy = eglGetPlatformDisplay(EGL_PLATFORM_WAYLAND, wl_dpy); >> >> >> EGLConfig config; >> eglChooseConfig(egl_dpy, &config, ...); >> >> // Since egl_dpy remembers that it was derived from an Wayland display, when >> // creating the EGLSurface below libEGL internally casts the >> // `(void*) wl_win` to `struct wl_egl_window*`. >> >> struct wl_egl_window *wl_win = wl_egl_window_create(...); >> EGLSurface egl_surface = eglCreateWindowSurface(egl_dpy, config, >>(void*) wl_win, NULL); > > Hi, > > is it possible to build a binary, that will use this extension if it is > present in whatever libEGL is available at runtime, and if it is not, > fall back gracefully to using the core eglGetDisplay()? > > Or is this specifically not supported, since I cannot see a way for > runtime detection of this extension? > > Or is the runtime detection left unspecified, so one could do it with > e.g. getting eglGetPlatformDisplay via dlsym()? > > Just a question that popped in my mind, since there were no comments > toward that topic. Thanks for asking this question. I neglected to address the topic of runtime detection, despite it coming it up in face-to-face conversation multiple times. The function must be exposed with eglGetProcAddr
Re: [Mesa-dev] [PATCH] mesa: flush current state when querying GL_EDGE_FLAG
- Original Message - > Fixes http://bugs.freedesktop.org/show_bug.cgi?id=61395 > > Note: This is a candidate for the stable branches. > --- > src/mesa/main/get_hash_params.py |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/mesa/main/get_hash_params.py > b/src/mesa/main/get_hash_params.py > index 1b7d6ad..ff6e108 100644 > --- a/src/mesa/main/get_hash_params.py > +++ b/src/mesa/main/get_hash_params.py > @@ -412,7 +412,7 @@ descriptor=[ >[ "DEPTH_SCALE", "CONTEXT_FLOAT(Pixel.DepthScale), NO_EXTRA" ], >[ "DOUBLEBUFFER", "BUFFER_INT(Visual.doubleBufferMode), NO_EXTRA" ], >[ "DRAW_BUFFER", "BUFFER_ENUM(ColorDrawBuffer[0]), NO_EXTRA" ], > - [ "EDGE_FLAG", "LOC_CUSTOM, TYPE_BOOLEAN, 0, NO_EXTRA" ], > + [ "EDGE_FLAG", "LOC_CUSTOM, TYPE_BOOLEAN, 0, extra_flush_current" ], >[ "FEEDBACK_BUFFER_SIZE", "CONTEXT_INT(Feedback.BufferSize), NO_EXTRA" ], >[ "FEEDBACK_BUFFER_TYPE", "CONTEXT_ENUM(Feedback.Type), NO_EXTRA" ], >[ "FOG_INDEX", "CONTEXT_FLOAT(Fog.Index), NO_EXTRA" ], > -- > 1.7.3.4 Reviewed-by: Jose Fonseca ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] improve gles2 conformance on android
On 02/20/2013 03:00 AM, Tapani Pälli wrote: > Following changes improve gles2 conformance on android. There are > additional failures related to sampling but those will be dealt later. > > Tapani Pälli (2): > mesa: add missing case in _mesa_GetTexParameterfv() > mesa/es: NULL check in EGLImageTargetTexture2DOES > > src/mesa/main/teximage.c | 6 ++ > src/mesa/main/texparam.c | 6 ++ > 2 files changed, 12 insertions(+) > Reviewed-by: Chad Versace Patches are now committed. Thanks. Also, for small fixes like this please add one of the tags below to the commit message. Otherwise, the maintainers won't cherry-pick your fixes to the bugfix releases. Note: This is a candidate for the stable branches. Note: This is a candidate for the X.Y branch. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] remove mfeatures.h file
Reviewed-by: Jordan Justen On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote: > This series removes the dependencies on the mfeatures.h file and the file > itself. > > I'd appreciated someone doing a test build of this series to double-check my > work. Do you have a public repo where you push changesets like this? -Jordan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Khronos Conformance test
On Mon, Feb 25, 2013 at 6:13 AM, Alle Mahesh wrote: > > Hi, > > > > > > We have run the Khronos test suite on for OpenGLES2.0. There are few failures > in the GL tests because of the difference in the images generated. > > We have found that the images generated using our development board are good > in quality rather than the reference images generated. A good quality image is one which passes the test. > This is the case with acos, asin and sin. We would like to know how the > conformance of the OpenGLES2.0 would be decided for the corresponding tests. Conformance tests for OpenGL ES 2.0 follow the specification and verify that GL implementation follow it too. If you think conformance test is testing something not specified in ES 2.0 spec, file a bug at https://cvs.khronos.org/bugzilla. HTH Anuj > > Regards > > Mahesh > > CAUTION - Disclaimer * > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > notify the sender by e-mail and delete the original message. Further, you are > not > to copy, disclose, or distribute this e-mail or its contents to any other > person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has > taken > every reasonable precaution to minimize this risk, but is not liable for any > damage > you may sustain as a result of any virus in this e-mail. You should carry out > your > own virus checks before opening the e-mail or attachment. Infosys reserves the > right to monitor and review the content of all messages sent to or from this > e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS End of Disclaimer INFOSYS*** > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61455] New: Feature request: implement wglMakeContextCurrentARB in Gallium
https://bugs.freedesktop.org/show_bug.cgi?id=61455 Priority: medium Bug ID: 61455 Assignee: mesa-dev@lists.freedesktop.org Summary: Feature request: implement wglMakeContextCurrentARB in Gallium Severity: normal Classification: Unclassified OS: Windows (All) Reporter: keith.kriew...@attachmate.com Hardware: All Status: NEW Version: 9.0 Component: Mesa core Product: Mesa Please implement wglMakeContextCurrentARB in the Gallium state-tracker. The declaration would be at: /gallium/state_trackers/wgl/stw_getprocaddress.c stw_extension_entries[] : /* WGL_ARB_make_current_read */ STW_EXTENSION_ENTRY( wglMakeContextCurrentARB ), We have a need for support of glXMakeContextCurrent in the Gallium software renderers (softpipe and/or llvmpipe). Specification docs: (GLX 1.3, GL 1.2) http://www.opengl.org/sdk/docs/man2/xhtml/glXMakeContextCurrent.xml (WGL) http://www.opengl.org/registry/specs/ARB/wgl_make_current_read.txt -- 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 61412] glCallLists performance extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #2 from Kenneth Graunke --- Yeah, I think we're relying on the meta path for glBitmap in many cases. We're probably hitting software rasterization. Still, 120 fps -> 8 fps is clearly not reasonable. What generation of Intel hardware are you running? (lspci -nn would tell you.) Can you post an apitrace which exhibits the problem? -- 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] Khronos Conformance test
On Mon, Feb 25, 2013 at 02:13:59PM +, Alle Mahesh wrote: > Hi, > > > We have run the Khronos test suite on for OpenGLES2.0. There are few failures > in the GL tests because of the difference in the images generated. > > We have found that the images generated using our development board are good > in quality rather than the reference images generated. This is the case with > acos, asin and sin. We would like to know how the conformance of the > OpenGLES2.0 would be decided for the corresponding tests. Hi Mahesh, OpenGLES 2.0 defines precision qualifiers (e.g. highp, mediump, lowp) that specify the desired precision for a floating-point result. If the images your driver produces are higher quality images than the reference images, then it's likely that your driver is not handling the precision qualifier correctly. -Tom > > Regards > Mahesh > > CAUTION - Disclaimer * > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > notify the sender by e-mail and delete the original message. Further, you are > not > to copy, disclose, or distribute this e-mail or its contents to any other > person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has > taken > every reasonable precaution to minimize this risk, but is not liable for any > damage > you may sustain as a result of any virus in this e-mail. You should carry out > your > own virus checks before opening the e-mail or attachment. Infosys reserves the > right to monitor and review the content of all messages sent to or from this > e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS End of Disclaimer INFOSYS*** > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] egl: Allow 24-bit visuals for 32-bit RGBA8888 configs
From: Ian Romanick Previously only the 32-bit X visual would match the 32-bit RGBA configs. This resulted in every config with alpha getting the "magic" visual whose alpha is used by the compositor. This also resulted in no multisample visuals being advertised. How many ways could we lose? This patch inverts the problem... now you can't get the visual with alpha used by the compositor even if you want it. I think we need to invent a new value for EGL_TRANSPARENT_TYPE that apps can use to get this. I'm surprised that there isn't already a choice for EGL_TRANSPARENT_ALPHA. Signed-off-by: Ian Romanick Tested-by: Tian Ye Cc: Kristian Høgsberg Cc: Chad Versace Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59783 --- src/egl/drivers/dri2/egl_dri2.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index ae842d7..5d00e4f 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -195,7 +195,14 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig *dri_config, int id, for (i = 0; attr_list[i] != EGL_NONE; i += 2) _eglSetConfigKey(&base, attr_list[i], attr_list[i+1]); - if (depth > 0 && depth != base.BufferSize) + /* Allow a 24-bit RGB visual to match a 32-bit RGBA fbconfig. Otherwise it +* will only match a 32-bit RGBA visual. On a composited window manager on +* X11, this will make all of the fbconfigs with destination alpha get +* blended by the compositor. This is probably not what the application +* wants... especially on drivers that only have 32-bit RGBA fbconfigs! +*/ + if (depth > 0 && + !(depth == base.BufferSize || (depth == 24 && base.BufferSize == 32))) return NULL; if (rgba_masks && memcmp(rgba_masks, dri_masks, sizeof(dri_masks))) -- 1.7.11.7 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Khronos Conformance test
On 02/25/2013 06:13 AM, Alle Mahesh wrote: Hi, We have run the Khronos test suite on for OpenGLES2.0. There are few failures in the GL tests because of the difference in the images generated. We have found that the images generated using our development board are good in quality rather than the reference images generated. This is the case with acos, asin and sin. We would like to know how the conformance of the OpenGLES2.0 would be decided for the corresponding tests. These tests have some known with very large window sizes. Otherwise, your implementation just isn't good enough. Regards Mahesh CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. Seriously. This is bullshit. Get a gmail account. ***INFOSYS End of Disclaimer INFOSYS*** ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61299] LLVM 3.2 fails to link with Mesa 9.0.2 on Windows; missing link libraries
https://bugs.freedesktop.org/show_bug.cgi?id=61299 José Fonseca changed: What|Removed |Added CC||jfons...@vmware.com --- Comment #1 from José Fonseca --- You saw this problem with LLVM 3.2, but the code you suggest changing also applies to LLVM 3.0 and 3.1. Are you sure this is correct. That is, that this won't cause problems with 3.0 / 3.1? -- 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] [PATCH 5/9] glapi: remove FEATURE_remap_table test (it's always defined)
On 02/23/2013 07:26 AM, Brian Paul wrote: --- src/mapi/glapi/gen/gl_table.py | 15 --- 1 files changed, 0 insertions(+), 15 deletions(-) diff --git a/src/mapi/glapi/gen/gl_table.py b/src/mapi/glapi/gen/gl_table.py index 382eaaf..99957f6 100644 --- a/src/mapi/glapi/gen/gl_table.py +++ b/src/mapi/glapi/gen/gl_table.py @@ -147,17 +147,6 @@ class PrintRemapTable(gl_XML.gl_print_base): for f, index in abi_functions: print '#define _gloffset_%s %d' % (f.name, f.offset) -print '' -print '#if !FEATURE_remap_table' -print '' - -for f, index in functions: -print '#define _gloffset_%s %d' % (f.name, f.offset) - Even for non-DRI builds? -print '' -print '#else /* !FEATURE_remap_table */' -print '' - if self.es: remap_table = "esLocalRemapTable" @@ -180,8 +169,6 @@ class PrintRemapTable(gl_XML.gl_print_base): print '#define _gloffset_%s %s[%s_remap_index]' % (f.name, remap_table, f.name) print '' -print '#endif /* !FEATURE_remap_table */' -print '' for f, index in abi_functions + functions: arg_string = gl_XML.create_parameter_string( f.parameters, 0 ) @@ -209,12 +196,10 @@ class PrintRemapTable(gl_XML.gl_print_base): print '#define SET_%s(disp, fn) SET_%s(disp, fn)' % (name, f.name) print '' -print '#if FEATURE_remap_table' for f in alias_functions: for name in f.entry_points: if name != f.name: print '#define %s_remap_index %s_remap_index' % (name, f.name) -print '#endif /* FEATURE_remap_table */' print '' return ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] remove mfeatures.h file
On 02/23/2013 07:29 AM, Brian Paul wrote: This series removes the dependencies on the mfeatures.h file and the file itself. I'd appreciated someone doing a test build of this series to double-check my work. The last thing left to do is remove the -DFEATURE_GL/ES1/ES2 stuff from the autoconf and scons files. There are some FEATURE_ES[12] in src/mesa/drivers/dri/intel/intel_screen.c too. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61299] LLVM 3.2 fails to link with Mesa 9.0.2 on Windows; missing link libraries
https://bugs.freedesktop.org/show_bug.cgi?id=61299 --- Comment #2 from Keith Kriewall --- No, I have not investigated LLVM 3.0 or 3.1 to see if the same libraries need to be specified for them. I only mentioned what I did as a workaround with the 3.2 source. A safer permanent solution would be to add a new version block in llvm.py for 3.2 or higher. -Keith -- 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] [PATCH 02/14] mesa: Replace open-coded _mesa_lookup_enum_by_nr().
On 02/22/2013 07:52 PM, Eric Anholt wrote:
---
src/mesa/main/errors.c | 38 +++---
1 file changed, 3 insertions(+), 35 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index 761b555..987cddb 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -29,7 +29,7 @@
#include "errors.h"
-
+#include "enums.h"
#include "imports.h"
#include "context.h"
#include "dispatch.h"
@@ -836,38 +836,6 @@ output_if_debug(const char *prefixString, const char
*outputString,
}
}
-
-/**
- * Return string version of GL error code.
- */
-static const char *
-error_string( GLenum error )
-{
- switch (error) {
- case GL_NO_ERROR:
- return "GL_NO_ERROR";
- case GL_INVALID_VALUE:
- return "GL_INVALID_VALUE";
- case GL_INVALID_ENUM:
- return "GL_INVALID_ENUM";
- case GL_INVALID_OPERATION:
- return "GL_INVALID_OPERATION";
- case GL_STACK_OVERFLOW:
- return "GL_STACK_OVERFLOW";
- case GL_STACK_UNDERFLOW:
- return "GL_STACK_UNDERFLOW";
- case GL_OUT_OF_MEMORY:
- return "GL_OUT_OF_MEMORY";
- case GL_TABLE_TOO_LARGE:
- return "GL_TABLE_TOO_LARGE";
- case GL_INVALID_FRAMEBUFFER_OPERATION_EXT:
- return "GL_INVALID_FRAMEBUFFER_OPERATION";
- default:
- return "unknown";
- }
-}
-
-
/**
* When a new type of error is recorded, print a message describing
* previous errors which were accumulated.
@@ -880,7 +848,7 @@ flush_delayed_errors( struct gl_context *ctx )
if (ctx->ErrorDebugCount) {
_mesa_snprintf(s, MAX_DEBUG_MESSAGE_LENGTH, "%d similar %s errors",
ctx->ErrorDebugCount,
- error_string(ctx->ErrorValue));
+ _mesa_lookup_enum_by_nr(ctx->ErrorValue));
Does _mesa_lookup_enum_by_nr do the right thing for GL_NO_ERROR?
Several other enums alias 0, so it could get the string for one of
those. I definitely approve of its use for all the other cases.
output_if_debug("Mesa", s, GL_TRUE);
@@ -1015,7 +983,7 @@ _mesa_error( struct gl_context *ctx, GLenum error, const
char *fmtString, ... )
}
len = _mesa_snprintf(s2, MAX_DEBUG_MESSAGE_LENGTH, "%s in %s",
- error_string(error), s);
+ _mesa_lookup_enum_by_nr(error), s);
if (len >= MAX_DEBUG_MESSAGE_LENGTH) {
/* Same as above. */
ASSERT(0);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] glCallLists performance extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #3 from Eric Anholt --- Please, please, please don't use display lists, and don't use bitmaps. Display lists are basically nvidia-only for performance, so it's a bad route to go. Use normal texturing and "discard" instructions to render your bitmaps, or normal texturing and alhpa blending if you're doing fixed function. Sticking your textures in one big atlas and vertex data in a vbo, you'll get way better performance than you'd ever get out of bitmap. -- 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] [PATCH 01/10] build: Get rid of CORE_DIRS
A step toward working make dist/distcheck. --- Makefile.am | 28 +++- configure.ac | 36 +++- 2 files changed, 34 insertions(+), 30 deletions(-) diff --git a/Makefile.am b/Makefile.am index 0ce9455..78ecfab 100644 --- a/Makefile.am +++ b/Makefile.am @@ -19,7 +19,33 @@ # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS # IN THE SOFTWARE. -SUBDIRS = src +SUBDIRS = src/gtest src/mapi/glapi/gen + +if HAVE_SHARED_GLAPI +SUBDIRS += src/mapi/shared-glapi +endif + +if HAVE_OPENGL +SUBDIRS += src/mapi/glapi +endif + +if HAVE_OPENGL_ES1 +SUBDIRS += src/mapi/es1api +endif + +if HAVE_OPENGL_ES2 +SUBDIRS += src/mapi/es2api +endif + +if HAVE_OPENVG +SUBDIRS += src/mapi/vgapi +endif + +if NEED_OPENGL_COMMON +SUBDIRS += src/glsl src/mesa +endif + +SUBDIRS += src ACLOCAL_AMFLAGS = -I m4 diff --git a/configure.ac b/configure.ac index 1e11b4e..9178355 100644 --- a/configure.ac +++ b/configure.ac @@ -698,6 +698,13 @@ if test "x$enable_gles2" = xyes; then fi AC_SUBST([API_DEFINES]) +AM_CONDITIONAL(HAVE_OPENGL, test "x$enable_opengl" = xyes) +AM_CONDITIONAL(HAVE_OPENGL_ES1, test "x$enable_gles1" = xyes) +AM_CONDITIONAL(HAVE_OPENGL_ES2, test "x$enable_gles2" = xyes) +AM_CONDITIONAL(NEED_OPENGL_COMMON, test "x$enable_opengl" = xyes -o \ +"x$enable_gles1" = xyes -o \ +"x$enable_gles2" = xyes) + if test "x$enable_glx" = xno; then AC_MSG_WARN([GLX disabled, disabling Xlib-GLX]) enable_xlib_glx=no @@ -745,7 +752,6 @@ if test "x$enable_shared_glapi" = xyes; then # libGL will use libglapi for function lookups (IN_DRI_DRIVER means to use # the remap table) DEFINES="$DEFINES -DIN_DRI_DRIVER" -CORE_DIRS="mapi/shared-glapi" fi AM_CONDITIONAL(HAVE_SHARED_GLAPI, test "x$enable_shared_glapi" = xyes) @@ -758,28 +764,6 @@ GALLIUM_WINSYS_DIRS="sw" GALLIUM_DRIVERS_DIRS="galahad trace rbug noop identity" GALLIUM_STATE_TRACKERS_DIRS="" -# build glapi if OpenGL is enabled -if test "x$enable_opengl" = xyes; then -CORE_DIRS="$CORE_DIRS mapi/glapi" -fi - -# build es1api if OpenGL ES 1.x is enabled -if test "x$enable_gles1" = xyes; then -CORE_DIRS="$CORE_DIRS mapi/es1api" -fi - -# build es2api if OpenGL ES 2.x is enabled -if test "x$enable_gles2" = xyes; then -CORE_DIRS="$CORE_DIRS mapi/es2api" -fi - -# build glsl and mesa if OpenGL or OpenGL ES is enabled -case "x$enable_opengl$enable_gles1$enable_gles2" in -x*yes*) -CORE_DIRS="mapi/glapi/gen $CORE_DIRS gtest glsl mesa" -;; -esac - case "x$enable_glx$enable_xlib_glx" in xyesyes) DRIVER_DIRS="$DRIVER_DIRS x11" @@ -1371,7 +1355,6 @@ if test "x$enable_openvg" = xyes; then EGL_CLIENT_APIS="$EGL_CLIENT_APIS "'$(VG_LIB)' VG_LIB_DEPS="$VG_LIB_DEPS $SELINUX_LIBS $PTHREAD_LIBS" -CORE_DIRS="$CORE_DIRS mapi/vgapi" GALLIUM_STATE_TRACKERS_DIRS="vega $GALLIUM_STATE_TRACKERS_DIRS" HAVE_ST_VEGA=yes VG_PC_LIB_PRIV="-lm $CLOCK_LIB $PTHREAD_LIBS $DLOPEN_LIBS" @@ -1498,10 +1481,8 @@ AC_SUBST([CLANG_RESOURCE_DIR]) case "x$enable_opengl$enable_gles1$enable_gles2" in x*yes*) EGL_CLIENT_APIS="$EGL_CLIENT_APIS "'$(GL_LIB)' -HAVE_OPENGL=yes ;; esac -AM_CONDITIONAL(HAVE_OPENGL, test "x$HAVE_OPENGL" = xyes) AC_SUBST([VG_LIB_DEPS]) AC_SUBST([EGL_CLIENT_APIS]) @@ -2042,9 +2023,6 @@ AC_SUBST([XA_MINOR], 0) AC_SUBST([XA_TINY], 0) AC_SUBST([XA_VERSION], "$XA_MAJOR.$XA_MINOR.$XA_TINY") -dnl prepend CORE_DIRS to SRC_DIRS -SRC_DIRS="$CORE_DIRS $SRC_DIRS" - dnl Restore LDFLAGS and CPPFLAGS LDFLAGS="$_SAVE_LDFLAGS" CPPFLAGS="$_SAVE_CPPFLAGS" -- 1.7.8.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 02/10] build: Get rid of SRC_DIRS
--- Makefile.am | 20 +++- configure.ac| 21 ++--- src/Makefile.am |4 3 files changed, 25 insertions(+), 20 deletions(-) delete mode 100644 src/Makefile.am diff --git a/Makefile.am b/Makefile.am index 78ecfab..c3e2baa 100644 --- a/Makefile.am +++ b/Makefile.am @@ -45,7 +45,25 @@ if NEED_OPENGL_COMMON SUBDIRS += src/glsl src/mesa endif -SUBDIRS += src +if HAVE_GLX +SUBDIRS += src/glx +endif + +if HAVE_GBM +SUBDIRS += src/gbm +endif + +if HAVE_EGL +SUBDIRS += src/egl +endif + +if HAVE_GALLIUM +SUBDIRS += src/gallium src/gallium/winsys src/gallium/targets + +if HAVE_GALLIUM_TESTS +SUBDIRS += src/gallium/tests/trivial src/gallium/tests/unit +endif +endif ACLOCAL_AMFLAGS = -I m4 diff --git a/configure.ac b/configure.ac index 9178355..f25d488 100644 --- a/configure.ac +++ b/configure.ac @@ -732,6 +732,7 @@ if test "x$enable_glx" = xyes -a \ enable_glx=no fi +AM_CONDITIONAL(HAVE_GLX, test "x$enable_glx" = xyes) AM_CONDITIONAL(HAVE_DRI, test "x$enable_dri" = xyes) AM_CONDITIONAL(NEED_LIBMESA, test "x$enable_xlib_glx" = xyes -o \ "x$enable_osmesa" = xyes) @@ -772,10 +773,6 @@ xyesyes) GALLIUM_STATE_TRACKERS_DIRS="glx $GALLIUM_STATE_TRACKERS_DIRS" HAVE_WINSYS_XLIB="yes" ;; -xyesno) -# DRI-based GLX -SRC_DIRS="$SRC_DIRS glx" -;; esac if test "x$enable_dri" = xyes; then @@ -790,7 +787,6 @@ if test "x$enable_osmesa" = xyes; then DRIVER_DIRS="$DRIVER_DIRS osmesa" fi -AC_SUBST([SRC_DIRS]) AC_SUBST([DRIVER_DIRS]) AC_SUBST([GALLIUM_DIRS]) AC_SUBST([GALLIUM_TARGET_DIRS]) @@ -1211,8 +1207,6 @@ if test "x$enable_gbm" = xauto; then esac fi if test "x$enable_gbm" = xyes; then -SRC_DIRS="$SRC_DIRS gbm" - PKG_CHECK_MODULES([LIBUDEV], [libudev], [], AC_MSG_ERROR([gbm needs udev])) @@ -1223,6 +1217,7 @@ if test "x$enable_gbm" = xyes; then fi fi fi +AM_CONDITIONAL(HAVE_GBM, test "x$enable_gbm" = xyes) GBM_PC_REQ_PRIV="libudev" GBM_PC_LIB_PRIV="$DLOPEN_LIBS" AC_SUBST([GBM_PC_REQ_PRIV]) @@ -1234,7 +1229,6 @@ dnl EGL_CLIENT_APIS="" if test "x$enable_egl" = xyes; then -SRC_DIRS="$SRC_DIRS egl" EGL_LIB_DEPS="$DLOPEN_LIBS $SELINUX_LIBS $PTHREAD_LIBS" AC_CHECK_FUNC(mincore, [DEFINES="$DEFINES -DHAVE_MINCORE"]) @@ -1253,6 +1247,7 @@ if test "x$enable_egl" = xyes; then fi fi +AM_CONDITIONAL(HAVE_EGL, test "x$enable_egl" = xyes) AC_SUBST([EGL_LIB_DEPS]) dnl @@ -1462,10 +1457,7 @@ fi dnl dnl Gallium configuration dnl -if test "x$with_gallium_drivers" != x; then -SRC_DIRS="$SRC_DIRS gallium gallium/winsys gallium/targets" -fi -AM_CONDITIONAL(HAVE_GALLIUM, test "x$with_gallium_drivers" != x) +AM_CONDITIONAL(HAVE_GALLIUM, test -n "x$with_gallium_drivers") AC_SUBST([LLVM_BINDIR]) AC_SUBST([LLVM_CFLAGS]) @@ -1712,9 +1704,9 @@ dnl dnl Gallium Tests dnl if test "x$enable_gallium_tests" = xyes; then -SRC_DIRS="$SRC_DIRS gallium/tests/trivial gallium/tests/unit" enable_gallium_loader=yes fi +AM_CONDITIONAL(HAVE_GALLIUM_TESTS, test "x$enable_gallium_tests" = xyes) dnl Directory for VDPAU libs AC_ARG_WITH([vdpau-libdir], @@ -2033,7 +2025,6 @@ CXXFLAGS="$CXXFLAGS $USER_CXXFLAGS" dnl Substitute the config AC_CONFIG_FILES([Makefile - src/Makefile src/egl/Makefile src/egl/drivers/Makefile src/egl/drivers/dri2/Makefile @@ -2245,7 +2236,7 @@ else fi echo "" -if echo "$SRC_DIRS" | grep 'gallium' >/dev/null 2>&1; then +if test -n "x$with_gallium_drivers"; then echo "Gallium: yes" echo "Gallium dirs:$GALLIUM_DIRS" echo "Target dirs: $GALLIUM_TARGET_DIRS" diff --git a/src/Makefile.am b/src/Makefile.am deleted file mode 100644 index d6a7946..000 --- a/src/Makefile.am +++ /dev/null @@ -1,4 +0,0 @@ -SUBDIRS=$(SRC_DIRS) - -all-local: - $(MKDIR_P) $(top_builddir)/$(LIB_DIR) -- 1.7.8.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/10] build: Remove GALLIUM_DIRS
It's always constant anyway. --- Makefile.am |7 ++- configure.ac|4 src/gallium/Makefile.am | 22 -- 3 files changed, 6 insertions(+), 27 deletions(-) delete mode 100644 src/gallium/Makefile.am diff --git a/Makefile.am b/Makefile.am index c3e2baa..6eabe90 100644 --- a/Makefile.am +++ b/Makefile.am @@ -58,7 +58,12 @@ SUBDIRS += src/egl endif if HAVE_GALLIUM -SUBDIRS += src/gallium src/gallium/winsys src/gallium/targets +SUBDIRS += \ + src/gallium/auxiliary \ + src/gallium/drivers \ + src/gallium/state_trackers \ + src/gallium/winsys \ + src/gallium/targets if HAVE_GALLIUM_TESTS SUBDIRS += src/gallium/tests/trivial src/gallium/tests/unit diff --git a/configure.ac b/configure.ac index f25d488..854e616 100644 --- a/configure.ac +++ b/configure.ac @@ -759,7 +759,6 @@ AM_CONDITIONAL(HAVE_SHARED_GLAPI, test "x$enable_shared_glapi" = xyes) dnl dnl Driver specific build directories dnl -GALLIUM_DIRS="auxiliary drivers state_trackers" GALLIUM_TARGET_DIRS="" GALLIUM_WINSYS_DIRS="sw" GALLIUM_DRIVERS_DIRS="galahad trace rbug noop identity" @@ -788,7 +787,6 @@ if test "x$enable_osmesa" = xyes; then fi AC_SUBST([DRIVER_DIRS]) -AC_SUBST([GALLIUM_DIRS]) AC_SUBST([GALLIUM_TARGET_DIRS]) AC_SUBST([GALLIUM_WINSYS_DIRS]) AC_SUBST([GALLIUM_DRIVERS_DIRS]) @@ -2035,7 +2033,6 @@ AC_CONFIG_FILES([Makefile src/egl/wayland/wayland-drm/Makefile src/egl/wayland/wayland-egl/Makefile src/egl/wayland/wayland-egl/wayland-egl.pc - src/gallium/Makefile src/gallium/auxiliary/Makefile src/gallium/auxiliary/pipe-loader/Makefile src/gallium/drivers/Makefile @@ -2238,7 +2235,6 @@ fi echo "" if test -n "x$with_gallium_drivers"; then echo "Gallium: yes" -echo "Gallium dirs:$GALLIUM_DIRS" echo "Target dirs: $GALLIUM_TARGET_DIRS" echo "Winsys dirs: $GALLIUM_WINSYS_DIRS" echo "Driver dirs: $GALLIUM_DRIVERS_DIRS" diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am deleted file mode 100644 index e7cff89..000 --- a/src/gallium/Makefile.am +++ /dev/null @@ -1,22 +0,0 @@ -# Copyright © 2012 Intel Corporation -# -# 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 (including the next -# paragraph) shall be included in all copies or substantial portions of the -# Software. -# -# 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. - -SUBDIRS = $(GALLIUM_DIRS) -- 1.7.8.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 04/10] build: Stop AC_SUBST'ing DRI_DIRS and GALLIUM_DRIVERS_DIRS
Neither are used in Makefile.ams. --- configure.ac |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 854e616..5184cdf 100644 --- a/configure.ac +++ b/configure.ac @@ -789,7 +789,6 @@ fi AC_SUBST([DRIVER_DIRS]) AC_SUBST([GALLIUM_TARGET_DIRS]) AC_SUBST([GALLIUM_WINSYS_DIRS]) -AC_SUBST([GALLIUM_DRIVERS_DIRS]) AC_SUBST([GALLIUM_STATE_TRACKERS_DIRS]) AC_SUBST([MESA_LLVM]) @@ -1086,7 +1085,6 @@ if test "x$enable_dri" = xyes; then GALLIUM_DRI_LIB_DEPS="$GALLIUM_DRI_LIB_DEPS $SELINUX_LIBS $LIBDRM_LIBS $EXPAT_LIB -lm $CLOCK_LIB $PTHREAD_LIBS $DLOPEN_LIBS" fi AM_CONDITIONAL(NEED_LIBDRICORE, test -n "$DRI_DIRS") -AC_SUBST([DRI_DIRS]) AC_SUBST([EXPAT_INCLUDES]) AC_SUBST([DRI_LIB_DEPS]) AC_SUBST([GALLIUM_DRI_LIB_DEPS]) -- 1.7.8.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 05/10] build: Get rid of DRIVER_DIRS
--- configure.ac | 12 ++-- src/mesa/Makefile.am | 14 +- src/mesa/drivers/Makefile.am | 22 -- 3 files changed, 15 insertions(+), 33 deletions(-) delete mode 100644 src/mesa/drivers/Makefile.am diff --git a/configure.ac b/configure.ac index 5184cdf..4027f6e 100644 --- a/configure.ac +++ b/configure.ac @@ -766,7 +766,6 @@ GALLIUM_STATE_TRACKERS_DIRS="" case "x$enable_glx$enable_xlib_glx" in xyesyes) -DRIVER_DIRS="$DRIVER_DIRS x11" GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/xlib" GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS libgl-xlib" GALLIUM_STATE_TRACKERS_DIRS="glx $GALLIUM_STATE_TRACKERS_DIRS" @@ -775,18 +774,11 @@ xyesyes) esac if test "x$enable_dri" = xyes; then -DRIVER_DIRS="$DRIVER_DIRS dri" - GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/dri" GALLIUM_STATE_TRACKERS_DIRS="dri $GALLIUM_STATE_TRACKERS_DIRS" HAVE_ST_DRI="yes" fi -if test "x$enable_osmesa" = xyes; then -DRIVER_DIRS="$DRIVER_DIRS osmesa" -fi - -AC_SUBST([DRIVER_DIRS]) AC_SUBST([GALLIUM_TARGET_DIRS]) AC_SUBST([GALLIUM_WINSYS_DIRS]) AC_SUBST([GALLIUM_STATE_TRACKERS_DIRS]) @@ -1992,7 +1984,8 @@ AC_SUBST([GALLIUM_MAKE_DIRS]) AM_CONDITIONAL(NEED_LIBPROGRAM, test "x$with_gallium_drivers" != x -o \ "x$enable_xlib_glx" = xyes -o \ "x$enable_osmesa" = xyes) -AM_CONDITIONAL(HAVE_X11_DRIVER, echo "$DRIVER_DIRS" | grep 'x11' >/dev/null 2>&1) +AM_CONDITIONAL(HAVE_X11_DRIVER, test "x$enable_xlib_glx" = xyes) +AM_CONDITIONAL(HAVE_OSMESA, test "x$enable_osmesa" = xyes) AM_CONDITIONAL(HAVE_X86_ASM, echo "$DEFINES" | grep 'X86_ASM' >/dev/null 2>&1) AM_CONDITIONAL(HAVE_X86_64_ASM, echo "$DEFINES" | grep 'X86_64_ASM' >/dev/null 2>&1) @@ -2124,7 +2117,6 @@ AC_CONFIG_FILES([Makefile src/mapi/vgapi/vg.pc src/mesa/Makefile src/mesa/gl.pc - src/mesa/drivers/Makefile src/mesa/drivers/dri/dri.pc src/mesa/drivers/dri/common/Makefile src/mesa/drivers/dri/common/xmlpool/Makefile diff --git a/src/mesa/Makefile.am b/src/mesa/Makefile.am index 41483dd..b2d8775 100644 --- a/src/mesa/Makefile.am +++ b/src/mesa/Makefile.am @@ -23,7 +23,19 @@ if NEED_LIBDRICORE DRICORE_SUBDIR = libdricore endif -SUBDIRS = program x86 x86-64 . $(DRICORE_SUBDIR) drivers +SUBDIRS = program x86 x86-64 . $(DRICORE_SUBDIR) + +if HAVE_X11_DRIVER +SUBDIRS += drivers/x11 +endif + +if HAVE_DRI +SUBDIRS += drivers/dri +endif + +if HAVE_OSMESA +SUBDIRS += drivers/osmesa +endif gldir = $(includedir)/GL gl_HEADERS = $(top_srcdir)/include/GL/*.h diff --git a/src/mesa/drivers/Makefile.am b/src/mesa/drivers/Makefile.am deleted file mode 100644 index 1bc74ea..000 --- a/src/mesa/drivers/Makefile.am +++ /dev/null @@ -1,22 +0,0 @@ -# Copyright © 2012 Intel Corporation -# -# 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 (including the next -# paragraph) shall be included in all copies or substantial portions of the -# Software. -# -# 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. - -SUBDIRS = $(DRIVER_DIRS) -- 1.7.8.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/10] build: Stop using GALLIUM_STATE_TRACKERS_DIRS for SUBDIRS
configure still uses it to print the enabled state trackers. --- Makefile.am| 51 +++- configure.ac | 47 + src/gallium/state_trackers/Makefile.am | 23 -- 3 files changed, 64 insertions(+), 57 deletions(-) delete mode 100644 src/gallium/state_trackers/Makefile.am diff --git a/Makefile.am b/Makefile.am index 6eabe90..3aefb45 100644 --- a/Makefile.am +++ b/Makefile.am @@ -37,10 +37,6 @@ if HAVE_OPENGL_ES2 SUBDIRS += src/mapi/es2api endif -if HAVE_OPENVG -SUBDIRS += src/mapi/vgapi -endif - if NEED_OPENGL_COMMON SUBDIRS += src/glsl src/mesa endif @@ -60,10 +56,49 @@ endif if HAVE_GALLIUM SUBDIRS += \ src/gallium/auxiliary \ - src/gallium/drivers \ - src/gallium/state_trackers \ - src/gallium/winsys \ - src/gallium/targets + src/gallium/drivers + +if HAVE_X11_DRIVER +SUBDIRS += src/gallium/state_trackers/glx +endif + +if HAVE_DRI +SUBDIRS += src/gallium/state_trackers/dri +endif + +if HAVE_GALLIUM_EGL +SUBDIRS += src/gallium/state_trackers/egl +endif + +if HAVE_GALLIUM_GBM +SUBDIRS += src/gallium/state_trackers/gbm +endif + +if HAVE_ST_XORG +SUBDIRS += src/gallium/state_trackers/xorg +endif + +if HAVE_ST_XA +SUBDIRS += src/gallium/state_trackers/xa +endif + +if HAVE_OPENVG +SUBDIRS += src/mapi/vgapi src/gallium/state_trackers/vega +endif + +if HAVE_ST_XVMC +SUBDIRS += src/gallium/state_trackers/xvmc +endif + +if HAVE_ST_VDPAU +SUBDIRS += src/gallium/state_trackers/vdpau +endif + +if HAVE_CLOVER +SUBDIRS += src/gallium/state_trackers/clover +endif + +SUBDIRS += src/gallium/winsys src/gallium/targets if HAVE_GALLIUM_TESTS SUBDIRS += src/gallium/tests/trivial src/gallium/tests/unit diff --git a/configure.ac b/configure.ac index 4027f6e..5984987 100644 --- a/configure.ac +++ b/configure.ac @@ -776,12 +776,10 @@ esac if test "x$enable_dri" = xyes; then GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/dri" GALLIUM_STATE_TRACKERS_DIRS="dri $GALLIUM_STATE_TRACKERS_DIRS" -HAVE_ST_DRI="yes" fi AC_SUBST([GALLIUM_TARGET_DIRS]) AC_SUBST([GALLIUM_WINSYS_DIRS]) -AC_SUBST([GALLIUM_STATE_TRACKERS_DIRS]) AC_SUBST([MESA_LLVM]) # Check for libdrm @@ -1254,14 +1252,14 @@ if test "x$enable_gallium_egl" = xyes; then GALLIUM_STATE_TRACKERS_DIRS="egl $GALLIUM_STATE_TRACKERS_DIRS" GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS egl-static" -HAVE_ST_EGL="yes" fi +AM_CONDITIONAL(HAVE_GALLIUM_EGL, test "x$enable_gallium_egl" = xyes) dnl dnl gbm Gallium configuration dnl if test "x$enable_gallium_gbm" = xauto; then -case "$enable_gbm$HAVE_ST_EGL$enable_dri$with_egl_platforms" in +case "$enable_gbm$enable_gallium_egl$enable_dri$with_egl_platforms" in yesyesyes*drm*) enable_gallium_gbm=yes ;; *) @@ -1282,9 +1280,9 @@ if test "x$enable_gallium_gbm" = xyes; then GALLIUM_STATE_TRACKERS_DIRS="gbm $GALLIUM_STATE_TRACKERS_DIRS" GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS gbm" -HAVE_ST_GBM="yes" enable_gallium_loader=yes fi +AM_CONDITIONAL(HAVE_GALLIUM_GBM, test "x$enable_gallium_gbm" = xyes) dnl dnl X.Org DDX configuration @@ -1297,8 +1295,8 @@ if test "x$enable_xorg" = xyes; then HAVE_XEXTPROTO_71="yes"; DEFINES="$DEFINES -DHAVE_XEXTPROTO_71", HAVE_XEXTPROTO_71="no") GALLIUM_STATE_TRACKERS_DIRS="xorg $GALLIUM_STATE_TRACKERS_DIRS" -HAVE_ST_XORG=yes fi +AM_CONDITIONAL(HAVE_ST_XORG, test "x$enable_xorg" = xyes) dnl dnl XA configuration @@ -1314,11 +1312,11 @@ fi fi if test "x$enable_xa" = xyes; then GALLIUM_STATE_TRACKERS_DIRS="xa $GALLIUM_STATE_TRACKERS_DIRS" -HAVE_ST_XA=yes AC_SUBST(AWK) AC_SUBST(GREP) AC_SUBST(NM) fi +AM_CONDITIONAL(HAVE_ST_XA, test "x$enable_xa" = xyes) dnl dnl OpenVG configuration @@ -1339,7 +1337,6 @@ if test "x$enable_openvg" = xyes; then EGL_CLIENT_APIS="$EGL_CLIENT_APIS "'$(VG_LIB)' VG_LIB_DEPS="$VG_LIB_DEPS $SELINUX_LIBS $PTHREAD_LIBS" GALLIUM_STATE_TRACKERS_DIRS="vega $GALLIUM_STATE_TRACKERS_DIRS" -HAVE_ST_VEGA=yes VG_PC_LIB_PRIV="-lm $CLOCK_LIB $PTHREAD_LIBS $DLOPEN_LIBS" AC_SUBST([VG_PC_LIB_PRIV]) fi @@ -1355,7 +1352,6 @@ if test "x$enable_d3d1x" = xyes; then fi GALLIUM_STATE_TRACKERS_DIRS="d3d1x $GALLIUM_STATE_TRACKERS_DIRS" -HAVE_ST_D3D1X=yes fi dnl @@ -1383,14 +1379,14 @@ fi if test "x$enable_xvmc" = xyes; then PKG_CHECK_MODULES([XVMC], [xvmc >= 1.0.6 x11-xcb xcb-dri2 >= 1.8]) GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS xvmc" -HAVE_ST_XVMC="yes" fi +AM_CONDITIONAL(HAVE_ST_XVMC, test "x$enable_xvmc" = xyes) if test "x$enable_vdpau" = xyes; then PKG_CHECK_MODULES([VDPAU], [vdpau >= 0.4.1 x11-xcb xcb-dri2 >= 1.8]) GALLIUM_STATE_TRACKERS_DIRS="$GALLIUM_STATE_TRACKERS_DIRS vdpau" -HAVE_ST_VDPAU="yes" fi +AM_CONDITIONAL(
[Mesa-dev] [PATCH 07/10] build: Get rid of GALLIUM_MAKE_DIRS
--- configure.ac| 31 +++ src/gallium/drivers/Makefile.am | 76 ++- src/gallium/targets/pipe-loader/Makefile.am |6 +-- 3 files changed, 70 insertions(+), 43 deletions(-) diff --git a/configure.ac b/configure.ac index 5984987..c8de531 100644 --- a/configure.ac +++ b/configure.ac @@ -1920,6 +1920,13 @@ AM_CONDITIONAL(HAVE_GALLIUM_NOUVEAU, test "x$HAVE_GALLIUM_NOUVEAU" = xyes) AM_CONDITIONAL(HAVE_GALLIUM_SOFTPIPE, test "x$HAVE_GALLIUM_SOFTPIPE" = xyes) AM_CONDITIONAL(HAVE_GALLIUM_LLVMPIPE, test "x$HAVE_GALLIUM_LLVMPIPE" = xyes) +AM_CONDITIONAL(NEED_GALLIUM_SOFTPIPE_DRIVER, test "x$HAVE_GALLIUM_SVGA" = xyes -o \ + "x$HAVE_GALLIUM_I915" = xyes -o \ + "x$HAVE_GALLIUM_SOFTPIPE" = xyes) +AM_CONDITIONAL(NEED_GALLIUM_LLVMPIPE_DRIVER, test "x$HAVE_GALLIUM_I915" = xyes -o \ + "x$HAVE_GALLIUM_SOFTPIPE" = xyes -a \ + "x$MESA_LLVM" = x1) + if test "x$enable_gallium_loader" = xyes; then GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/null" GALLIUM_PIPE_LOADER_DEFINES="-DHAVE_PIPE_LOADER_SW" @@ -1945,27 +1952,6 @@ if test "x$enable_gallium_loader" = xyes; then AC_SUBST([GALLIUM_PIPE_LOADER_LIBS]) fi -dnl Tell Automake which drivers to build -for driver in $GALLIUM_DRIVERS_DIRS; do -case "x$driver" in -xgalahad) -HAVE_GALAHAD_GALLIUM=yes; - ;; - xidentity) - HAVE_IDENTITY_GALLIUM=yes; - ;; - xnoop) - HAVE_NOOP_GALLIUM=yes; - ;; -*) -GALLIUM_MAKE_DIRS="$GALLIUM_MAKE_DIRS $driver" - ;; -esac -done - -AM_CONDITIONAL(HAVE_GALAHAD_GALLIUM, test x$HAVE_GALAHAD_GALLIUM = xyes) -AM_CONDITIONAL(HAVE_IDENTITY_GALLIUM, test x$HAVE_IDENTITY_GALLIUM = xyes) -AM_CONDITIONAL(HAVE_NOOP_GALLIUM, test x$HAVE_NOOP_GALLIUM = xyes) AM_CONDITIONAL(NEED_RADEON_GALLIUM, test x$NEED_RADEON_GALLIUM = xyes) AM_CONDITIONAL(R600_NEED_RADEON_GALLIUM, test x$R600_NEED_RADEON_GALLIUM = xyes) AM_CONDITIONAL(USE_R600_LLVM_COMPILER, test x$USE_R600_LLVM_COMPILER = xyes) @@ -1975,8 +1961,6 @@ AM_CONDITIONAL(HAVE_GALLIUM_COMPUTE, test x$enable_opencl = xyes) AM_CONDITIONAL(HAVE_MESA_LLVM, test x$MESA_LLVM = x1) AM_CONDITIONAL(LLVM_NEEDS_FNORTTI, test $LLVM_VERSION_INT -ge 302) -AC_SUBST([GALLIUM_MAKE_DIRS]) - AM_CONDITIONAL(NEED_LIBPROGRAM, test "x$with_gallium_drivers" != x -o \ "x$enable_xlib_glx" = xyes -o \ "x$enable_osmesa" = xyes) @@ -2136,7 +2120,6 @@ dnl Sort the dirs alphabetically GALLIUM_TARGET_DIRS=`echo $GALLIUM_TARGET_DIRS|tr " " "\n"|sort -u|tr "\n" " "` GALLIUM_WINSYS_DIRS=`echo $GALLIUM_WINSYS_DIRS|tr " " "\n"|sort -u|tr "\n" " "` GALLIUM_DRIVERS_DIRS=`echo $GALLIUM_DRIVERS_DIRS|tr " " "\n"|sort -u|tr "\n" " "` -GALLIUM_MAKE_DIRS=`echo $GALLIUM_MAKE_DIRS|tr " " "\n"|sort -u|tr "\n" " "` GALLIUM_STATE_TRACKERS_DIRS=`echo $GALLIUM_STATE_TRACKERS_DIRS|tr " " "\n"|sort -u|tr "\n" " "` AC_OUTPUT diff --git a/src/gallium/drivers/Makefile.am b/src/gallium/drivers/Makefile.am index 25d9533..ff2f353 100644 --- a/src/gallium/drivers/Makefile.am +++ b/src/gallium/drivers/Makefile.am @@ -10,12 +10,10 @@ AM_CFLAGS = $(VISIBILITY_CFLAGS) noinst_LTLIBRARIES = -SUBDIRS = . +SUBDIRS = . trace rbug -if HAVE_GALAHAD_GALLIUM - noinst_LTLIBRARIES += galahad/libgalahad.la galahad_libgalahad_la_SOURCES = \ @@ -23,12 +21,8 @@ galahad_libgalahad_la_SOURCES = \ galahad/glhd_context.c \ galahad/glhd_screen.c -endif - -if HAVE_IDENTITY_GALLIUM - noinst_LTLIBRARIES += identity/libidentity.la identity_libidentity_la_SOURCES = \ @@ -36,12 +30,8 @@ identity_libidentity_la_SOURCES = \ identity/id_context.c \ identity/id_screen.c -endif - -if HAVE_NOOP_GALLIUM - # Meta-driver which combines whichever software rasterizers have been # built into a single convenience library. @@ -51,8 +41,6 @@ noop_libnoop_la_SOURCES = \ noop/noop_pipe.c \ noop/noop_state.c -endif - if NEED_RADEON_GALLIUM @@ -63,4 +51,64 @@ endif -SUBDIRS += $(GALLIUM_MAKE_DIRS) +if HAVE_GALLIUM_I915 + +SUBDIRS += i915 + +endif + + + +if HAVE_GALLIUM_NOUVEAU + +SUBDIRS += nouveau nv30 nv50 nvc0 + +endif + +###
[Mesa-dev] [PATCH 08/10] build: Build pipe-loader before gallium tests
And don't build it from other Makefiles. That's awful, and breaks distclean. --- configure.ac |8 src/gallium/targets/opencl/Makefile.am |3 --- src/gallium/tests/trivial/Makefile.am |7 --- 3 files changed, 4 insertions(+), 14 deletions(-) diff --git a/configure.ac b/configure.ac index c8de531..dbe72c6 100644 --- a/configure.ac +++ b/configure.ac @@ -1435,10 +1435,6 @@ if test "x$enable_opencl" = xyes; then fi AM_CONDITIONAL(HAVE_CLOVER, test "x$enable_opencl" = xyes) -if test "x$enable_gallium_gbm" = xyes || test "x$enable_opencl" = xyes; then -GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS pipe-loader" -fi - dnl dnl Gallium configuration dnl @@ -1693,6 +1689,10 @@ if test "x$enable_gallium_tests" = xyes; then fi AM_CONDITIONAL(HAVE_GALLIUM_TESTS, test "x$enable_gallium_tests" = xyes) +if test "x$enable_gallium_loader" = xyes; then +GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS pipe-loader" +fi + dnl Directory for VDPAU libs AC_ARG_WITH([vdpau-libdir], [AS_HELP_STRING([--with-vdpau-libdir=DIR], diff --git a/src/gallium/targets/opencl/Makefile.am b/src/gallium/targets/opencl/Makefile.am index c5c3003..da33788 100644 --- a/src/gallium/targets/opencl/Makefile.am +++ b/src/gallium/targets/opencl/Makefile.am @@ -32,11 +32,8 @@ libOpenCL_la_SOURCES = # Force usage of a C++ linker nodist_EXTRA_libOpenCL_la_SOURCES = dummy.cpp -PIPE_SRC_DIR = $(top_srcdir)/src/gallium/targets/pipe-loader - # Provide compatibility with scripts for the old Mesa build system for # a while by putting a link to the driver into /lib of the build tree. all-local: libOpenCL.la - @$(MAKE) -C $(PIPE_SRC_DIR) $(MKDIR_P) $(top_builddir)/$(LIB_DIR) ln -f .libs/libOpenCL.so* $(top_builddir)/$(LIB_DIR)/ diff --git a/src/gallium/tests/trivial/Makefile.am b/src/gallium/tests/trivial/Makefile.am index e6e9ae7..32a1299 100644 --- a/src/gallium/tests/trivial/Makefile.am +++ b/src/gallium/tests/trivial/Makefile.am @@ -25,10 +25,3 @@ compute_SOURCES = compute.c tri_SOURCES = tri.c quad_tex_SOURCES = quad-tex.c - -all-local: - @$(MAKE) -C $(PIPE_SRC_DIR) - -clean-local: - @$(MAKE) -C $(PIPE_SRC_DIR) clean - -rm -f result.bmp -- 1.7.8.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 09/10] build: Get rid of GALLIUM_TARGET_DIRS
--- configure.ac|2 +- src/gallium/targets/Makefile.am | 142 ++- 2 files changed, 142 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index dbe72c6..db77eb1 100644 --- a/configure.ac +++ b/configure.ac @@ -778,7 +778,6 @@ if test "x$enable_dri" = xyes; then GALLIUM_STATE_TRACKERS_DIRS="dri $GALLIUM_STATE_TRACKERS_DIRS" fi -AC_SUBST([GALLIUM_TARGET_DIRS]) AC_SUBST([GALLIUM_WINSYS_DIRS]) AC_SUBST([MESA_LLVM]) @@ -1692,6 +1691,7 @@ AM_CONDITIONAL(HAVE_GALLIUM_TESTS, test "x$enable_gallium_tests" = xyes) if test "x$enable_gallium_loader" = xyes; then GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS pipe-loader" fi +AM_CONDITIONAL(NEED_GALLIUM_LOADER, test "x$enable_gallium_loader" = xyes) dnl Directory for VDPAU libs AC_ARG_WITH([vdpau-libdir], diff --git a/src/gallium/targets/Makefile.am b/src/gallium/targets/Makefile.am index deeefbe..c80b56d 100644 --- a/src/gallium/targets/Makefile.am +++ b/src/gallium/targets/Makefile.am @@ -1 +1,141 @@ -SUBDIRS = $(GALLIUM_TARGET_DIRS) +# Copyright © 2013 Intel Corporation +# +# 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 (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# 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. + +SUBDIRS = + +if HAVE_X11_DRIVER +SUBDIRS += libgl-xlib +endif + +if HAVE_GALLIUM_GBM +SUBDIRS += gbm +endif + +if HAVE_CLOVER +SUBDIRS += opencl +endif + +if HAVE_GALLIUM_SVGA +if HAVE_DRI +SUBDIRS += dri-vmwgfx +endif + +if HAVE_ST_XA +SUBDIRS += xa-vmwgfx +endif +endif + +if HAVE_GALLIUM_I915 +if HAVE_DRI +SUBDIRS += dri-i915 +endif + +if HAVE_ST_XORG +SUBDIRS += xorg-i915 +endif +endif + +if HAVE_GALLIUM_R300 +if HAVE_DRI +SUBDIRS += dri-r300 +endif + +if HAVE_ST_XVMC +SUBDIRS += xvmc-r300 +endif + +if HAVE_ST_VDPAU +SUBDIRS += vdpau-r300 +endif +endif + +if HAVE_GALLIUM_R600 +if HAVE_DRI +SUBDIRS += dri-r600 +endif + +if HAVE_ST_XORG +SUBDIRS += xorg-r600 +endif + +if HAVE_ST_XVMC +SUBDIRS += xvmc-r600 +endif + +if HAVE_ST_VDPAU +SUBDIRS += vdpau-r600 +endif +endif + +if HAVE_GALLIUM_RADEONSI +if HAVE_DRI +SUBDIRS += dri-radeonsi +endif + +if HAVE_ST_XORG +SUBDIRS += xorg-radeonsi +endif + +if HAVE_ST_VDPAU +SUBDIRS += vdpau-radeonsi +endif +endif + +if HAVE_GALLIUM_NOUVEAU +if HAVE_DRI +SUBDIRS += dri-nouveau +endif + +if HAVE_ST_XORG +SUBDIRS += xorg-nouveau +endif + +if HAVE_ST_XVMC +SUBDIRS += xvmc-nouveau +endif + +if HAVE_ST_VDPAU +SUBDIRS += vdpau-nouveau +endif +endif + +if HAVE_GALLIUM_SOFTPIPE +if HAVE_DRI +SUBDIRS += dri-swrast +endif + +if HAVE_ST_XVMC +SUBDIRS += xvmc-softpipe +endif + +if HAVE_ST_VDPAU +SUBDIRS += vdpau-softpipe +endif +endif + +if NEED_GALLIUM_LOADER +SUBDIRS += pipe-loader +endif + +if HAVE_GALLIUM_EGL +SUBDIRS += egl-static +endif -- 1.7.8.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 10/10] build: Get rid of GALLIUM_WINSYS_DIRS
---
configure.ac | 38 +-
src/gallium/winsys/Makefile.am| 62 -
src/gallium/winsys/sw/Makefile.am | 37 --
3 files changed, 84 insertions(+), 53 deletions(-)
delete mode 100644 src/gallium/winsys/sw/Makefile.am
diff --git a/configure.ac b/configure.ac
index db77eb1..59146c2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -769,7 +769,7 @@ xyesyes)
GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/xlib"
GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS libgl-xlib"
GALLIUM_STATE_TRACKERS_DIRS="glx $GALLIUM_STATE_TRACKERS_DIRS"
-HAVE_WINSYS_XLIB="yes"
+NEED_WINSYS_XLIB="yes"
;;
esac
@@ -778,7 +778,6 @@ if test "x$enable_dri" = xyes; then
GALLIUM_STATE_TRACKERS_DIRS="dri $GALLIUM_STATE_TRACKERS_DIRS"
fi
-AC_SUBST([GALLIUM_WINSYS_DIRS])
AC_SUBST([MESA_LLVM])
# Check for libdrm
@@ -1483,10 +1482,6 @@ fi
egl_platforms=`IFS=', '; echo $with_egl_platforms`
for plat in $egl_platforms; do
case "$plat" in
- fbdev|null)
- GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/$plat"
- ;;
-
wayland)
PKG_CHECK_MODULES([WAYLAND], [wayland-client >= 1.0.2
wayland-server >= 1.0.2])
GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/wayland"
@@ -1509,7 +1504,7 @@ for plat in $egl_platforms; do
AC_MSG_ERROR([EGL platform drm needs gbm])
;;
- android|gdi)
+ android|fbdev|gdi|null)
;;
*)
@@ -1534,6 +1529,9 @@ fi
EGL_PLATFORMS="$egl_platforms"
+if echo "$egl_platforms" | grep 'x11' >/dev/null 2>&1; then
+NEED_WINSYS_XLIB=yes
+fi
AM_CONDITIONAL(HAVE_EGL_PLATFORM_X11, echo "$egl_platforms" | grep 'x11'
>/dev/null 2>&1)
AM_CONDITIONAL(HAVE_EGL_PLATFORM_WAYLAND, echo "$egl_platforms" | grep
'wayland' >/dev/null 2>&1)
AM_CONDITIONAL(HAVE_EGL_PLATFORM_DRM, echo "$egl_platforms" | grep 'drm'
>/dev/null 2>&1)
@@ -1713,9 +1711,7 @@ dnl
dnl Gallium helper functions
dnl
gallium_check_st() {
-if test "x$enable_dri" = xyes -o "x$enable_xorg" = xyes -o \
-"x$enable_xa" = xyes -o "x$enable_xvmc" = xyes -o \
-"x$enable_vdpau" = xyes; then
+if test "x$NEED_NONNULL_WINSYS" = xyes; then
if test "x$have_libdrm" != xyes; then
AC_MSG_ERROR([DRI or Xorg DDX requires libdrm >= $LIBDRM_REQUIRED])
fi
@@ -1776,6 +1772,13 @@ radeon_llvm_check() {
}
dnl Gallium drivers
+if test "x$enable_dri" = xyes -o "x$enable_xorg" = xyes -o \
+"x$enable_xa" = xyes -o "x$enable_xvmc" = xyes -o \
+"x$enable_vdpau" = xyes; then
+NEED_NONNULL_WINSYS=yes
+fi
+AM_CONDITIONAL(NEED_NONNULL_WINSYS, test "x$NEED_NONNULL_WINSYS" = xyes)
+
dnl Duplicates in GALLIUM_DRIVERS_DIRS are removed by sorting it after this
block
if test "x$with_gallium_drivers" != x; then
gallium_drivers=`IFS=', '; echo $with_gallium_drivers`
@@ -1856,9 +1859,8 @@ if test "x$with_gallium_drivers" != x; then
GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS xvmc-softpipe"
fi
if test "x$enable_vdpau" = xyes -o "x$enable_xvmc" = xyes; then
- if test "x$HAVE_WINSYS_XLIB" != xyes; then
- GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/xlib"
- fi
+NEED_WINSYS_XLIB=yes
+GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/xlib"
fi
;;
*)
@@ -1933,7 +1935,7 @@ if test "x$enable_gallium_loader" = xyes; then
GALLIUM_PIPE_LOADER_LIBS="\$(top_builddir)/src/gallium/auxiliary/pipe-loader/libpipe_loader.la"
GALLIUM_PIPE_LOADER_LIBS="$GALLIUM_PIPE_LOADER_LIBS
\$(top_builddir)/src/gallium/winsys/sw/null/libws_null.la"
-if test "x$HAVE_WINSYS_XLIB" = xyes; then
+if test "x$NEED_WINSYS_XLIB" = xyes; then
GALLIUM_PIPE_LOADER_DEFINES="$GALLIUM_PIPE_LOADER_DEFINES
-DHAVE_PIPE_LOADER_XLIB"
GALLIUM_PIPE_LOADER_LIBS="$GALLIUM_PIPE_LOADER_LIBS
\$(top_builddir)/src/gallium/winsys/sw/xlib/libws_xlib.la"
fi
@@ -1952,6 +1954,13 @@ if test "x$enable_gallium_loader" = xyes; then
AC_SUBST([GALLIUM_PIPE_LOADER_LIBS])
fi
+AM_CONDITIONAL(NEED_RADEON_DRM_WINSYS, test "x$NEED_NONNULL_WINSYS" = xyes -a \
+"x$HAVE_GALLIUM_R300" = xyes -o \
+"x$HAVE_GALLIUM_R600" = xyes -o \
+"x$HAVE_GALLIUM_RADEONSI" = xyes)
+AM_CONDITIONAL(NEED_WINSYS_WRAPPER, test "x$HAVE_GALLIUM_I915" = xyes -o \
+ "x$HAVE_GALLIUM_SVGA" = xyes)
+AM_CONDITIONAL(NEED_WINSYS_XLIB, test "x$NEED_WINSYS_XLIB" = xyes)
AM_CONDITIONAL(NEED_RADEON_GALLIUM, test x$NEED_RADEON_GALLIUM = xyes)
AM_CONDITIONAL(R600_NEED_RADEON_GALLIUM, test x$R600_NEED_RADEON_GALLIUM =
xyes)
AM_CONDITIONAL(USE_R600_LLVM_COMPILER, test x$USE_R600_LLVM_COM
Re: [Mesa-dev] GL_ARB_debug_output from drivers
On 02/22/2013 07:52 PM, Eric Anholt wrote: One of the features Valve asked for, that they expected after using other drivers, is that they can easily get information about performance traps (and other important stuff) from drivers. We wrote INTEL_DEBUG=perf this summer as a quick fix, but it's not how most drivers integrate this sort of feedback. Instead, you make a debug context, and you take a bit of a performance hit but you get GL_ARB_debug_output messages from the driver. I didn't want to just dump the same ID in every message, since that's definitely not what the spec intends you to do, so I'd been delaying the ARB_debug_output work until I could decide how to make that possible. This is what I came up with after a few false starts. I haven't fixed up the current messages to have unique IDs, though. I'd like to do something that doesn't involve spamming a static msg_id into each caller, but to avoid that I need a #define with varargs. Is __VA_ARGS__ or some equivalent standard enough that we can rely on it outside of drivers? It looks like Visual Studio supports it since VS 2005: http://msdn.microsoft.com/en-us/library/ms177415(v=vs.80).aspx It looks like clang also supports it, but it may generate an extra warning: http://stackoverflow.com/questions/4786649/are-variadic-macros-nonstandard The VS support may only be in C++ mode. Varargs macros are part of C99 and C++0x. We may have to experiment. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Lower textureGrad() for samplerCubeShadow.
Kenneth Graunke writes: > GLSL provides gradients for the 'r' coordinate (face ID), while our > hardware apparently ignores them. Sadly, this means that sample_d and > sample_d_c appear to be unsuitable for OpenGL, and need to be lowered. 'r' isn't a face ID in GLSL, though -- it's just the 3rd component of the vector pointing to texels. Did you mean it's used as face ID in hardware for sample_d/d_c? pgpkYdgA7NU6D.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] egl: Add MESA_image_sRGB extension.
On 02/23/2013 07:53 AM, John Kåre Alsaker wrote:
This gives applications access to use DRIimage.duplicateImage to create sRGB
and linear views from EGL images.
The spec and the implementation really should be separate commits.
Also... are there piglit tests coming?
---
docs/MESA_image_sRGB.spec | 132
include/EGL/eglmesaext.h| 7 ++
src/egl/drivers/dri2/egl_dri2.c | 115 +++-
src/egl/drivers/dri2/egl_dri2.h | 2 +-
src/egl/drivers/dri2/platform_android.c | 19 -
src/egl/drivers/dri2/platform_drm.c | 18 -
src/egl/drivers/dri2/platform_x11.c | 18 -
src/egl/main/eglcurrent.c | 5 ++
src/egl/main/egldisplay.h | 1 +
src/egl/main/eglimage.c | 6 ++
src/egl/main/eglimage.h | 3 +
src/egl/main/eglmisc.c | 1 +
12 files changed, 281 insertions(+), 46 deletions(-)
create mode 100644 docs/MESA_image_sRGB.spec
diff --git a/docs/MESA_image_sRGB.spec b/docs/MESA_image_sRGB.spec
new file mode 100644
index 000..f8a0bea
--- /dev/null
+++ b/docs/MESA_image_sRGB.spec
@@ -0,0 +1,132 @@
More recent versions of the spec template include a section for
describing conformance tests. This would be a good place to document
piglit tests. It also helps app developers know how things should work.
+Name
+
+MESA_image_sRGB
+
+Name Strings
+
+EGL_MESA_image_sRGB
+
+Contact
+
+John Kåre Alsaker
+
+Status
+
+Complete
+
+Version
+
+Version 2, February 23, 2013
+
+Number
+
+EGL Extension #not assigned
+
+Dependencies
+
+EGL 1.2 or later is required.
+
+EGL_KHR_image_base is required.
+
+This extension is written against the wording of the EGL 1.2
+specification.
+
+Overview
+
+This extension provides a way for applications to allocate sRGB
+or linear gamma views for EGLImage sources. This means that
+sampling from the resulting EGLImage should convert from sRGB's
+gamma into linear gamma.
+
+IP Status
+
+Open-source; freely implementable.
+
+New Tokens
+
+Accepted in the parameter of eglCreateImageKHR:
+
+EGL_GAMMA_MESA 0x3290
+
+Accepted as values for the EGL_GAMMA_MESA attribute:
+
+EGL_DEFAULT_MESA 0x3291
+
+Error states:
+
+EGL_BAD_VIEW_MESA 0x3292
+
+Additions to the EGL 1.2 Specification:
+
+Add to section 2.5.1 "EGLImage Specification" (as defined by the
+EGL_KHR_image_base specification), in the description of
+eglCreateImageKHR:
+
+ "Attributes names accepted in are shown in Table bbb
+
+ ++-+--+
+ | Attribute | Description | Default Value|
+ ++-+--+
+ | EGL_GAMMA_MESA | Specifies the gamma | EGL_DEFAULT_MESA |
+ || view of the | |
+ || EGLImage created. | |
+ ++-+--+
+ Table bbb. Legal attributes for eglCreateImageKHR
+parameter
+
+...
+
+If the value of attribute EGL_GAMMA_MESA is EGL_DEFAULT_MESA (the
+default), then the gamma view of the resulting EGLImage will be
+the same as the EGLImage source.
+
+If the value of attribute EGL_GAMMA_MESA is EGL_COLORSPACE_LINEAR,
+then the gamma view of the resulting EGLImage will be linear
+and no gamma conversions will be done when sampling the image
+in client APIs.
+
+If the value of attribute EGL_GAMMA_MESA is EGL_COLORSPACE_sRGB,
+then the gamma view of the resulting EGLImage will be an sRGB
+view and the red, green and blue color components will be
+converted from sRGB gamma to linear gamma when sampling the image
+in client APIs. This conversion should ideally take place before
+any filtering, but that is not required. The conversion from an
+sRGB gamma component, cs, to a linear gamma component, cl, is as
+follows.
+
+{ cs / 12.92, cs <= 0.04045
+ cl = {
+{ ((cs + 0.055)/1.055)^2.4, cs > 0.04045
+
+Assume cs is the sRGB gamma component in the range [0,1]."
+
+Add to the list of error conditions for eglCreateImageKHR:
+
+ "* If the value specified in for EGL_GAMMA_MESA
+ is not EGL_DEFAULT_MESA, and the implementation does not
+ support creating the specified gamma view, the error
+ EGL_BAD_VIEW_MESA is generated.
+
+ * If the value specified in for EGL_GAMMA_MESA
+ is EGL_COLORSPACE_sRGB, and the EGLImage source does not have
+ red, green and blue color components, the error
+ EGL_BAD_VIEW_MESA is generated."
+
+Issues
+
+1) Should creating multiple
Re: [Mesa-dev] [PATCH 2/2] i965/vs: Fix textureGrad() with shadow samplers on Haswell.
Kenneth Graunke writes:
> The shadow comparitor needs to be loaded into the Z component of the
> last DWord.
>
> Fixes es3conform's shadow_execution_vert and oglconform's
> shadow-grad advanced.textureGrad.1D tests on Haswell.
>
> NOTE: This is a candidate for stable branches.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> index 1863fe5..f5b467d 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> @@ -2194,7 +2194,7 @@ vec4_visitor::visit(ir_texture *ir)
>emit(MOV(dst_reg(MRF, param_base, ir->coordinate->type, zero_mask),
> src_reg(0)));
>/* Load the shadow comparitor */
> - if (ir->shadow_comparitor) {
> + if (ir->shadow_comparitor && ir->op != ir_txd) {
>emit(MOV(dst_reg(MRF, param_base + 1, ir->shadow_comparitor->type,
> WRITEMASK_X),
> shadow_comparitor));
> @@ -2231,12 +2231,18 @@ vec4_visitor::visit(ir_texture *ir)
> emit(MOV(dst_reg(MRF, param_base + 1, type, WRITEMASK_YW), dPdy));
> inst->mlen++;
>
> - if (ir->type->vector_elements == 3) {
> + if (ir->type->vector_elements == 3 || ir->shadow_comparitor) {
> dPdx.swizzle = BRW_SWIZZLE_;
> dPdy.swizzle = BRW_SWIZZLE_;
> emit(MOV(dst_reg(MRF, param_base + 2, type, WRITEMASK_X), dPdx));
> emit(MOV(dst_reg(MRF, param_base + 2, type, WRITEMASK_Y), dPdy));
Should we bother setting up dst_reg.xy if vector_elements != 3 here?
> inst->mlen++;
> +
> + if (ir->shadow_comparitor) {
> + emit(MOV(dst_reg(MRF, param_base + 2,
> + ir->shadow_comparitor->type, WRITEMASK_Z),
> + shadow_comparitor));
> + }
> }
>} else /* intel->gen == 4 */ {
> emit(MOV(dst_reg(MRF, param_base + 1, type, WRITEMASK_XYZ), dPdx));
> --
> 1.8.1.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgpLgn0Iv7vHG.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] dri: Add another duplicateImage to DRIimageExtension which allows you to create a sRGB view of a DRI image
On 02/23/2013 07:53 AM, John Kåre Alsaker wrote:
duplicateImage will allow you to create a linear or sRGB view into a DRIimage
you have access to.
This is useful because compositors may want a specific view which doesn't
correspond to the one used by applications.
Please wrap commit messages to 72 characters.
---
include/GL/internal/dri_interface.h | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 42147e9..f4948a8 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -938,7 +938,7 @@ struct __DRIdri2ExtensionRec {
* extensions.
*/
#define __DRI_IMAGE "DRI_IMAGE"
-#define __DRI_IMAGE_VERSION 6
+#define __DRI_IMAGE_VERSION 7
/**
* These formats correspond to the similarly named MESA_FORMAT_*
@@ -1009,6 +1009,15 @@ struct __DRIdri2ExtensionRec {
#define __DRI_IMAGE_COMPONENTS_Y_UV 0x3004
#define __DRI_IMAGE_COMPONENTS_Y_XUXV 0x3005
+/**
+ * Flags for duplicateImage.
+ *
+ * \since 7
+ */
+
+#define __DRI_IMAGE_FLAG_SRGB_VIEW 0x0001
+#define __DRI_IMAGE_FLAG_LINEAR_VIEW 0x0002
+
/**
* queryImage attributes
@@ -1105,6 +1114,7 @@ struct __DRIimageExtensionRec {
__DRIimage *(*fromPlanar)(__DRIimage *image, int plane,
void *loaderPrivate);
+
Spurious whitespace change.
/**
* Create image from texture.
*
@@ -1117,6 +1127,15 @@ struct __DRIimageExtensionRec {
int level,
unsigned *error,
void *loaderPrivate);
+
+ /**
+* The new __DRIimage will share the raw content with the old one,
+* but it might have a different format.
+*
+* \since 7
+*/
+__DRIimage *(*duplicateImage)(__DRIscreen *screen, __DRIimage *image,
+ unsigned int flags, void *loaderPrivate);
};
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] glCallLists performance extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #4 from James Ogden --- (In reply to comment #3) > Please, please, please don't use display lists, and don't use bitmaps. > Display lists are basically nvidia-only for performance, so it's a bad route > to go. Use normal texturing and "discard" instructions to render your > bitmaps, or normal texturing and alhpa blending if you're doing fixed > function. Sticking your textures in one big atlas and vertex data in a vbo, > you'll get way better performance than you'd ever get out of bitmap. Really dude, did you not read anything I said? It's a compatibility thing, plus the people who play this game are mostly either kids or computer illiterates so if a font texture goes bye bye because of something silly they did, I'll be the one who has to personally troubleshoot their issue. I *want* to use the proper method, but I've had that many issues in the past with relying on users being intelligent enough to keep track of their file system that I now know better. I know they're slow, I know they're deprecated and I do care, but I don't have much choice if I want to stay sane. Oh and my last machine was an AMD ATi setup, dual radeon graphics, display lists worked fine using the official drivers, or 3rd party ones, I just hate APUs which is why I upgraded as soon as the laptop died before the warranty ran out. So this isn't a case of nvidia drivers being better than the rest. (In reply to comment #2) > Yeah, I think we're relying on the meta path for glBitmap in many cases. > We're > probably hitting software rasterization. > > Still, 120 fps -> 8 fps is clearly not reasonable. > > What generation of Intel hardware are you running? (lspci -nn would tell > you.) > Can you post an apitrace which exhibits the problem? I'm not sure how much I trust lspci's information, it thinks I have a Xeon server processor :/ I'm running an Intel i5 Gen 3 Core processor the 3210M model IvyBridge. The VGA section for the low-performance side of things states an Intel 3rd Gen Graphics Controller. Not a lot of help on that side. (In reply to comment #1) > glBitmap, not glCallLists, is probably the real issue. It might be helpful > to see the "OpenGL renderer string" from glxinfo to identify the GPU. I > suspect the i965 driver needs some sort of glBitmap caching mechanism > (similar to what's in the gallium state tracker) to improve performance. Renderer is Mesa 9.0 I believe, like I said, it's using Mesa drivers. -- 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] [PATCH] texobj: add verbose api trace messages to several routines
Motivated by wanting to see if GenTextures was called by an
application while debugging another Steam overlay issue.
Signed-off-by: Jordan Justen
---
src/mesa/main/texobj.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
index e99b0dc..af5902f 100644
--- a/src/mesa/main/texobj.c
+++ b/src/mesa/main/texobj.c
@@ -960,6 +960,9 @@ _mesa_GenTextures( GLsizei n, GLuint *textures )
GLuint first;
GLint i;
+ if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
+ _mesa_debug(ctx, "glGenTextures %d\n", n);
+
if (n < 0) {
_mesa_error( ctx, GL_INVALID_VALUE, "glGenTextures" );
return;
@@ -1069,6 +1072,9 @@ _mesa_DeleteTextures( GLsizei n, const GLuint *textures)
GET_CURRENT_CONTEXT(ctx);
GLint i;
+ if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
+ _mesa_debug(ctx, "glDeleteTextures %d\n", n);
+
FLUSH_VERTICES(ctx, 0); /* too complex */
if (!textures)
@@ -1290,6 +1296,9 @@ _mesa_PrioritizeTextures( GLsizei n, const GLuint
*texName,
GET_CURRENT_CONTEXT(ctx);
GLint i;
+ if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
+ _mesa_debug(ctx, "glPrioritizeTextures %d\n", n);
+
FLUSH_VERTICES(ctx, 0);
if (n < 0) {
@@ -1334,6 +1343,9 @@ _mesa_AreTexturesResident(GLsizei n, const GLuint
*texName,
GLint i;
ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, GL_FALSE);
+ if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
+ _mesa_debug(ctx, "glAreTexturesResident %d\n", n);
+
if (n < 0) {
_mesa_error(ctx, GL_INVALID_VALUE, "glAreTexturesResident(n)");
return GL_FALSE;
@@ -1379,6 +1391,9 @@ _mesa_IsTexture( GLuint texture )
GET_CURRENT_CONTEXT(ctx);
ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, GL_FALSE);
+ if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
+ _mesa_debug(ctx, "glIsTexture %d\n", texture);
+
if (!texture)
return GL_FALSE;
@@ -1428,6 +1443,9 @@ _mesa_InvalidateTexSubImage(GLuint texture, GLint level,
GLint xoffset,
struct gl_texture_image *image;
GET_CURRENT_CONTEXT(ctx);
+ if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
+ _mesa_debug(ctx, "glInvalidateTexSubImage %d\n", texture);
+
t = invalidate_tex_image_error_check(ctx, texture, level,
"glInvalidateTexSubImage");
@@ -1566,6 +1584,9 @@ _mesa_InvalidateTexImage(GLuint texture, GLint level)
{
GET_CURRENT_CONTEXT(ctx);
+ if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
+ _mesa_debug(ctx, "glInvalidateTexImage(%d, %d)\n", texture, level);
+
invalidate_tex_image_error_check(ctx, texture, level,
"glInvalidateTexImage");
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] glCallLists performance extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #5 from Eric Anholt --- I did read it. But alpha blended texturing would also do the job that glBitmap does, and is just fine with fixed function GL. -- 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] [PATCH 01/10] build: Get rid of CORE_DIRS
Matt Turner writes: > A step toward working make dist/distcheck. > --- > Makefile.am | 28 +++- > configure.ac | 36 +++- > 2 files changed, 34 insertions(+), 30 deletions(-) > > diff --git a/Makefile.am b/Makefile.am > index 0ce9455..78ecfab 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -19,7 +19,33 @@ > # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > DEALINGS > # IN THE SOFTWARE. > > -SUBDIRS = src > +SUBDIRS = src/gtest src/mapi/glapi/gen > + > +if HAVE_SHARED_GLAPI > +SUBDIRS += src/mapi/shared-glapi > +endif Is there a reason these aren't all added to src/Makefile.am instead? I like where this is going, though... pgpTDz9jUM0Bp.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] build: Get rid of CORE_DIRS
On Mon, Feb 25, 2013 at 2:21 PM, Eric Anholt wrote:
> Matt Turner writes:
>
>> A step toward working make dist/distcheck.
>> ---
>> Makefile.am | 28 +++-
>> configure.ac | 36 +++-
>> 2 files changed, 34 insertions(+), 30 deletions(-)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 0ce9455..78ecfab 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -19,7 +19,33 @@
>> # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> DEALINGS
>> # IN THE SOFTWARE.
>>
>> -SUBDIRS = src
>> +SUBDIRS = src/gtest src/mapi/glapi/gen
>> +
>> +if HAVE_SHARED_GLAPI
>> +SUBDIRS += src/mapi/shared-glapi
>> +endif
>
> Is there a reason these aren't all added to src/Makefile.am instead?
Just a question of whether we'd rather recurse into src/ in order to
recurse into src/{...}. If keeping the top-level Makefile.am smaller
is what we want, I'll move the SUBDIRS += ... into src/Makefile.am. As
it stands though, patch 2 kills src/Makefile.am.
>
> I like where this is going, though...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines
On Mon, Feb 25, 2013 at 2:00 PM, Jordan Justen
wrote:
> Motivated by wanting to see if GenTextures was called by an
> application while debugging another Steam overlay issue.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/main/texobj.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c
> index e99b0dc..af5902f 100644
> --- a/src/mesa/main/texobj.c
> +++ b/src/mesa/main/texobj.c
> @@ -960,6 +960,9 @@ _mesa_GenTextures( GLsizei n, GLuint *textures )
> GLuint first;
> GLint i;
>
> + if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
> + _mesa_debug(ctx, "glGenTextures %d\n", n);
> +
> if (n < 0) {
>_mesa_error( ctx, GL_INVALID_VALUE, "glGenTextures" );
>return;
> @@ -1069,6 +1072,9 @@ _mesa_DeleteTextures( GLsizei n, const GLuint *textures)
> GET_CURRENT_CONTEXT(ctx);
> GLint i;
>
> + if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
> + _mesa_debug(ctx, "glDeleteTextures %d\n", n);
> +
> FLUSH_VERTICES(ctx, 0); /* too complex */
>
> if (!textures)
> @@ -1290,6 +1296,9 @@ _mesa_PrioritizeTextures( GLsizei n, const GLuint
> *texName,
> GET_CURRENT_CONTEXT(ctx);
> GLint i;
>
> + if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
> + _mesa_debug(ctx, "glPrioritizeTextures %d\n", n);
> +
> FLUSH_VERTICES(ctx, 0);
>
> if (n < 0) {
> @@ -1334,6 +1343,9 @@ _mesa_AreTexturesResident(GLsizei n, const GLuint
> *texName,
> GLint i;
> ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, GL_FALSE);
>
> + if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
> + _mesa_debug(ctx, "glAreTexturesResident %d\n", n);
> +
> if (n < 0) {
>_mesa_error(ctx, GL_INVALID_VALUE, "glAreTexturesResident(n)");
>return GL_FALSE;
> @@ -1379,6 +1391,9 @@ _mesa_IsTexture( GLuint texture )
> GET_CURRENT_CONTEXT(ctx);
> ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, GL_FALSE);
>
> + if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
> + _mesa_debug(ctx, "glIsTexture %d\n", texture);
> +
> if (!texture)
>return GL_FALSE;
>
> @@ -1428,6 +1443,9 @@ _mesa_InvalidateTexSubImage(GLuint texture, GLint
> level, GLint xoffset,
> struct gl_texture_image *image;
> GET_CURRENT_CONTEXT(ctx);
>
> + if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
> + _mesa_debug(ctx, "glInvalidateTexSubImage %d\n", texture);
> +
> t = invalidate_tex_image_error_check(ctx, texture, level,
> "glInvalidateTexSubImage");
>
> @@ -1566,6 +1584,9 @@ _mesa_InvalidateTexImage(GLuint texture, GLint level)
> {
> GET_CURRENT_CONTEXT(ctx);
>
> + if (MESA_VERBOSE & (VERBOSE_API|VERBOSE_TEXTURE))
> + _mesa_debug(ctx, "glInvalidateTexImage(%d, %d)\n", texture, level);
> +
> invalidate_tex_image_error_check(ctx, texture, level,
> "glInvalidateTexImage");
>
> --
> 1.7.10.4
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] glCallLists performance extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #6 from James Ogden --- (In reply to comment #5) > I did read it. But alpha blended texturing would also do the job that > glBitmap does, and is just fine with fixed function GL. You clearly DID NOT read it: > The people who play this game are mostly either kids or computer illiterates > so if a font texture goes bye bye because of something silly they did, I'll > be the one who has to personally troubleshoot their issue. I *want* to use > the proper method, but I've had that many issues in the past with relying on > users being intelligent enough to keep track of their file system that I now > know better. I know they're slow, I know they're deprecated and I do care, > but I don't have much choice if I want to stay sane. Besides, I have reported a clearly broken feature of the driver, which appears to be related to glBitmap, perhaps instead of solely glCallLists, and it should be fixed. So stop telling me what I should do instead of using it when I've given my perfectly reasonable reasons and am not interested in people such as yourself arrogantly parading around like you do. Either help with fixing the issue that is the driver seemingly falling back to some slow software implementation or bugger off. -- 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 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 James Ogden changed: What|Removed |Added Summary|glCallLists performance |glCallLists/glBitmap calls |extremely slow |slow on Intel ||implementation of Mesa ||drivers -- 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 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #7 from Ian Romanick --- (In reply to comment #4) > (In reply to comment #3) > > Please, please, please don't use display lists, and don't use bitmaps. > > Display lists are basically nvidia-only for performance, so it's a bad route > > to go. Use normal texturing and "discard" instructions to render your > > bitmaps, or normal texturing and alhpa blending if you're doing fixed > > function. Sticking your textures in one big atlas and vertex data in a vbo, > > you'll get way better performance than you'd ever get out of bitmap. > > Really dude, did you not read anything I said? It's a compatibility thing, > plus the people who play this game are mostly either kids or computer > illiterates so if a font texture goes bye bye because of something silly > they did, I'll be the one who has to personally troubleshoot their issue. I Can you elaborate on what you mean by this? I believe that Eric's proposal was for you to change the way the application is rendering. I'm not sure how this has any affect on end-users troubleshooting things. > *want* to use the proper method, but I've had that many issues in the past > with relying on users being intelligent enough to keep track of their file > system that I now know better. I know they're slow, I know they're > deprecated and I do care, but I don't have much choice if I want to stay > sane. I'm assuming that you have fonts stored on disk as bitmap (1-bit per pixel) images, and that's why you're mentioning filesystems. You can use this data as a texture by using the GL_PIXEL_MAP_I_TO_A table. The data is sent to glTexImage2D like: glTexImage2D(GL_TEXTURE_2D, 0, width, height, 0, GL_ALPHA4, GL_COLOR_INDEX, GL_BITMAP, pixels); Configure the GL 1.2 texture combiners and blend mode to blend the font the way you want: glTexEnvi(GL_TEXTURE_2D, GL_TEXTURE_ENV_MODE, GL_REPLACE); glBlendFunc(GL_SRC_ALPHA, GL_ZERO); glBlendEquation(GL_FUNC_ADD); Then draw a single quad in the color you want the font to be: glColor3f(1.0f, 0.0f, 0.0f); glBegin(GL_QUADS); // or your favorite way to draw glTexCoord2f(...); // location of the character in the atlas glVertex2f(...); ... glEnd(); You could even build those calls into display lists (as you currently do with the glBitmap calls) to keep the changes isolated from the reset of your code. Excluding the call to glBlendEquation, that will work on every OpenGL implementation since GL 1.1, and it will probably be faster than glBitmap on every GL implementation since the data doesn't need to be re-uploaded for each drawing operation. Some implementations may cache the bitmap data in GPU memory with the display list, but there's no guarantee. > Oh and my last machine was an AMD ATi setup, dual radeon graphics, display > lists worked fine using the official drivers, or 3rd party ones, I just hate > APUs which is why I upgraded as soon as the laptop died before the warranty > ran out. So this isn't a case of nvidia drivers being better than the rest. (In reply to comment #6) > (In reply to comment #5) > > I did read it. But alpha blended texturing would also do the job that > > glBitmap does, and is just fine with fixed function GL. > You clearly DID NOT read it: > > > The people who play this game are mostly either kids or computer illiterates > > so if a font texture goes bye bye because of something silly they did, I'll > > be the one who has to personally troubleshoot their issue. I *want* to use > > the proper method, but I've had that many issues in the past with relying on > > users being intelligent enough to keep track of their file system that I now > > know better. I know they're slow, I know they're deprecated and I do care, > > but I don't have much choice if I want to stay sane. > > Besides, I have reported a clearly broken feature of the driver, which > appears to be related to glBitmap, perhaps instead of solely glCallLists, > and it should be fixed. So stop telling me what I should do instead of using > it when I've given my perfectly reasonable reasons and am not interested in > people such as yourself arrogantly parading around like you do. Either help > with fixing the issue that is the driver seemingly falling back to some slow > software implementation or bugger off. We have a small team, and a lot of other things to work on. The probably that we will have time to optimize this case is very, very small. We have never encountered any other application that depends on the performance of glBitmap. -- 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] [PATCH] egl: Allow 24-bit visuals for 32-bit RGBA8888 configs
Two nits. On 02/25/2013 10:51 AM, Ian Romanick wrote: > From: Ian Romanick > > Previously only the 32-bit X visual would match the 32-bit RGBA > configs. This resulted in every config with alpha getting the "magic" > visual whose alpha is used by the compositor. This also resulted in no > multisample visuals being advertised. How many ways could we lose? > > This patch inverts the problem... now you can't get the visual with > alpha used by the compositor even if you want it. I think we need to > invent a new value for EGL_TRANSPARENT_TYPE that apps can use to get > this. I'm surprised that there isn't already a choice for > EGL_TRANSPARENT_ALPHA. > > Signed-off-by: Ian Romanick > Tested-by: Tian Ye > Cc: Kristian Høgsberg > Cc: Chad Versace > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59783 > --- > src/egl/drivers/dri2/egl_dri2.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c > index ae842d7..5d00e4f 100644 > --- a/src/egl/drivers/dri2/egl_dri2.c > +++ b/src/egl/drivers/dri2/egl_dri2.c > @@ -195,7 +195,14 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig > *dri_config, int id, >for (i = 0; attr_list[i] != EGL_NONE; i += 2) > _eglSetConfigKey(&base, attr_list[i], attr_list[i+1]); > > - if (depth > 0 && depth != base.BufferSize) > + /* Allow a 24-bit RGB visual to match a 32-bit RGBA fbconfig. Otherwise > it fbconfig occurs nowhere in this code, and encountering it here confused me. The code is dealing with an EGLConfig, so let's call it what it is. > +* will only match a 32-bit RGBA visual. On a composited window manager > on > +* X11, this will make all of the fbconfigs with destination alpha get > +* blended by the compositor. This is probably not what the application > +* wants... especially on drivers that only have 32-bit RGBA fbconfigs! > +*/ > + if (depth > 0 && > + !(depth == base.BufferSize || (depth == 24 && base.BufferSize == 32))) >return NULL; DeMorgan could simplify this to: depth > 0 && depth != base.BufferSize && !(depth == 24 && base.BufferSize == 32) > > if (rgba_masks && memcmp(rgba_masks, dri_masks, sizeof(dri_masks))) > The code's correct, so feel free to ignore my nits. And THANK YOU for fixing this bug. It's been bothering me for months. Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: Allow 24-bit visuals for 32-bit RGBA8888 configs
On 02/25/2013 04:22 PM, Chad Versace wrote: > Two nits. > > On 02/25/2013 10:51 AM, Ian Romanick wrote: >> From: Ian Romanick >> >> Previously only the 32-bit X visual would match the 32-bit RGBA >> configs. This resulted in every config with alpha getting the "magic" >> visual whose alpha is used by the compositor. This also resulted in no >> multisample visuals being advertised. How many ways could we lose? >> >> This patch inverts the problem... now you can't get the visual with >> alpha used by the compositor even if you want it. I think we need to >> invent a new value for EGL_TRANSPARENT_TYPE that apps can use to get >> this. I'm surprised that there isn't already a choice for >> EGL_TRANSPARENT_ALPHA. >> >> Signed-off-by: Ian Romanick >> Tested-by: Tian Ye >> Cc: Kristian Høgsberg >> Cc: Chad Versace >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59783 >> --- >> src/egl/drivers/dri2/egl_dri2.c | 9 - >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/src/egl/drivers/dri2/egl_dri2.c >> b/src/egl/drivers/dri2/egl_dri2.c >> index ae842d7..5d00e4f 100644 >> --- a/src/egl/drivers/dri2/egl_dri2.c >> +++ b/src/egl/drivers/dri2/egl_dri2.c >> @@ -195,7 +195,14 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig >> *dri_config, int id, >>for (i = 0; attr_list[i] != EGL_NONE; i += 2) >> _eglSetConfigKey(&base, attr_list[i], attr_list[i+1]); >> >> - if (depth > 0 && depth != base.BufferSize) >> + /* Allow a 24-bit RGB visual to match a 32-bit RGBA fbconfig. Otherwise >> it > > fbconfig occurs nowhere in this code, and encountering it here confused me. > The > code is dealing with an EGLConfig, so let's call it what it is. > >> +* will only match a 32-bit RGBA visual. On a composited window manager >> on >> +* X11, this will make all of the fbconfigs with destination alpha get >> +* blended by the compositor. This is probably not what the application >> +* wants... especially on drivers that only have 32-bit RGBA fbconfigs! >> +*/ >> + if (depth > 0 && >> + !(depth == base.BufferSize || (depth == 24 && base.BufferSize == >> 32))) >>return NULL; > > DeMorgan could simplify this to: > > depth > 0 && > depth != base.BufferSize && > !(depth == 24 && base.BufferSize == 32) > >> >> if (rgba_masks && memcmp(rgba_masks, dri_masks, sizeof(dri_masks))) >> > > The code's correct, so feel free to ignore my nits. > And THANK YOU for fixing this bug. It's been bothering me for months. > > Reviewed-by: Chad Versace Well... I shouldn't have said the code is *correct*, because I don't know what correct really means here given the constraints of EGLConfig suckage. The code *correctly* does what you want it do, which trades an unwanted bug to a preferable one. Yeah, that's what I originally meant to say. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #8 from James Ogden --- (In reply to comment #7) > Can you elaborate on what you mean by this? I believe that Eric's proposal > was for you to change the way the application is rendering. I'm not sure > how this has any affect on end-users troubleshooting things. Seriously I feel like I'm a canary, repeating the same tune over and over. I can't rely on a texture based font stored in the game directory, or even the truetype/freetype fonts (except maybe Ubuntu/fixed on Linux and Arial on Windows) because I am catering for people who do weird stuff to their computers and files go missing mysteriously. So instead I rely on something I know is there and if its not, then their system is completely buggered. > I'm assuming that you have fonts stored on disk as bitmap (1-bit per pixel) > images, and that's why you're mentioning filesystems. You can use this data > as a texture by using the GL_PIXEL_MAP_I_TO_A table. The data is sent to > glTexImage2D like: > > glTexImage2D(GL_TEXTURE_2D, 0, width, height, 0, > GL_ALPHA4, GL_COLOR_INDEX, GL_BITMAP, pixels); > > Configure the GL 1.2 texture combiners and blend mode to blend the font the > way you want: > > glTexEnvi(GL_TEXTURE_2D, GL_TEXTURE_ENV_MODE, GL_REPLACE); > glBlendFunc(GL_SRC_ALPHA, GL_ZERO); > glBlendEquation(GL_FUNC_ADD); > > Then draw a single quad in the color you want the font to be: > > glColor3f(1.0f, 0.0f, 0.0f); > glBegin(GL_QUADS); // or your favorite way to draw > glTexCoord2f(...); // location of the character in the atlas > glVertex2f(...); > ... > glEnd(); > > You could even build those calls into display lists (as you currently do > with the glBitmap calls) to keep the changes isolated from the reset of your > code. > > Excluding the call to glBlendEquation, that will work on every OpenGL > implementation since GL 1.1, and it will probably be faster than glBitmap on > every GL implementation since the data doesn't need to be re-uploaded for > each drawing operation. I know how to do all of this, again I do NOT have a font texture file, I rely on system installed fonts because if they aren't there, then the system is buggered to hell. > Some implementations may cache the bitmap data in GPU memory with the > display list, but there's no guarantee. Yes I am aware of that, but this isn't an implementation specific thing, it's Mesa specific on all intel renderers for Linux. > We have a small team, and a lot of other things to work on. The probably > that we will have time to optimize this case is very, very small. We have > never encountered any other application that depends on the performance of > glBitmap. Hardly an excuse if you ask me, I have a two man team working on a big project but we never make excuses like that, we simply prioritise any issues we encounter and get to them when we can. And this is probably why no one ports games over from Windows, because the Mesa implementations are horrible, fantastic fast when you use Core 3.0 stuff and 2.1 stuff, but otherwise you'd never be able to port golden titles from the 1990's over without gutting their rendering systems and rewriting them yourself by hand. -- 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] [PATCH 0/9] remove mfeatures.h file
On 02/25/2013 11:10 AM, Jordan Justen wrote: Reviewed-by: Jordan Justen On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote: This series removes the dependencies on the mfeatures.h file and the file itself. I'd appreciated someone doing a test build of this series to double-check my work. Do you have a public repo where you push changesets like this? No, but here's a tarball of the patch series. I added a tenth patch that touches intel_screen.c -Brian mfeatures.tar.gz Description: Unix tar archive ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/9] glapi: remove FEATURE_remap_table test (it's always defined)
On 02/25/2013 12:11 PM, Ian Romanick wrote: On 02/23/2013 07:26 AM, Brian Paul wrote: --- src/mapi/glapi/gen/gl_table.py | 15 --- 1 files changed, 0 insertions(+), 15 deletions(-) diff --git a/src/mapi/glapi/gen/gl_table.py b/src/mapi/glapi/gen/gl_table.py index 382eaaf..99957f6 100644 --- a/src/mapi/glapi/gen/gl_table.py +++ b/src/mapi/glapi/gen/gl_table.py @@ -147,17 +147,6 @@ class PrintRemapTable(gl_XML.gl_print_base): for f, index in abi_functions: print '#define _gloffset_%s %d' % (f.name, f.offset) - print '' - print '#if !FEATURE_remap_table' - print '' - - for f, index in functions: - print '#define _gloffset_%s %d' % (f.name, f.offset) - Even for non-DRI builds? Yes, I tested both DRI and non-DRI builds and FEATURE_remap_table was defined for both. But as I said, I'd appreciate someone else doing a build or two to double-check. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #9 from Ian Romanick --- (In reply to comment #8) > (In reply to comment #7) > > Can you elaborate on what you mean by this? I believe that Eric's proposal > > was for you to change the way the application is rendering. I'm not sure > > how this has any affect on end-users troubleshooting things. > Seriously I feel like I'm a canary, repeating the same tune over and over. > I can't rely on a texture based font stored in the game directory, or even > the truetype/freetype fonts (except maybe Ubuntu/fixed on Linux and Arial on > Windows) because I am catering for people who do weird stuff to their > computers and files go missing mysteriously. So instead I rely on something > I know is there and if its not, then their system is completely buggered. > > > I'm assuming that you have fonts stored on disk as bitmap (1-bit per pixel) > > images, and that's why you're mentioning filesystems. You can use this data > > as a texture by using the GL_PIXEL_MAP_I_TO_A table. The data is sent to > > glTexImage2D like: > > > > glTexImage2D(GL_TEXTURE_2D, 0, width, height, 0, > > GL_ALPHA4, GL_COLOR_INDEX, GL_BITMAP, pixels); > > > > Configure the GL 1.2 texture combiners and blend mode to blend the font the > > way you want: > > > > glTexEnvi(GL_TEXTURE_2D, GL_TEXTURE_ENV_MODE, GL_REPLACE); > > glBlendFunc(GL_SRC_ALPHA, GL_ZERO); > > glBlendEquation(GL_FUNC_ADD); > > > > Then draw a single quad in the color you want the font to be: > > > > glColor3f(1.0f, 0.0f, 0.0f); > > glBegin(GL_QUADS); // or your favorite way to draw > > glTexCoord2f(...); // location of the character in the atlas > > glVertex2f(...); > > ... > > glEnd(); > > > > You could even build those calls into display lists (as you currently do > > with the glBitmap calls) to keep the changes isolated from the reset of your > > code. > > > > Excluding the call to glBlendEquation, that will work on every OpenGL > > implementation since GL 1.1, and it will probably be faster than glBitmap on > > every GL implementation since the data doesn't need to be re-uploaded for > > each drawing operation. > I know how to do all of this, again I do NOT have a font texture file, I > rely on system installed fonts because if they aren't there, then the system > is buggered to hell. You're repeating my point, and that's confusing. It doesn't matter how your fonts are stored. You can send *exactly the same bits* into OpenGL as a texture or a bitmap. -- 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 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 James Ogden changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTOURBUG |--- --- Comment #10 from James Ogden --- (In reply to comment #9) > You're repeating my point, and that's confusing. It doesn't matter how your > fonts are stored. You can send *exactly the same bits* into OpenGL as a > texture or a bitmap. No I'm not repeating *your* point. I'm repeating my point that you are .clearly not understanding. I am loading these in using the XFont in glXBitmapFont or whatever the X version of wglFontBitmaps is. I have no control of how these get loaded in or what they do under the hood. Like I said, I am not relying on a file that may or may not exist in the game directory, I'm relying on the system. Oh and this issue isn't resolved, perhaps you should not be so immature and disregard an issue as not your own doing when clearly it is. Why don't you face up to the problem and fix it or atleast add it to your supposedly big "to do" list that your tiny team should be slogging through. -- 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 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 Ian Romanick changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |NOTOURBUG --- Comment #11 from Ian Romanick --- We've tried really hard to help you, and all of your responses have been filled with rudeness and belligerence. I think we're done trying to help you. You can reopen the bug if you want, but we have no plans to do anything with it. Have a nice day. -- 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] [PATCH 9/9] mesa: remove mfeatures.h
On Sat, Feb 23, 2013 at 7:26 AM, Brian Paul wrote: > No longer needed. > --- > src/mesa/main/mfeatures.h | 53 > - > 1 files changed, 0 insertions(+), 53 deletions(-) > delete mode 100644 src/mesa/main/mfeatures.h > > diff --git a/src/mesa/main/mfeatures.h b/src/mesa/main/mfeatures.h > deleted file mode 100644 > index 55e9cf9..000 > --- a/src/mesa/main/mfeatures.h > +++ /dev/null > @@ -1,53 +0,0 @@ > -/* > - * Mesa 3-D graphics library > - * Version: 7.1 > - * > - * Copyright (C) 1999-2008 Brian Paul All Rights Reserved. > - * > - * 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. > - * > - * 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 > - * BRIAN PAUL 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. > - */ > - > - > -/** > - * \file mfeatures.h > - * Flags to enable/disable specific parts of the API. > - */ > - > -#ifndef FEATURES_H > -#define FEATURES_H > - > -#ifndef FEATURE_ES1 > -#define FEATURE_ES1 0 > -#endif > -#ifndef FEATURE_ES2 > -#define FEATURE_ES2 0 > -#endif > - > -#define FEATURE_ES (FEATURE_ES1 || FEATURE_ES2) > - > -#ifndef FEATURE_GL > -#define FEATURE_GL !FEATURE_ES > -#endif > - > -#if defined(IN_DRI_DRIVER) || (FEATURE_GL + FEATURE_ES1 + FEATURE_ES2 > 1) > -#define FEATURE_remap_table 1 > -#else > -#define FEATURE_remap_table 0 > -#endif > - > -#endif /* FEATURES_H */ > -- > 1.7.3.4 The series looks good to me. Have a Reviewed-by: Matt Turner Also, I think the macro IN_DRI_DRIVER is now unused, so it should be removed from configure.ac and src/mesa/SConscript. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 James Ogden changed: What|Removed |Added Hardware|All |x86-64 (AMD64) Resolution|NOTOURBUG |WONTFIX Severity|major |critical Priority|medium |highest Version|unspecified |9.0 --- Comment #12 from James Ogden --- (In reply to comment #11) > We've tried really hard to help you, and all of your responses have been > filled with rudeness and belligerence. I think we're done trying to help > you. You can reopen the bug if you want, but we have no plans to do > anything with it. > > Have a nice day. It's nice to see the world is still full of people who are happy to live with broken utilities. It really is quite sad that a company like NVidia - or AMD even - who have to have their hands forced by a company like Valve can at least produce working drivers for their devices while you lot who supposedly work for the community and produce things by the community can't even acknowledge and attempt to fix a problem brought up by someone. And then go so far as to be arrogant and ignore everything said person says and then use their frustration against them to further ignore the issue. Good day, take your shitty drivers and wallow in your arrogance and self righteousness. It's people like you that drive other people away from using bug reporting systems to try and find a proper solution to an issue and resolve it for future cases, and even deter people from using the operating system the issue originates on. :) Marking this as RESOLVED - WONTFIX, since that's the reality of the situation, NOTOURBUG is just pathetic really. -- 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] [PATCH 0/9] remove mfeatures.h file
On 02/25/2013 05:17 PM, Brian Paul wrote: On 02/25/2013 11:10 AM, Jordan Justen wrote: Reviewed-by: Jordan Justen On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote: This series removes the dependencies on the mfeatures.h file and the file itself. I'd appreciated someone doing a test build of this series to double-check my work. Do you have a public repo where you push changesets like this? No, but here's a tarball of the patch series. I added a tenth patch that touches intel_screen.c In the future, a git tree for a large patch series would be a lot better. A lot of times git-am will fail if the tip of the tree has changed much since the patches were sent out. That can make it a lot harder to build, test, etc. large series. One of the guys around here suggested this morning that we make that part of the patch policy, and I think that's a good idea. Everyone with commit access to any project hosted on fdo has (should have?) an account on people.freedesktop.org, so there should be no problems with hosting. For what value of N should we set the bound? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #13 from Brian Paul --- (In reply to comment #11) > We've tried really hard to help you, and all of your responses have been > filled with rudeness and belligerence. Ian, I don't think James is being unreasonable. He's simply trying to use a legacy OpenGL feature (that works fine with other drivers) and is frustrated that nobody seems interested in helping him. And simply saying "just forget about glXUseXFonts and use textures" doesn't really help either, given the other constraints that he described (and were probably glossed over by others). James, I think I have a possible path to a solution for you. The texture map approach really is the best way to go, but you're probably wondering about how to get your font glyphs without pulling in some new font utility/library, font files, etc. If you look at Mesa's src/mesa/drivers/x11/xfonts.c file you'll find an implementation of glXUseXFont(). It uses some Xlib code to convert X font glyphs into bitmap images. I think you could adapt that code so that you'd save the bitmap images in some data structure, then implement a simple bitmap character renderer to render strings into a texture image (see also src/mesa/state_trackers/st_cb_bitmap.c and the _mesa_expand_bitmap() function). Then render the texture/string with GL_ALPHA_TEST or blending. I think you could do all this in a few hundred lines of code (most of it from xfonts.c). Maybe there's even some code on the net that does this already. Anyway, you could build new code this with your other app sources and avoid any new external dependencies. Hope that helps. -- 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] [PATCH 0/9] remove mfeatures.h file
On 02/25/2013 06:57 PM, Ian Romanick wrote: On 02/25/2013 05:17 PM, Brian Paul wrote: On 02/25/2013 11:10 AM, Jordan Justen wrote: Reviewed-by: Jordan Justen On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote: This series removes the dependencies on the mfeatures.h file and the file itself. I'd appreciated someone doing a test build of this series to double-check my work. Do you have a public repo where you push changesets like this? No, but here's a tarball of the patch series. I added a tenth patch that touches intel_screen.c In the future, a git tree for a large patch series would be a lot better. A lot of times git-am will fail if the tip of the tree has changed much since the patches were sent out. That can make it a lot harder to build, test, etc. large series. I could simply put the code on a feature branch tomorrow. I need to call it a day soon. I've never setup a git repo for my home fdo.o account. To be honest, I'd have to do some digging around to figure that out. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #14 from Ian Romanick --- (In reply to comment #12) > (In reply to comment #11) > > We've tried really hard to help you, and all of your responses have been > > filled with rudeness and belligerence. I think we're done trying to help > > you. You can reopen the bug if you want, but we have no plans to do > > anything with it. > > > > Have a nice day. > It's nice to see the world is still full of people who are happy to live > with broken utilities. > > It really is quite sad that a company like NVidia - or AMD even - who have > to have their hands forced by a company like Valve can at least produce > working drivers for their devices while you lot who supposedly work for the > community and produce things by the community can't even acknowledge and > attempt to fix a problem brought up by someone. And then go so far as to be > arrogant and ignore everything said person says and then use their > frustration against them to further ignore the issue. > > Good day, take your shitty drivers and wallow in your arrogance and self > righteousness. It's people like you that drive other people away from using > bug reporting systems to try and find a proper solution to an issue and > resolve it for future cases, and even deter people from using the operating > system the issue originates on. 1. Nobody was arrogant or self righteous. I went back and read every message in this thread several times. Based on incomplete information, we tried to offer detailed suggestions of how to make your application work better with our drivers. 2. Key information like "I'm using glXUseXFont so I never interact with the font data at all in any way" was omitted until message 10 in the thread. Up to that point, at least five different people that read the bug thought your application was calling glBitmap directly. There was certainly no reason to think otherwise. That changes things a lot. 3. Nobody wants to volunteer to be yelled at and called names in a bug tracker. We didn't tell you to "take your shitty ..." and do something with it. We didn't tell you to "bugger off." I don't expect that you'd talk to the guy behind the counter at the coffee shop that way. If you did, they'd probably kick you out permanently. I'm surprised that you think it's okay to talk to us that way. In an asynchronous communication mechanism, there's plenty of time to self-censor. I'm somewhat infamous for... speaking with rage before thinking, so I understand better than most how difficult that can be. 4. You suggested that we should "simply prioritise any issues we encounter and get to them when we can." In comment #7 I tried to describe exactly that. Where to you prioritize an issue seen by one user versus issues seen by many users? Let's start over. In comment #2, Ken asked for an apitrace of your application. Can you provide that? -- 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 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #15 from Brian Paul --- (In reply to comment #13) > already. Anyway, you could build new code this with your other app sources Err, "build this new code with" ... -- 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 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 James Ogden changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #16 from James Ogden --- (In reply to comment #13) > (In reply to comment #11) > > We've tried really hard to help you, and all of your responses have been > > filled with rudeness and belligerence. > > Ian, I don't think James is being unreasonable. He's simply trying to use a > legacy OpenGL feature (that works fine with other drivers) and is frustrated > that nobody seems interested in helping him. And simply saying "just forget > about glXUseXFonts and use textures" doesn't really help either, given the > other constraints that he described (and were probably glossed over by > others). No I didn't think I was being unreasonable either, being a complete a**hole maybe, but not unreasonable. > James, I think I have a possible path to a solution for you. The texture > map approach really is the best way to go, but you're probably wondering > about how to get your font glyphs without pulling in some new font > utility/library, font files, etc. I know it's the best way to go, I'd prefer it since the game has a TTF dedicated to it that wasn't used originally back in the 90s due to the developers being too lazy to install it with the game. But as we all know from my previous comments that I'd rather rely on the system :) > If you look at Mesa's src/mesa/drivers/x11/xfonts.c file you'll find an > implementation of glXUseXFont(). It uses some Xlib code to convert X font > glyphs into bitmap images. I think you could adapt that code so that you'd > save the bitmap images in some data structure, then implement a simple > bitmap character renderer to render strings into a texture image (see also > src/mesa/state_trackers/st_cb_bitmap.c and the _mesa_expand_bitmap() > function). Then render the texture/string with GL_ALPHA_TEST or blending. > I think you could do all this in a few hundred lines of code (most of it > from xfonts.c). Maybe there's even some code on the net that does this > already. Anyway, you could build new code this with your other app sources > and avoid any new external dependencies. I've already begun the process of writing a setup like this and manually creating a texture at load-time with the font glyph data stored in an appropriate structure. Thanks for suggesting the source, I would have just wrote the whole thing myself from scratch but now I may take a look at how it's done in Mesa's source. > Hope that helps. Kind of, definitely a much better response than I initially received, thank you Brian. (In Reply to Comment #12) > Let's start over. > > In comment #2, Ken asked for an apitrace of your application. Can you > provide that? Building the utility and will return with the dump as soon as I'm done. -- 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] [PATCH 0/9] remove mfeatures.h file
On Mon, Feb 25, 2013 at 6:48 PM, Brian Paul wrote: > On 02/25/2013 06:57 PM, Ian Romanick wrote: >> >> On 02/25/2013 05:17 PM, Brian Paul wrote: >>> >>> On 02/25/2013 11:10 AM, Jordan Justen wrote: Reviewed-by: Jordan Justen On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote: > > This series removes the dependencies on the mfeatures.h file and the > file > itself. > > I'd appreciated someone doing a test build of this series to > double-check my > work. Do you have a public repo where you push changesets like this? >>> >>> >>> No, but here's a tarball of the patch series. I added a tenth patch >>> that touches intel_screen.c >> >> >> In the future, a git tree for a large patch series would be a lot >> better. A lot of times git-am will fail if the tip of the tree has >> changed much since the patches were sent out. That can make it a lot >> harder to build, test, etc. large series. > > > I could simply put the code on a feature branch tomorrow. I need to call it > a day soon. > > I've never setup a git repo for my home fdo.o account. To be honest, I'd > have to do some digging around to figure that out. In fact it's a pretty easy process. See http://www.freedesktop.org/wiki/Infrastructure/git/RepositoryAdmin for instructions. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61412] glCallLists/glBitmap calls slow on Intel implementation of Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=61412 --- Comment #17 from James Ogden --- Here is a raw copy of the .trace from the app, its 10mb (dump was 20mb) because it takes 4 seconds to quit the game so it continued tracing the renderer. http://www.mediafire.com/?2fiejjbonnu9e42 -- 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] [PATCH 0/9] remove mfeatures.h file
Ian Romanick writes: > On 02/25/2013 05:17 PM, Brian Paul wrote: >> On 02/25/2013 11:10 AM, Jordan Justen wrote: >>> Reviewed-by: Jordan Justen >>> >>> On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote: This series removes the dependencies on the mfeatures.h file and the file itself. I'd appreciated someone doing a test build of this series to double-check my work. >>> >>> Do you have a public repo where you push changesets like this? >> >> No, but here's a tarball of the patch series. I added a tenth patch >> that touches intel_screen.c > > In the future, a git tree for a large patch series would be a lot > better. A lot of times git-am will fail if the tip of the tree has > changed much since the patches were sent out. That can make it a lot > harder to build, test, etc. large series. > > One of the guys around here suggested this morning that we make that > part of the patch policy, and I think that's a good idea. Everyone with > commit access to any project hosted on fdo has (should have?) an account > on people.freedesktop.org, so there should be no problems with hosting. Incidentally, that was in the context of my debug series, and I ended up agreeing that it's pretty reasonable -- people often end up polling the submitter to put up a tree, and it costs me little to mention a branch name up front. It can help review when you get to go grep the tree after the fact, which can show things hard to see in a diff. > For what value of N should we set the bound? I'm not that into hard and fast rules, but it seems likely that if I thought there was enough extra context to deserve "--compose" for my series, it probably also deserves posting to a branch in my personal tree. And especially for patches that have sed-job aspects (granted, not the patch series I just did, but several I've been involved in recently) pgpDU7bIwn_0l.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] texobj: add verbose api trace messages to several routines
Jordan Justen writes: > Motivated by wanting to see if GenTextures was called by an > application while debugging another Steam overlay issue. Making a systematic MESA_DEBUG=api using dispatch tables and code generation seems like it would be nice instead of adding it ad-hoc. Not something against this patch, just maybe a project for a janitor list if we have one. apitrace seems like it would be to replace it, but I've seen enough apps where it doesn't work (and in this case with the steam overlay it definitely doesn't) that we can't just rely on that. pgpeNFk19vHKE.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] New EGL extension: EGL_EXT_platform_display
On Mon, 25 Feb 2013 09:09:22 -0800 Chad Versace wrote: > > On 02/24/2013 11:46 PM, Pekka Paalanen wrote:> On Tue, 19 Feb 2013 08:20:51 > -0800 > > Chad Versace wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> I'm seeking feedback on an EGL extension that I'm drafting. The ideas have > >> already been discussed at Khronos meetings to a good reception, but I want > >> feedback from Mesa developers too. > >> > >> Summary > >> - --- > >> The extension, tentatively named EGL_EXT_platform_display, enables EGL > >> clients > >> to specify to which platform (X11, Wayland, gbm, etc) an EGL resource > >> (EGLDisplay, EGLSurface, etc) belongs when the resource is derived from > >> a platform-native type. As a corollary, the extension enables the creation > >> of > >> EGL resources from different platforms within a single process. > >> > >> > >> Feedback > >> - > >> I'd like to hear feeback about the details below. Do you see any potential > >> problems? Is it lacking a feature that you believe should be present? > >> > >> > >> Details > >> - --- > >> The draft extension defines the following new functions: > >> > >> // This is the extenion's key function. > >> // > >> EGLDisplay > >> eglGetPlatformDisplayEXT(EGLenum platform, void *native_display); > >> > >> // The two eglCreate functions below differ from their core > >> counterparts > >> // only in their signature. The EGLNative types are replaced with > >> void*. > >> // This makes the signature agnostic to which platform the native > >> resource > >> // belongs. > >> > >> EGLSurface > >> eglCreatePlatformWindowSurfaceEXT(EGLDisplay dpy, > >> EGLConfig config, > >> void *native_window, > >> const EGLint *attrib_list); > >> > >> EGLSurface > >> eglCreatePlatformPixmapSurface(EGLDisplay dpy, > >>EGLConfig config, > >>void *native_pixmap, > >>const EGLint *attrib_list); > >> > >> Valid values for `platform` are defined by layered extensions. For > >> example, EGL_EXT_platform_x11 defines EGL_PLATFORM_X11, and > >> EGL_EXT_platform_wayland defines EGL_PLATFORM_WAYLAND. > >> > >> Also, the layered extensions specify which native types should be passed as > >> the native parameters. For example, EGL_EXT_platform_wayland specifies > >> that, > >> when calling eglCreatePlatformWindowSurfaceEXT with a display that was > >> derived > >> from a Wayland display, then the native_window parameter must be `struct > >> wl_egl_window*`. Analogously, EGL_EXT_platform_x11 specifies that > >> native_window must be `Window*`. > >> > >> > >> Example Code for X11 > >> - > >> // The internal representation of the egl_dpy, created below, remembers > >> that > >> // it was derived from an Xlib display. > >> > >> Display *xlib_dpy = XOpenDisplay(NULL); > >> EGLDisplay *egl_dpy = eglGetPlatformDisplayEXT(EGL_PLATFORM_X11, xlib_dpy); > >> > >> EGLConfig config; > >> eglChooseConfig(egl_dpy, &config, ...); > >> > >> // Since egl_dpy remembers that it was derived from an Xlib display, when > >> // creating the EGLSurface below libEGL internally casts the > >> // `(void*) &xlib_win` to `Window*`. > >> > >> Window xlib_win = XCreateWindow(xlib_dpy, ...); > >> EGLSurface egl_surface = eglCreatePlatformWindowSurfaceEXT(egl_dpy, config, > >>(void*) > >> &xlib_win, > >>NULL); > >> > >> Example Code for Wayland > >> - > >> // The internal representation of the egl_dpy, created below, remembers > >> that > >> // it was derived from a Wayland display. > >> > >> struct wl_display *wl_dpy = wl_display_connect(NULL); > >> EGLDisplay *egl_dpy = eglGetPlatformDisplay(EGL_PLATFORM_WAYLAND, wl_dpy); > >> > >> > >> EGLConfig config; > >> eglChooseConfig(egl_dpy, &config, ...); > >> > >> // Since egl_dpy remembers that it was derived from an Wayland display, > >> when > >> // creating the EGLSurface below libEGL internally casts the > >> // `(void*) wl_win` to `struct wl_egl_window*`. > >> > >> struct wl_egl_window *wl_win = wl_egl_window_create(...); > >> EGLSurface egl_surface = eglCreateWindowSurface(egl_dpy, config, > >>(void*) wl_win, NULL); > > > > Hi, > > > > is it possible to build a binary, that will use this extension if it is > > present in whatever libEGL is available at runtime, and if it is not, > > fall back gracefully to using the core eglGetDisplay()? > > > > Or is this specifically not supported, since I cannot see a way for > > runtime detection of this extension? > > > > Or is the runtime detection left unspecified, so one could do it with > > e.g. get
