Re: [Mesa-dev] r600g plans
On 07/24/2010 11:36 AM, Tom Stellard wrote: On Fri, Jul 23, 2010 at 08:09:46PM -0400, Jerome Glisse wrote: On 07/23/2010 07:11 PM, Corbin Simpson wrote: On Fri, Jul 23, 2010 at 3:49 PM, Jerome Glissegli...@freedesktop.org wrote: Just heads up on r600g plan, i removed the compiler stuff it was getting messy and kind of stopped anyone else from working on other part of r600g. So now there is a very simple dumb tgsi - r600 assembler that does work and can run glxgears and couple others non textured demos. I want to freeze r600_asm* stuff as i plan to reuse at latter point with a proper optimizer (thought there is a couple of thing missing in it like splitting alu node when reaching the 256dwords limit). So now if you want to add opcode the only file you need to touch is r600_shader.c. Also i would like to avoid any kind of work on optimizing what it spit. I am going to add texture support over the next few days (target being tri-tex, multiarb, tunnel, tunnel2 at that point i think quake engine should run). Todo list (kind of sorted): - texture support - use const buffer rather than cfile - avoid recompiling the shader at each draw command (would improve speed a lot) - stencil support - support more states (blending, alpha, rasterization, ...) - geometry shader - tiling support - color mask support - hyperz - a proper compiler Feel free to pick something and have fun. You're awesome as usual. Can we talk about maybe some common optimizations to r300g and r600g (and maybe others) that can be done in TGSI? Code sharing is fun, and I *really* don't want to see features fall by the wayside just because the shader compiler needs work. ~ C. When i first looked at optimization i looked at r300 compiler, but thing is i want to try a different approach that would be very hard to apply to r300-r500 hw. Basic idea is to do all optimization as scalar, and repack the instruction after. The repacking is more or less easy on r6xx and after but it's really tricky on r3xx-r5xx. Two Questions: 1. You mentioned in another mail message that you have started working on a r600g compiler. Is this working being done in its own branch somewhere? I will push to my own repo as a glsl branch, i will use the work from intel as fronted and also because it allow to test the compiler without backend which is nice. 2. Have you considered using SSA form once you've converted everything to scalar? -Tom Yes it's SSA straight from the ground. I will write down the layout of the compiler as time permit. The tricky part is register + instruction packing that somethings that was never done (at least in open academic work) i have been banging my head on this and thought about abusing some of the register allocation, state of the art, algorithm in weird way Note that we don't need registers allocation as if a program need more register than hw provide it's good to consider the shader as non runable. There are also few challenges that i don't want to address now, like breaking dot product or other similar things. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g LIT support
On 07/24/2010 09:46 AM, Stephan Schmid wrote: Hello, i've created a patch that implements the LIT instuction in r600g Cheers, Stephan Schmid Avoid the // for comment otherwise looks good will test on monday. Please resend using git format-patch and make sure you use proper GIT AUTHOR, COMMIT env variable so patch is properly attributed to you. Thanks, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] opencl (clover) patches question
Hi, I have been looking into what would be needed to modify in clang to support opencl recently, although there is an opencl flag to set in the lang options, it doesn't really seem to do much, so the modifications seem non-trivial (to me at least). I am wondering if this would be useful to continue, and if the changes required would invalidate this work. I also have a patch that gets the clover compiler class working with the api changes in clang. Without the opencl specific modifications, it has effectively turned it into a simplistic c99 compiler, return llvm bytecode. I also have started on some work to get a simple cpu implementation, based on the llvm execution engine, working, though this probably will take a back seat until the compiler is at least half-way correct. Also, am I correct in assuming that the general flow goes: openCL code - clang - llvm bytecode - TGSI - gallium driver? Thanks, Jonathan Hamilton On 07/23/10 15:39, Zack Rusin wrote: On Thursday 22 July 2010 20:33:59 Anthony Waters wrote: sounds good, the patches in http://www.mail-archive.com/mesa3d-...@lists.sourceforge.net/msg10561.html don't produce any conflicts with the commit from 3/28, they applied cleanly into my working copy with a 3 way merge through git am -3 not sure if this is a concern or not, but after the 3 way merge the commit log is not in chronological order anymore That doesn't really matter. Just so that I know do you actually have a plan or are you just playing around? I'm asking because the reason the Clover repository is waiting is because the entire codebase will depend on the infrastructure for GPGPU in Gallium, Clang integration and LLVM code-gen code. In the gallium resources branch I've the first crucial part of the changes in Gallium which is support for buffer reads and gather instructions. Then we'll need to implement scatter and memory spaces. TBH anything short of that Gallium/Clang/LLVM infrastructure work is at this point not very useful because it will just be rewritten later. Actually from the simpler stuff maybe cleaning up the build system or changing the testing framework to QtTest would be useful for later. I wouldn't spend any time on anything but that at this point. z ___ 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] opencl (clover) patches question
On Friday 30 July 2010 14:13:06 Jorge Villaseñor wrote: Is there some public roadmap to get this working? somewhere we can start hacking? As Anthony I'm a newcomer and I'm looking for getting OpenCL/clover up. Not right now, I'll try to start something on the fdo wiki within the next few days. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] opencl (clover) patches question
On Monday 26 July 2010 03:48:31 Jonathan Hamilton wrote: Hi, I have been looking into what would be needed to modify in clang to support opencl recently, although there is an opencl flag to set in the lang options, it doesn't really seem to do much, so the modifications seem non-trivial (to me at least). I think you're over-thinking it. I guess what you're referring is support for things like floatX (e.g. float4), __local and so on, but those aren't part of the language itself, they're actually simple defines. So what we need is a private header which defines the OpenCL C types and attributes. E.g. typedef __attribute__(( ext_vertex_type(4) )) float float4; typedef __attribute__(( ext_vertex_type(2) )) float float2; and so on. Each compiled OpenCL kernel would implicitly include this header. We'll need pretty much the same thing for builtins (but along with actual definitions of those). Also, am I correct in assuming that the general flow goes: openCL code - clang - llvm bytecode - TGSI - gallium driver? That's exactly right. z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29344] New: Long urls in chromium causes X to close when I use compositing window manager.
https://bugs.freedesktop.org/show_bug.cgi?id=29344 Summary: Long urls in chromium causes X to close when I use compositing window manager. Product: Mesa Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: GLX AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: b...@hackerdom.ru I file this bug in chromium bugzilla. http://code.google.com/p/chromium/issues/detail?id=50881can=5colspec=ID%20Stars%20Pri%20Area%20Feature%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS In short: when I open long URL in chromium the X server hangs. I have mesa 7.8.2 installed and intel drivers for videocard. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x495c20] 1: /usr/bin/X (0x40+0x5d606) [0x45d606] 2: /lib/libpthread.so.0 (0x7f2d9766b000+0xf110) [0x7f2d9767a110] 3: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f2d95495000+0x384a8) [0x7f2d954cd4a8] (in dri2GetBuffersWithFormat, file glxdri2.c, in cycle) 4: /usr/lib64/dri/i965_dri.so (0x7f2d93eb4000+0x2091d) [0x7f2d93ed491d] (in intel_update_renderbuffers, file intelcontex.c, line 270) 5: /usr/lib64/dri/i965_dri.so (0x7f2d93eb4000+0x3123d) [0x7f2d93ee523d] (in intelSetTexBuffer2) 6: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f2d95495000+0x3835d) [0x7f2d954cd35d] (in glXDRIbindTexImage, file glxdri2.c) 7: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f2d95495000+0x2c44f) [0x7f2d954c144f](I don't know what this function do) 8: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f2d95495000+0x2b99b) [0x7f2d954c099b] (in glXDisp_VendorPrivate, file glxcmds.c, line 2303) 9: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f2d95495000+0x2f763) [0x7f2d954c4763] (in glXDispatch, file glxext.c, line 601) 10: /usr/bin/X (0x40+0x2e24c) [0x42e24c] 11: /usr/bin/X (0x40+0x24bfa) [0x424bfa] 12: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f2d95d45bbd] 13: /usr/bin/X (0x40+0x247d9) [0x4247d9] Segmentation fault at address (nil) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Tue, 27 Jul 2010 21:32:57 +0100, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-07-21 at 18:53 -0700, Ian Romanick wrote: As everyone knows, a group of us at Intel have been rewriting Mesa's GLSL compiler. The work started out-of-tree as a stand alone compiler. We moved all of our work to the glsl2 branch in the Mesa tree as soon as we had some actual code being generated. This was about month ago. Since that time we have implemented quite a bit more code generation and a complete linker. The compiler is not done, but it gets closer every day. I think now is the time to start discussing merge criteria. It is well known that the Intel graphics team favors quarterly releases. In order to align with other people's release schedules, we'd really like to have the new compiler in a Mesa release at the end of Q3 (end of September / beginning of October). That's just over two months from now. In order to have a credible release, the compiler needs to be merged to master before then. A reasonable estimate puts the end of August as the latest possible merge time. Given how far the compiler has come in the last month, I have a lot of faith in being able to hit that target. We have developed our own set of merge requirements, and these are listed below. Since this is such a large subsystem, we want to solicit input from the other stakeholders. * No piglit regressions, except draw_buffers-05.vert, compared to master in swrast, i965, or i915. * Any failing tests do not crash (segfault, assertion failure, etc.). draw_buffers-05.vert is specifically excluded because I'm not sure the test is correct. One of the items on the TODO list is proper support for GLSL ES. That work won't happen until the last couple weeks of August, so I don't think any sort of ES testing is suitable merge criteria. Unless, of course, the tests in question should also work on desktop GLSL. We haven't and, for all practical purposes, can't test with Gallium or other hardware drivers. The new compiler generates the same assembly IR that the current compiler generates. We haven't added any instructions. It does, however, generate different combinations of instructions, different uses of registers, and so on. We don't expect there to be significant impact on other hardware, but there may be some. The optimizer in r300 will certainly see different sequences of instructions than it is accustomed to seeing. I can't foresee what impact this will have on that driver. I have put up the results of master and the glsl2 branch at http://people.freedesktop.org/~idr/results/. This run off compiler.tests from the glsl2 branch of Eric's piglit repository. A few of the failures (half a dozen or so) on master seem to be mutex related in the GLX code. Kristian is working on fixing that. :) We're already very close to our proposed merge criteria. I was recently made aware that glsl2 adds an hard dependency on the talloc library. Is this correct? I doesn't seem that talloc has ever been ported to Windows or MSVC, although it seems small. There's also the fact that it's a dependency with a very different license from Mesa (LGPLv3). This is not an obstacle on itself, but it makes it harder to simply bundle the code into mesa and port it ourselves. At a first glance it seems that talloc gives a tad more trouble than what it's worth. Did you guys investigate other alternatives? talloc.c mentions it was inspired by http://swapped.cc/halloc/ , which is BSD license and seems trivial to port to MSVC. Would that also fit your needs? No, it's missing most of the API that talloc provides. Also, http://github.com/aras-p/glsl-optimizer/ ported it to windows. pgpzMs2WHUjxw.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] mesa: increase the relative address offset limit to 4096 in ARB_vp/fp
On Sat, 31 Jul 2010 20:32:29 +0200, Marek Olšák mar...@gmail.com wrote: Also program_parse.tab.c has been regenerated. This fixes the parser error: ARB_vp: error: relative address offset too large See also: https://bugs.freedesktop.org/show_bug.cgi?id=28628 4096 * sizeof(vec4) is the maximum size of the constant buffer on NV50, so it is a reasonable limit, at least for now. (should there be any limit at all?) Piglit: vp-arl-constant-array-huge-relative-offset The limit comes from: (26) What limits should be imposed on the constants that can be added to or subtracted from the address register for relative addressing? Negative offsets are sometimes useful for shifting down in an array. RESOLVED: -64 to +63 should be sufficient for the time being. Offset sizes are limited to allow offsets to be baked into device-dependent instruction encodings. so wine is really being nonportable here and should handle it itself, but I'm fine with just removing the limits in the core and letting the drivers complain if they can't be supported. 4096 doesn't make sense as a limit, as constant buffer size limits should already be expressed through MAX_PROGRAM_PARAMETERS_ARB. pgpQulwb3DgAT.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] mesa: increase the relative address offset limit to 4096 in ARB_vp/fp
On Sat, 2010-07-31 at 20:32 +0200, Marek Olšák wrote: Also program_parse.tab.c has been regenerated. This fixes the parser error: ARB_vp: error: relative address offset too large See also: https://bugs.freedesktop.org/show_bug.cgi?id=28628 4096 * sizeof(vec4) is the maximum size of the constant buffer on NV50, so it is a reasonable limit, at least for now. (should there be any limit at all?) Sorry about butting in, but is this the same issue that's tracked here? https://bugs.freedesktop.org/show_bug.cgi?id=23975 -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 23946] Wine GLSL support
https://bugs.freedesktop.org/show_bug.cgi?id=23946 --- Comment #14 from Vinson Lee v...@vmware.com 2010-08-01 12:54:50 PDT --- (In reply to comment #5) (In reply to comment #4) Do most other GL drivers allow a larger range of offsets? We could easily raise them in Mesa. Nvidia and fglrx do, I'm not completely sure about Apple. An offset of 64 or -65 does not compile with Apple. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: increase the relative address offset limit to 4096 in ARB_vp/fp
On Sun, Aug 1, 2010 at 7:27 PM, Eric Anholt e...@anholt.net wrote: On Sat, 31 Jul 2010 20:32:29 +0200, Marek Olšák mar...@gmail.com wrote: Also program_parse.tab.c has been regenerated. This fixes the parser error: ARB_vp: error: relative address offset too large See also: https://bugs.freedesktop.org/show_bug.cgi?id=28628 4096 * sizeof(vec4) is the maximum size of the constant buffer on NV50, so it is a reasonable limit, at least for now. (should there be any limit at all?) Piglit: vp-arl-constant-array-huge-relative-offset The limit comes from: (26) What limits should be imposed on the constants that can be added to or subtracted from the address register for relative addressing? Negative offsets are sometimes useful for shifting down in an array. RESOLVED: -64 to +63 should be sufficient for the time being. Offset sizes are limited to allow offsets to be baked into device-dependent instruction encodings. so wine is really being nonportable here and should handle it itself, but I'm fine with just removing the limits in the core and letting the drivers complain if they can't be supported. OK. The thing is proprietary drivers allow much larger offsets than -64/+63. 4096 doesn't make sense as a limit, as constant buffer size limits should already be expressed through MAX_PROGRAM_PARAMETERS_ARB. It is not supposed to be a definite hardware limit, it is just large enough for it not to get in the way. -Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 27250] glEnable(GL_VERTEX PROGRAM POINT SIZE) doesn't work
https://bugs.freedesktop.org/show_bug.cgi?id=27250 Gordon Jin gordon@intel.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Gordon Jin gordon@intel.com 2010-08-01 18:45:06 PDT --- This test case has been committed as piglit glsl-vs-point-size. And the test result has changed to pass since about one week ago. Tested with mesa master branch on Piketon (i965). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29351] New: Segfaults in glCompileShader since 566430
https://bugs.freedesktop.org/show_bug.cgi?id=29351 Summary: Segfaults in glCompileShader since 566430 Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: cedr...@neonux.com glCompileShader segfaults and/or fails to compile valid shaders with errors like gl_Position not written in vertex shader. Bisected first bad commit is 566430, which seems to be the first part of a two-part commit to fix #29305. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
