Re: [Mesa-dev] Bogus use of '#' in a macro definition (was: Re: Mesa (master): 29 new commits)
Thread reference: https://lists.freedesktop.org/archives/mesa-dev/2014-July/064410.html On 07/31/2014 11:01:29 PDT Carl Worth writes: > Ian Romanick writes: > > On 07/31/2014 12:14 AM, Michel Dänzer wrote: > >> > >> FYI, this change broke the game Reaction Quake, see the failure output > >> below. I don't know if this is a bug in this change or in the game, so > >> I'm reporting it here. > > Hi Michel, > > Thanks very much for reporting this failure. It's certainly an > interesting one. > > >> #define USE_DISCARD#line 0 > > > > Something is seriously wrong here. > > The above line in the shader does seem to be what is triggering the > error you noticed: > > >> 0:46(20): preprocessor error: syntax error, unexpected HASH_TOKEN, expecting NEWLINE On 07/31/2014 12:14 AM, Michel Dänzer wrote: > > attribute vec4 attr_Position; > > attribute vec3 attr_Normal; > > > > un > > form mat4 u_ModelViewProjectionMatrix; > > This also looks bogus. > > Is this a bad copy-and-paste, or ... ? It's not a bug in Mesa nor in GLSL shader, it's a bug in Reaction itself which was already broken but doing weird things silently instead of aborting. These commits do not introduced regressions on that part. If you open the binary in a text editor you can see the strings are ok: ``` 3242 #define USE_DISCARD^@^@^@^@^@attribute vec4 attr_Position; 3243 attribute vec3 attr_Normal; 3244 3245 uniform mat4 u_ModelViewProjectionMatrix; ``` same in hexdump: ``` 000de370 55 53 45 5f 44 49 53 43 41 52 44 00 00 00 00 00 |USE_DISCARD.| 000de380 61 74 74 72 69 62 75 74 65 20 76 65 63 34 20 61 |attribute vec4 a| 000de390 74 74 72 5f 50 6f 73 69 74 69 6f 6e 3b 0d 0a 61 |ttr_Position;..a| 000de3a0 74 74 72 69 62 75 74 65 20 76 65 63 33 20 61 74 |ttribute vec3 at| 000de3b0 74 72 5f 4e 6f 72 6d 61 6c 3b 0d 0a 0d 0a 75 6e |tr_Normal;un| 000de3c0 69 66 6f 72 6d 20 6d 61 74 34 20 20 20 75 5f 4d |iform mat4 u_M| 000de3d0 6f 64 65 6c 56 69 65 77 50 72 6f 6a 65 63 74 69 |odelViewProjecti| 000de3e0 6f 6e 4d 61 74 72 69 78 3b 0d 0a 76 61 72 79 69 |onMatrix;..varyi| ``` There is no `USE_DISCARD#Line0` but `USE_DISCARD\0` and no `un\nform` but `uniform` It looks like to be a bug in the code itself, some part of this shader is generated at runtime and some memory corruption occurs, so it's probably a classic string boundary issue, see this line: https://github.com/ReactionQuake3/reaction/blob/a35d0a7c9c3062466edba3e42112e76bc9bcf6dd/code/renderergl2/tr_glsl.c#L1145 It's not a bug on Mesa's side, and there is no need to handle this case, this case is Mesa parsing a corrupted file. -- Thomas Debesse ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: time for amber2 branch?
Le mer. 19 juin 2024 à 16:33, Mike Blumenkrantz a écrit : > In looking at the gallium tree, I'm wondering if it isn't time for a second > amber branch to prune some of the drivers that cause pain when doing big tree > updates It's probably fine for nv30 and r300 that are very unlikely to receive new features being implemented anyway (if I'm right all they do is OpenGL 2.1). For r600 it may be more annoying to split the tree for someone wanting to continue the rusticl implementation in order to drop clover, as this would split rusticl as well. Maybe the work-in-progress “Terakan” vulkan driver for r600 cards won't be affected because vulkan is not a gallium thing. I don't use any of the others so I have no thought about them. -- Thomas “illwieckz” Debesse
Mesa is painful to bisect, I hope this can be improved
Hi, for a long time now I wanted to make this observation in the hope it can be improved: Mesa is painfully hard to bisect because of many things. The most common thing hindering bisect tasks is the fact some options values are constantly swapped to `true` to `enabled` and things like that. Even when there are some legacy-compatibility implemented to recognize one for the other, Meson looks to only be able to process the compatibility if and only if the build folder has been entirely cleaned-up first. So bisecting requires to clean-up the build folder on almost every bisecting step, and most of the bisecting steps also require to modify the options themselves. I wonder if there are some rooms to improve the bisecting experience: - either by implementing some working method like not doing random enable/true change one by one throughout the years but focusing at porting all of them at once, - either at making Meson accept one for the other in all cases. Then comes the silent breaking of enabled features requiring another feature to be enabled too to be working again, which also prevents to bisect properly because the same configure and build commands for the same feature may or may not produce a working installation given the commit that is tested while bisecting, this has been reported there: - https://gitlab.freedesktop.org/mesa/mesa/-/issues/12024 Then comes the usual renaming things like the `swrast` gallium driver option being split into by `llvmpipe` and `softpipe`, we can't probably avoid that, and I would be happy if in the future I and others would only have to deal with that. Do you you also experience similar problems when bisecting Mesa? Do you also face similar problems but some I may have not listed ? I focus myself on OpenGL on Xorg with GLX and on OpenCL (clover/rusticl) so other people bisecting other things like GL ES, EGL, Vulkan or even some drivers I'm not testing myself that much or not at all may experience other things I'm not aware of but making bisecting uneasy as well. An example of thing I don't test that much is zink, so problems like zink not being working while being installed given which commit is built is definitely something that makes bisecting painful, but it took me months to experience this problem myself only because I don't test zink that much myself, but I guess some people experience similar problems and pain with other features or components of Mesa. More info about that zink problem can be found there, but this is just yet one example among others: - https://gitlab.freedesktop.org/mesa/mesa/-/issues/12024 While I don't bisect zink that much myself, when I had to bisect r300 to discover what Meson option I needed to make it work again, I experienced the pain of having to rewrite Meson command line options and to clean-up the build on various bisecting steps. So I expect other people to experience similar problems I'm not aware of, only because they bisect other things in Mesa I don't bisect myself. Do you have any opinion on the topic and/or ideas to make bisecting Mesa easier? -- Thomas “illwieckz” Debesse
