OK, I reproduced the issue with a piglit shader_runner test. It looks
like the writes to float, vec2 or vec3 outputs is sometimes lost (but
always works for vec4).
I've posted a set of tests to the piglit list.
I'm cc'ing the mesa-dev list so hopefully one of the GLSL people can
take a look.
-Brian
On 10/22/2014 06:34 PM, Brian Paul wrote:
>
> In your vertex shader, try removing this code:
>
> if( !lightingEnabled ) {
> return;
> }
>
> It looks like the early return from main() is causing us to skip writing
> the value to the "UV" varying/output. I'll see if I can repro this with
> a small piglit test.
>
> -Brian
>
>
>
> On 10/21/2014 10:16 PM, Jason Anderssen wrote:
>> Hi Brian,
>>
>> The previous trace was my first attempt, and even though it reproduced on
>> windows, I tested it on linux, and it only gave a black screen, so here is
>> a second attempt, and I also tested it on linux as well, with identical
>> results to the windows replay using apitrace. (I might of only allowed it
>> to record a single frame, and I think this is what caused the issue.)
>>
>> Sorry for the previous trace.
>>
>> Anyhow, on a good note, it reproduces in Windows and Linux builds of mesa,
>> so I hope you can tell me what I am doing wrong.
>>
>> Thanks again for your help and patience.
>> Cheers
>> Jason
>>
>> On 22/10/2014 12:10 pm, "Jason Anderssen" <janders...@exactal.com> wrote:
>>
>>> Hi Brian,
>>>
>>> I worked out what you mean by apitrace, attached is the trace for you.
>>> Switching between Mesa3d-llvm build to the windows default opengl32.dll
>>> shows 2 different results, Mesa is completely blue, where as using the
>>> system you have green and blue strips (which is what I would expect).
>>>
>>> The version is 10.2.9
>>>
>>> I hope this helps.
>>>
>>> Cheers
>>> Jason
>>>
>>>
>>> On 22/10/2014 10:20 am, "Jason Anderssen" <janders...@exactal.com> wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> Thank you for your response.
>>>> I am kind of new to Mesa, so please forgive my ignorance:-)
>>>> Do I build it with this export (soft pipe)?
>>>>
>>>> What kind of apitrace do you mean, a trace of all the calls via codeXL ?,
>>>> or is there a special tool that Mesa dev¹s use?
>>>>
>>>> Cheers and thank you in advance.
>>>> Jason
>>>>
>>>>
>>>> On 22/10/2014 9:15 am, "Brian Paul" <bri...@vmware.com> wrote:
>>>>
>>>>> On 10/21/2014 03:28 PM, Jason Anderssen wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> In Mesa 3D (Windows software llvm) all our texture coordinates are
>>>>>> coming through as zero.
>>>>>> Our same code works fine with ATI, NVIDIA, and even Angle (which I
>>>>>> know
>>>>>> uses Direct3D under the covers, but it is an OpenGL ES compliant
>>>>>> wrapper).
>>>>>>
>>>>>> To verify this, I simply in the shader checked if the texcoord.s is >
>>>>>> 0.5 and color green, else blue, and sure enough half the image is
>>>>>> green
>>>>>> and half is blue with the other drivers, but with Mesa, it is entirely
>>>>>> blue. (entirely same program and exe, just different opengl32.dll)
>>>>>>
>>>>>> Any ideas what could be causing this?
>>>>>> Any help would be very appreciated.
>>>>>
>>>>> Can you make an apitrace of the problem? Have you tried with softpipe
>>>>> (export GALLIUM_DRIVER=softpipe)?
>>>>>
>>>>> -Brian
>>>>>
>>>>>
>>>>
>>>
>>
>> Internet Email Confidentiality Footer: This email and any files transmitted
>> with it contain privileged/confidential information intended for the
>> addressee. Neither the confidentiality of nor any privilege in the email is
>> waived, lost or destroyed by reason that it has been transmitted other than
>> to the addressee. If you are not the addressee indicated in this message (or
>> responsible for delivery of the message to such person), you may not copy or
>> deliver this message to anyone. In such case, you should destroy this
>> message, and notify us immediately.
>>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
