Re: [Mesa-dev] big endian: r600g
Best thing to do is to hire some developer to do the work for you. If it knows Mesa well, this can be cheaper and faster than doing it yourself. I know Timothy Arceri ( t_arc...@yahoo.com.au) was doing some Mesa work for pay in the past. On Wed, Aug 19, 2015 at 10:34 AM, Christian Zigotzky chzigot...@xenosoft.de wrote: Hi Michel, Thank you for your answer. I don't have an idea anymore. Could you tell me which files we have to modify? Is it possible to port the AMD Catalyst driver to the PowerPC platform? If yes do you know how can I in touch with AMD? Please help us. We want to release new PowerPC desktop systems but without 3D acceleration it wouldn't be so nice. Cheers, Christian On 19 August 2015 at 09:12 AM, Michel Dänzer wrote: On 19.08.2015 15:02, Christian Zigotzky wrote: Could you please adapt the r600g driver for the changed PIPE_FORMAT_* semantics for big endian machines, please? All Power Mac and AMIGA one users can't use AMD Radeon HD7xxx or higher for 3D acceleration. The r600g driver needs to be adapted to changes in the way the Gallium3D infrastructure deals with big endian hosts. Bug report: https://bugs.freedesktop.org/show_bug.cgi?id=72877 I'm afraid this kind of request isn't going to get you anywhere. The problem is that there's nobody working on Mesa who cares about those platforms. You'd need to find somebody who cares about those platforms and who can work on fixing the issues. ___ 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] [PATCHES] Tessellation is here
Wonderful Marek. Many thanks to you all. I hope till the end of the year we will have OGL 4.3 in Mesa. On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák mar...@gmail.com wrote: You can also use this for nicer reviewing: http://cgit.freedesktop.org/~mareko/mesa/log/?h=tessellation-review Please note that there are differences from Chris Forbes's tessellation branches. I think I modified almost all patches when I was reviewing them, fixing them, and cleaning them up. Marek On Wed, Jun 17, 2015 at 1:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, First, I'd like to thank Fabian Bieler, Chris Forbes, and Ilia Mirkin for their contributions to this. The development of tessellation has reached the point that the only way to make it better and more compliant is to write piglit tests that help find small bugs that are difficult to catch during code review. According to piglit, it's already more compliant than the NVIDIA driver. (The NVIDIA GLSL compiler sometimes even dies with an internal error on some of the variable indexing tests. I haven't tested Catalyst.) Other than piglit, the following apps have been tested: - Unigine Heaven 4.0 (wireframe both on and off) - TessMark 0.3.0 * - GpuTest 0.7.0 containing a newer version of TessMark * - Tutorials 30 and 31 from http://ogldev.atspace.co.uk/ * (* These don't work with the OpenGL Core profile and need overrides and code hacks to enable OpenGL 4.0 Compatibility) The RadeonSI driver support is complete and requires LLVM 3.6.2. There is just one small bug with GpuTest 0.7.0. The patches will be split up into 3 series: 1) Mesa + GLSL 2) State tracker 3) Radeonsi docs/GL3.txt | 2 +- docs/relnotes/10.7.0.html | 1 + src/gallium/docs/source/screen.rst| 4 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c| 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c| 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c| 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 1 + src/gallium/drivers/r300/r300_screen.c| 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeon/r600_pipe_common.c | 6 + src/gallium/drivers/radeon/r600_pipe_common.h | 20 +- src/gallium/drivers/radeon/radeon_llvm.h | 14 +- src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 + .../drivers/radeon/radeon_setup_tgsi_llvm.c | 40 +- src/gallium/drivers/radeonsi/si_blit.c| 2 + src/gallium/drivers/radeonsi/si_descriptors.c | 251 -- src/gallium/drivers/radeonsi/si_hw_context.c | 8 + src/gallium/drivers/radeonsi/si_pipe.c| 22 +- src/gallium/drivers/radeonsi/si_pipe.h| 29 +- src/gallium/drivers/radeonsi/si_shader.c | 835 ++-- src/gallium/drivers/radeonsi/si_shader.h | 123 ++- src/gallium/drivers/radeonsi/si_state.c | 47 +- src/gallium/drivers/radeonsi/si_state.h | 23 +- src/gallium/drivers/radeonsi/si_state_draw.c | 217 - src/gallium/drivers/radeonsi/si_state_shaders.c | 494 +++- src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c| 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/glsl/Makefile.sources | 1 + src/glsl/ast.h| 55 +- src/glsl/ast_array_index.cpp | 47 +- src/glsl/ast_to_hir.cpp | 350 +++- src/glsl/ast_type.cpp | 115 ++- src/glsl/builtin_functions.cpp| 4 +- src/glsl/builtin_variables.cpp| 112 ++- src/glsl/glcpp/glcpp-parse.y | 3 + src/glsl/glsl_lexer.ll| 5 +- src/glsl/glsl_parser.yy | 133 +++- src/glsl/glsl_parser_extras.cpp | 60 +- src/glsl/glsl_parser_extras.h | 48 +- src/glsl/glsl_types.cpp | 5 + src/glsl/glsl_types.h | 6 + src/glsl/ir.cpp | 2 + src/glsl/ir.h | 1 + src/glsl/ir_optimization.h| 8 +- src/glsl/ir_print_visitor.cpp | 5 +- src/glsl/ir_reader.cpp| 2 + src/glsl/ir_set_program_inouts.cpp| 96 ++- src/glsl/link_interface_blocks.cpp|
Re: [Mesa-dev] [PATCHES] Tessellation is here
I only guess, that TESS is too much for the software rasterization, so they may very well fake it. On Wed, Jun 17, 2015 at 3:21 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov drago.iva...@gmail.com wrote: Wonderful Marek. Many thanks to you all. I hope till the end of the year we will have OGL 4.3 in Mesa. Is LLVMpipe (and software rasterziation) also supported? Ilyes On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák mar...@gmail.com wrote: You can also use this for nicer reviewing: http://cgit.freedesktop.org/~mareko/mesa/log/?h=tessellation-review Please note that there are differences from Chris Forbes's tessellation branches. I think I modified almost all patches when I was reviewing them, fixing them, and cleaning them up. Marek On Wed, Jun 17, 2015 at 1:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, First, I'd like to thank Fabian Bieler, Chris Forbes, and Ilia Mirkin for their contributions to this. The development of tessellation has reached the point that the only way to make it better and more compliant is to write piglit tests that help find small bugs that are difficult to catch during code review. According to piglit, it's already more compliant than the NVIDIA driver. (The NVIDIA GLSL compiler sometimes even dies with an internal error on some of the variable indexing tests. I haven't tested Catalyst.) Other than piglit, the following apps have been tested: - Unigine Heaven 4.0 (wireframe both on and off) - TessMark 0.3.0 * - GpuTest 0.7.0 containing a newer version of TessMark * - Tutorials 30 and 31 from http://ogldev.atspace.co.uk/ * (* These don't work with the OpenGL Core profile and need overrides and code hacks to enable OpenGL 4.0 Compatibility) The RadeonSI driver support is complete and requires LLVM 3.6.2. There is just one small bug with GpuTest 0.7.0. The patches will be split up into 3 series: 1) Mesa + GLSL 2) State tracker 3) Radeonsi docs/GL3.txt | 2 +- docs/relnotes/10.7.0.html | 1 + src/gallium/docs/source/screen.rst| 4 + src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c| 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c| 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c| 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c| 1 + src/gallium/drivers/r300/r300_screen.c| 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeon/r600_pipe_common.c | 6 + src/gallium/drivers/radeon/r600_pipe_common.h | 20 +- src/gallium/drivers/radeon/radeon_llvm.h | 14 +- src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 + .../drivers/radeon/radeon_setup_tgsi_llvm.c | 40 +- src/gallium/drivers/radeonsi/si_blit.c| 2 + src/gallium/drivers/radeonsi/si_descriptors.c | 251 -- src/gallium/drivers/radeonsi/si_hw_context.c | 8 + src/gallium/drivers/radeonsi/si_pipe.c| 22 +- src/gallium/drivers/radeonsi/si_pipe.h| 29 +- src/gallium/drivers/radeonsi/si_shader.c | 835 ++-- src/gallium/drivers/radeonsi/si_shader.h | 123 ++- src/gallium/drivers/radeonsi/si_state.c | 47 +- src/gallium/drivers/radeonsi/si_state.h | 23 +- src/gallium/drivers/radeonsi/si_state_draw.c | 217 - src/gallium/drivers/radeonsi/si_state_shaders.c | 494 +++- src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c| 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/glsl/Makefile.sources | 1 + src/glsl/ast.h| 55 +- src/glsl/ast_array_index.cpp | 47 +- src/glsl/ast_to_hir.cpp | 350 +++- src/glsl/ast_type.cpp | 115 ++- src/glsl/builtin_functions.cpp| 4 +- src/glsl/builtin_variables.cpp| 112 ++- src/glsl/glcpp/glcpp-parse.y | 3 + src/glsl/glsl_lexer.ll| 5 +- src/glsl/glsl_parser.yy | 133 +++- src/glsl/glsl_parser_extras.cpp | 60 +- src/glsl/glsl_parser_extras.h | 48 +- src/glsl/glsl_types.cpp | 5 + src/glsl/glsl_types.h | 6 + src/glsl/ir.cpp | 2 + src/glsl/ir.h
Re: [Mesa-dev] Mesa 10.6 release plan
If these two go: GL_ARB_shader_subroutine GL_ARB_tessellation_shader Should the Mesa release be called Mesa 11? Since new major of OGL is reached. Dragomir On Sat, May 16, 2015 at 8:11 PM, Jason Ekstrand ja...@jlekstrand.net wrote: There was some discussion on IRC today about what the official date is. A bunch of Intel people have been working under the assumption that it's the end of next week, not this week. Was there some non-public discussion and a decision to slip? We would like to get two things in before the branch point: 1) The MUL series Matt just sent 2) Use NIR by default for GEN8+ VS. If we don't want to slip too far we can probably get both in by Monday. --Jason On Fri, May 8, 2015 at 8:26 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Hello all, On 21 April 2015 at 13:40, Emil Velikov emil.l.veli...@gmail.com wrote: Hi all, Here is the preliminary release schedule for Mesa 10.6. Personally I would love if we can go up to Mesa 11.0 (Spinal Tap anyone ?) although it might happen with the September release. May 15th 2015 - Feature freeze/Release candidate 1 May 22st 2015 - Release candidate 2 May 29th 2015 - Release candidate 3 June 5th 2015 - Release candidate 4/Mesa 10.6.0 This means that we have roughly four weeks to get new features in, and another four weeks to get all the serious bugs sorted out. Does this sound reasonable with the different teams ? If anyone has something special in mind please speak up. This is a gentle reminder that we have one week until the 10.6 branch point. As far as I can see we have a few extensions which may or may not make it in time. I would be fine if we need an extra week to finish up any of the following extensions considering their importance and/or how long people have been working on them. If you feel the same way please speak up, otherwise the schedule will stay as outlined previously. GL_ARB_shader_subroutine GL_ARB_tessellation_shader GL_ARB_shader_image_load_store GL_ARB_direct_state_access Thanks Emil ___ 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] i965: Enable INTEL_performance_query for Gen5+.
What about other drivers supporting `AMD_performance_monitor`? Are there any?
On Wed, Mar 12, 2014 at 2:54 PM, Petri Latvala petri.latv...@intel.com wrote:
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/mesa/drivers/dri/i965/intel_extensions.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 5094c2b..78bf5b4 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -307,8 +307,10 @@ intelInitExtensions(struct gl_context *ctx)
ctx-Extensions.ARB_stencil_texturing = true;
}
- if (brw-gen == 5 || can_write_oacontrol(brw))
+ if (brw-gen == 5 || can_write_oacontrol(brw)) {
ctx-Extensions.AMD_performance_monitor = true;
+ ctx-Extensions.INTEL_performance_query = true;
+ }
if (ctx-API == API_OPENGL_CORE)
ctx-Extensions.ARB_base_instance = true;
--
1.9.0
___
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] Fw: Taking part in MESA development - Dissertation Project
They are not a newbie task, too. On Fri, Nov 29, 2013 at 3:34 PM, Marek Olšák mar...@gmail.com wrote: The tesselation shaders and the compute shader are definitely not trivial. Marek On Fri, Nov 29, 2013 at 12:01 PM, Timothy Arceri t_arc...@yahoo.com.au wrote: On Fri, 2013-11-29 at 09:36 +0200, Petri Latvala wrote: On 11/28/2013 11:15 PM, Timothy Arceri wrote: Hi guys, I received the following submitted as an Issue on my github account. Maybe someone here has a project they can suggest. Is NewbieProjects too newbie for this? http://wiki.freedesktop.org/dri/NewbieProjects/ Most of the remaining work seems to be partly done already so I don't think what remains qualifies as non-trivial. Maybe there are some left over google summer of code projects that were not undertaken that would be of interest: http://www.x.org/wiki/SummerOfCodeIdeas/ ___ 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 mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] mesa: Bump version to 11.0.0.
The numbering has just in relation with DirectX support numbering. Mesa 10.0 - OpenGL 3.3 == DirectX10. And now you want to brake this :) On Fri, Oct 18, 2013 at 10:01 AM, Mike Lothian m...@fireburn.co.uk wrote: It seems a bit silly to skip version 10 entirely Is this really necessary? On 18 Oct 2013 07:57, Kenneth Graunke kenn...@whitecape.org wrote: Mesa now supports OpenGL 3.3 and GLSL 3.30, so bump the Mesa major version from 10 to 11 to reflect this. Also update the release notes, and add appropriate FAQ entries. http://en.wikipedia.org/wiki/Up_to_eleven Signed-off-by: Kenneth Graunke kenn...@whitecape.org Reviewed-by: Matt Turner matts...@gmail.com --- VERSION | 2 +- docs/relnotes.html | 3 +- docs/relnotes/10.0.html | 65 docs/relnotes/11.0.html | 80 + 4 files changed, 83 insertions(+), 67 deletions(-) delete mode 100644 docs/relnotes/10.0.html create mode 100644 docs/relnotes/11.0.html diff --git a/VERSION b/VERSION index 8e92e83..2b1181d 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -10.0.0-devel +11.0.0-devel diff --git a/docs/relnotes.html b/docs/relnotes.html index 82072dd..fb31555 100644 --- a/docs/relnotes.html +++ b/docs/relnotes.html @@ -21,7 +21,8 @@ The release notes summarize what's new or changed in each Mesa release. /p ul -lia href=relnotes/10.0.html10.0 release notes/a +lia href=relnotes/11.0.html11.0 release notes/a +liMesa 10.0 was never released. lia href=relnotes/9.2.1.html9.2.1 release notes/a lia href=relnotes/9.2.html9.2 release notes/a lia href=relnotes/9.1.7.html9.1.7 release notes/a diff --git a/docs/relnotes/10.0.html b/docs/relnotes/10.0.html deleted file mode 100644 index 0b25f49..000 --- a/docs/relnotes/10.0.html +++ /dev/null @@ -1,65 +0,0 @@ -!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; -html lang=en -head - meta http-equiv=content-type content=text/html; charset=utf-8 - titleMesa Release Notes/title - link rel=stylesheet type=text/css href=../mesa.css -/head -body - -div class=header - h1The Mesa 3D Graphics Library/h1 -/div - -iframe src=../contents.html/iframe -div class=content - -h1Mesa 10.0 Release Notes / TBD/h1 - -p -Mesa 10.0 is a new development release. -People who are concerned with stability and reliability should stick -with a previous release or wait for Mesa 10.0.1. -/p -p -Mesa 10.0 implements the OpenGL 3.3 API, but the version reported by -glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) / -glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used. -Some drivers don't support all the features required in OpenGL 3.3. OpenGL -3.3 is strongonly/strong available if requested at context creation -because compatibility contexts are not supported. -/p - - -h2MD5 checksums/h2 -pre -TBD. -/pre - - -h2New features/h2 - -p -Note: some of the new features are only available with certain drivers. -/p - -ul -liGL_AMD_seamless_cubemap_per_texture on i965./li -liGL_ARB_conservative_depth on i965./li -liGL_ARB_texture_gather on i965./li -liGL_ARB_texture_query_levels on i965./li -liGL_KHR_debug/li -/ul - - -h2Bug fixes/h2 - -TBD. - -h2Changes/h2 - -TBD. - -/div -/body -/html diff --git a/docs/relnotes/11.0.html b/docs/relnotes/11.0.html new file mode 100644 index 000..2fb8135 --- /dev/null +++ b/docs/relnotes/11.0.html @@ -0,0 +1,80 @@ +!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; +html lang=en +head + meta http-equiv=content-type content=text/html; charset=utf-8 + titleMesa Release Notes/title + link rel=stylesheet type=text/css href=../mesa.css +/head +body + +div class=header + h1The Mesa 3D Graphics Library/h1 +/div + +iframe src=../contents.html/iframe +div class=content + +h1Mesa 11.0 Release Notes / TBD/h1 + +p +Mesa 11.0 is a new development release. +People who are concerned with stability and reliability should stick +with a previous release or wait for Mesa 11.0.1. +/p + +p +Mesa 11.0 implements the OpenGL 3.3 API, but the version reported by +glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) / +glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used. +Some drivers don't support all the features required in OpenGL 3.3. OpenGL +3.3 is strongonly/strong available if requested at context creation +because compatibility contexts are not supported. +/p + +h2FAQ/h2 + +bQ:/b What happened to Mesa 10.0? +p + bA:/b The Mesa community increases the major version number each time + the project gains support for a new version of desktop OpenGL. Mesa 9.2 + supported OpenGL 3.1. When it gained support for OpenGL 3.2, it became + Mesa 10.0. But before Mesa 10.0 was ever released, the
Re: [Mesa-dev] Introducing Virgil - 3D virtual GPU for qemu
Dave, what is your motivation to use OpenGL renderer/translator, and not native Gallium3D interface? Yes, I know about the blobs performance/features, but wasn't the idea to push even harder, so everyone uses FOSS drivers? I have always asked myself, Why the heck virual 3D is so hard to do? Couldn't TGSI steam generated from guest Mesa3D just gets passed down to host Gallium3D provider(Mesa3D again), and then pushed to pipe drivers? On Tue, Jul 23, 2013 at 4:11 PM, Michael Thayer michael.tha...@oracle.comwrote: Hello David, On 18/07/13 08:48, Dave Airlie wrote: since I suppose these communities would be most interested in this and might not all read my blog or G+ stream, Virgil is a research project I've been working on at Red Hat for a few months now and I think is ready for at least announcing upstream and seeing if there is any developer interest in the community in trying to help out. [...] If you are a developer interested in working on an open source virtual 3D GPU, or you work for a company who is interested in developing something in this area, then get in touch with me, but if you just want to kick the tyres, I don't have time for this yet. Sorry I didn't get round to answering earlier. I have taken a look at your code (the Mesa part), and on the whole it looks like something we could make good use of too, except that we would want to be producing a stream of something closer to OpenGL which we could send over our existing proxying mechanisms. Since you put the client and server code conveniently close to each other in your clone of the Mesa repository, my idea would be to add an build-time option to do this by pulling the server-side code into the Gallium driver too - is that something you could live with if I wrote code for it? My tendency is to output a white-listed subset of OpenGL as a text stream which a custom winsys back-end could send into a DRM driver. Regarding your comments on the safety of passing OpenGL through, isn't a major part of the risk in the shader code anyway, which we can't really not pass through either way? I would probably not be able to get on to writing the code I mentioned above immediately either, as this will not make sense without a proper DRM driver which we currently don't have, and which would be my first target. Since this is my first proper visit to that part of the kernel code I will probably take a little bit more time for it that you would. Regards, Michael -- ORACLE Deutschland B.V. Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.thayer@oracle.**commichael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher __**_ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/**mailman/listinfo/mesa-devhttp://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] SIGFPE in libdrm_radeon on evergreen
0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, surf=0x88d848, level=0x88dea8, bpe=1, tile_split=0, offset=65536, start_level=0) It looks like division by 0. tile_split=0 from the call site. On Mon, May 20, 2013 at 4:11 AM, Vadim Girlin vadimgir...@gmail.com wrote: Reduced test app attached and below is gdb backtrace. I suspect something is not initialized properly but I'm not very familiar with this code. Vadim Program received signal SIGFPE, Arithmetic exception. 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, surf=0x88d848, level=0x88dea8, bpe=1, tile_split=0, offset=65536, start_level=0) at radeon_surface.c:651 651 slice_pt = tileb / tile_split; #0 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, surf=0x88d848, level=0x88dea8, bpe=1, tile_split=0, offset=65536, start_level=0) at radeon_surface.c:651 #1 0x76905eea in eg_surface_init_2d_miptrees (surf_man=0x633ea0, surf=0x88d848) at radeon_surface.c:807 #2 0x76906062 in eg_surface_init (surf_man=0x633ea0, surf=0x88d848) at radeon_surface.c:863 #3 0x76907fe6 in radeon_surface_init (surf_man=0x633ea0, surf=0x88d848) at radeon_surface.c:1901 #4 0x7713260b in radeon_drm_winsys_surface_init (rws=0x6339a0, surf=0x88d848) at radeon_drm_winsys.c:477 #5 0x770a3e1c in r600_setup_surface (screen=0x6340d0, rtex=0x88d760, pitch_in_bytes_override=0) at r600_texture.c:203 #6 0x770a4774 in r600_texture_create_object (screen=0x6340d0, base=0x7fffd6d0, pitch_in_bytes_override=0, buf=0x0, surface=0x7fffc8e0) at r600_texture.c:432 #7 0x770a5268 in r600_texture_create (screen=0x6340d0, templ=0x7fffd6d0) at r600_texture.c:607 #8 0x7708a5bd in r600_resource_create (screen=0x6340d0, templ=0x7fffd6d0) at r600_resource.c:38 #9 0x77125579 in dri2_drawable_process_buffers (drawable=0x88af80, buffers=0x88aea0, buffer_count=1, atts=0x88b628, att_count=2) at dri2.c:283 #10 0x7712590a in dri2_allocate_textures (drawable=0x88af80, statts=0x88b628, statts_count=2) at dri2.c:404 #11 0x77123e6a in dri_st_framebuffer_validate (stfbi=0x88af80, statts=0x88b628, count=2, out=0x7fffd840) at dri_drawable.c:81 #12 0x76e461c1 in st_framebuffer_validate (stfb=0x88b1e0, st=0x883870) at ../../src/mesa/state_tracker/**st_manager.c:193 #13 0x76e472a8 in st_api_make_current (stapi=0x7761b9e0 st_gl_api, stctxi=0x883870, stdrawi=0x88af80, streadi=0x88af80) at ../../src/mesa/state_tracker/**st_manager.c:721 #14 0x77122ce8 in dri_make_current (cPriv=0x7fdb70, driDrawPriv=0x88af40, driReadPriv=0x88af40) at dri_context.c:255 #15 0x76c6ba1f in driBindContext (pcp=0x7fdb70, pdp=0x88af40, prp=0x88af40) at ../../../../src/mesa/drivers/**dri/common/dri_util.c:382 #16 0x77dc57e3 in dri2_bind_context (context=0x7fd9d0, old=0x616650, draw=67108873, read=67108873) at dri2_glx.c:172 #17 0x77d8c253 in MakeContextCurrent (dpy=0x602040, draw=67108873, read=67108873, gc_user=0x7fd9d0) at glxcurrent.c:269 #18 0x00384e82713c in fgOpenWindow () from /lib64/libglut.so.3 #19 0x00384e825afa in fgCreateWindow () from /lib64/libglut.so.3 #20 0x00384e825b95 in fgCreateMenu () from /lib64/libglut.so.3 #21 0x00384e823cd3 in glutCreateMenu () from /lib64/libglut.so.3 #22 0x00400816 in main (argc=1, argv=0x7fffdf18) at test.c:17 ___ 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] r600g missing Bump mapping
Hi there, I just fired Doom3 on 64 -bit Arch Linux (no 32 libs involved), to test r600g progress. Game runs fine, but I can't see bump mapping effects as on Catalyst under windows. They are enabled in the options. Does Mesa/r600g support bumps? AMD E-350 here. Evergreen class GPU. OpenGL renderer string: Gallium 0.4 on AMD PALM OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.1.2 OpenGL core profile shading language version string: 1.40 Linux localhost 3.8.11-1-ARCH #1 SMP PREEMPT Wed May 1 20:18:57 CEST 2013 x86_64 GNU/Linux ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g missing Bump mapping
Hmm, Vadim... it works indeed. I can't push up to Ultra, but I see the difference as on your screenshots. Interestingly when I play it on win with catalyst, everything is WOW, on r600g is Meh... Unfortunately I erased windows, so I can't supply screenshot, but subjectively it was way more beautiful on the same graphics level. On Thu, May 9, 2013 at 4:15 AM, Vadim Girlin vadimgir...@gmail.com wrote: On 05/09/2013 02:42 AM, Dragomir Ivanov wrote: Hi there, I just fired Doom3 on 64 -bit Arch Linux (no 32 libs involved), to test r600g progress. Game runs fine, but I can't see bump mapping effects as on Catalyst under windows. They are enabled in the options. Does Mesa/r600g support bumps? AMD E-350 here. Evergreen class GPU. Here are two screenshots made with git mesa on evergreen with Ultra settings, the only difference is toggled bump mapping option: http://i.imgur.com/Cl0hamf.jpg http://i.imgur.com/4IsjrR3.jpg To me it looks like bump mapping works. Could you provide more detailed info (with screenshots etc) to demonstrate your issue? Also you might want to try resetting game options to default to make sure that you don't have any nonstandard tweaks. Vadim OpenGL renderer string: Gallium 0.4 on AMD PALM OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.1.2 OpenGL core profile shading language version string: 1.40 Linux localhost 3.8.11-1-ARCH #1 SMP PREEMPT Wed May 1 20:18:57 CEST 2013 x86_64 GNU/Linux __**_ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/**mailman/listinfo/mesa-devhttp://lists.freedesktop.org/mailman/listinfo/mesa-dev __**_ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/**mailman/listinfo/mesa-devhttp://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] GLSL compiler bug
Probably, the optimizer sees that there is second assignment, and skips the
first, f=1.0. It never gets to second though.
On Wed, Apr 10, 2013 at 11:08 PM, Ian Romanick i...@freedesktop.org wrote:
On 04/10/2013 12:20 PM, Vadim Girlin wrote:
Hi,
It seems there is a bug in the compiler. The problem may be reproduced
with the following shader (complete shader_test file attached):
void main()
{
float f = 0.0;
while (true) {
f = 1.0;
break;
f = 0.5;
}
gl_FragColor = vec4(1.0 - f, f, 0.0, 1.0);
}
The result of compilation is equal to:
while (true) {
break;
}
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
In other words, GLSL compiler eliminates both assignments to f in the
loop body and the resulting value of the f variable is 0.
Blarg. I can believe it. The loop analysis code is a disaster. Part of
the reason I'm (slowly) making changes to the IR is so that we can do more
credible loop handling.
I probably won't be able to get to this problem for quite some time. :(
Vadim
__**_
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/**mailman/listinfo/mesa-devhttp://lists.freedesktop.org/mailman/listinfo/mesa-dev
__**_
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/**mailman/listinfo/mesa-devhttp://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] ACTIVE_UNIFORM_MAX_LENGTH should include 3 extra characters for arrays.
I don't know OpenGL very much, but can uniforms be more than 10? So you can
have [24] where you will need +4, not +3.
On Sat, Mar 30, 2013 at 3:22 AM, Haixia Shi h...@chromium.org wrote:
If the active uniform is an array, then the length of the uniform name
should
include the three extra characters for the [0] suffix, which is required
by
the GL 4.2 spec to be appended to the uniform name in glGetActiveUniform().
This avoids the situation where the output buffer does not have enough
space
to hold the [0] suffix, resulting in an incomplete array specification
like
foobar[0.
Change-Id: Icd58cd6a73c9de7bbe5659d757b8009021846019
Signed-off-by: Haixia Shi h...@chromium.org
Reviewed-by: Stéphane Marchesin marc...@chromium.org
---
src/mesa/main/shaderapi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index be69467..68767f4 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -519,8 +519,11 @@ get_programiv(struct gl_context *ctx, GLuint
program, GLenum pname, GLint *param
for (i = 0; i shProg-NumUserUniformStorage; i++) {
/* Add one for the terminating NUL character.
+ * However if the uniform is an array, then add three extra
characters
+ * for the appended [0] suffix, in addition to the terminating
NUL.
*/
-const GLint len = strlen(shProg-UniformStorage[i].name) + 1;
+const GLint len = strlen(shProg-UniformStorage[i].name) + 1 +
+((shProg-UniformStorage[i].array_elements != 0) ? 3 : 0);
if (len max_len)
max_len = len;
--
1.8.1.3
___
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] r600g: status of my work on the shader optimization
Well, the branch was said to work with EG. For HD4000, probably further work is needed. On Mon, Feb 18, 2013 at 12:20 PM, Andy Furniss andy...@ukfsn.org wrote: Stefan Seifert wrote: Hi! Amazing work! I see some 50 % speed ups in FlightGear and even more. While normally 3D clouds tear performance down to an unflyable stutter, with your branch I can fly in densly clouded conditions at usable framerates. I can now turn all shaders to maximum and enjoy the view. This makes a huge difference. Unfortunately there's a downside as well: Testing with rv790 with drm-fixes kernel not much works - etqw runs but in a level 50% of screen is junk. nexuiz menus total junk, didn't test further. xonotic menus OK but gpu lock on starting timedemo. vdpau mpeg2 decode - renders 90% junk. heaven 3.0 (on a different pure 64 bit setup) gpu lock. Unrelated question wtr heaven 3.0 - does it work properly anyway? For me running 64bit on rv790 with vanilla mesa with or without llvm I have to set shaders to medium, on high it works but I get no lighting/effects. There are also a couple of scenes that render as flared out black and white. __**_ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/**mailman/listinfo/mesa-devhttp://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] r600g: status of my work on the shader optimization
Just wow! It would be crime not to merge this branch, with the sole reason LLVM is the future. Fantastic work Vadim. On Fri, Feb 15, 2013 at 1:00 PM, Vadim Girlin vadimgir...@gmail.com wrote: On 02/14/2013 02:42 PM, Christian König wrote: Hi Vadim, nice work, I think you've made quite a progress here, but on the other hand it should be clear that the LLVM backend is the future and we should concentrate on that. LLVM backend is the future is a pretty abstract argument. I prefer to operate with real facts. After a year of LLVM backend development what are the real benefits for the users? What are the real use cases where the users might prefer LLVM backend? To me this situation looks like the use of LLVM requires a lot more time and development efforts than the custom solution, despite the initial expectations. Maybe you are right and the LLVM backend will become the best alternative for users sometime in the future, but I only have some today's results: Heaven 3.0, all settings high/enabled, 1280x720, HD5750: default backend : 20.0 fps llvm backend: 18.8 fps r600-sb : 38.0 fps When I'm looking at these results, the benefits of LLVM-based solution are not very clear to me. I'm not trying to persuade anyone, just wanted to explain why I decided to switch back to work on the non-LLVM solution. Anyway, it's absolutely not a problem for me if this branch will never make it to mesa, I was ready to this before I started. One of the goals of this branch was just to show that the use of LLVM is possibly not the the best way of the GL shaders compilation for r600g. And another goal, of course, is to get better performance with r600g *today*, not in the future. Vadim To sum it up I'm not sure what we should do with this branch :) As Dragomir already wrote even if the code won't be used much the know-how you gained while coding it will stay, believe me that this is or far more value than the code itself. Christian. Am 14.02.2013 11:10, schrieb Dragomir Ivanov: Greetings, I hope that, even if you work will be short-lived, e.g. until LLVM bytecode compiler takes off, the know-how is still very useful. On Thu, Feb 14, 2013 at 4:04 AM, Vadim Girlin vadimgir...@gmail.com mailto:vadimgir...@gmail.com** wrote: Hi, Last month I finally found the time to work on the rewrite of my previous shader optimization branch, now it's mostly done in terms of the correctness of produced code and feature support (at least on evergreen), though it's still a work in progress in terms of the efficiency of generated shader code and the efficiency of the backend itself. I spent some time last year studying the LLVM infrastructure and R600 LLVM backend and trying to improve it, but after all I came to the conclusion that for me it might be easier to implement all that I wanted in the custom backend. This allows for more simple and efficient implementation - e.g. I don't have to deal with CFGs because in fact we have structured code, so it's possible to use more simple and efficient algorithms. Currently the branch has no regressions with piglit's quick-driver.tests on evergreen (it doesn't rely on the fallback to unoptimized code for the shaders with relative addressing and other cases unlike the previous branch), and so far I don't see any rendering issues with the apps that I used for testing - Lightsmark 2008, Unigine Heaven 3.0 and some others.. There are also some performance improvements with the gpu-bound apps. I tried to keep in mind the differences between chip classes, so I hope it should only require minor fixes to make it work on non-evergreen chips, but I doubt that it will work out of the box - support for some non-evergreen hw-specific features is still missing, e.g. I'm sure that indirect addressing currently won't work on R6xx, though basic tests might work in theory. Fixing this shouldn't require a lot of work though. The branch can be found in my freedesktop repo: http://cgit.freedesktop.org/~**vadimg/mesa/log/?h=r600-sbhttp://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-sb http://cgit.freedesktop.org/%**7Evadimg/mesa/log/?h=r600-sbhttp://cgit.freedesktop.org/%7Evadimg/mesa/log/?h=r600-sb Regarding the differences from the previous branch - there are some additional optimizations, e.g. global value numbering with some basic support for constant folding (not all instructions are currently handled, but it's easy to extend), global code motion that can hoist invariant code out of the loops etc. Some optimizations that were implemented in the previous branch are not implemented in the new branch (yet), e.g. propagation of modifiers (I'm not even sure if it has any noticeable effect on performance). Unlike the previous branch
[Mesa-dev] LLVM backend
Two patches. One replacing dynamic_casts where their result value is not checked against NULL pointer, so they can be made safely static_casts. Other, defining llvm.AMDGPU.kill instrinsic for R600 class hardware. This enables using discard keyword in GLSL. 0001-Since-result-of-dynamic_cast-is-not-checked-it-can-b.patch Description: Binary data 0001-Add-llvm.AMDGPU.kill-intrinsic-definition-for-R600-c.patch Description: Binary data ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
