On 11/15/2011 07:11 AM, Vadim Girlin wrote:
On Tue, 2011-11-15 at 06:48 -0800, Jose Fonseca wrote:
- Original Message -
On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
- Original Message -
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM, Va
On 11/15/2011 04:11 PM, Vadim Girlin wrote:
> On Tue, 2011-11-15 at 06:48 -0800, Jose Fonseca wrote:
>>
>> - Original Message -
>>> On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
- Original Message -
> On 11/14/2011 07:16 AM, Marek Olšák wrote:
>> On Mon, N
On Tue, Nov 15, 2011 at 9:27 AM, Ian Romanick wrote:
>
> I guess I don't follow. Different hardware can do different things, and the
> code for that hardware will look different. What's the problem?
Well, I guess you're right. We already make the GLSL compiler do
different things based on CAPs.
On Tue, 2011-11-15 at 06:48 -0800, Jose Fonseca wrote:
>
> - Original Message -
> > On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
> > >
> > > - Original Message -
> > > > On 11/14/2011 07:16 AM, Marek Olšák wrote:
> > > > > On Mon, Nov 14, 2011 at 2:49 PM, Vadim
> > > > >
- Original Message -
> On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
> >
> > - Original Message -
> > > On 11/14/2011 07:16 AM, Marek Olšák wrote:
> > > > On Mon, Nov 14, 2011 at 2:49 PM, Vadim
> > > > Girlin wrote:
> > > >> On Mon, 2011-11-14 at 05:22 -0800, Jose Fonse
On Tue, Nov 15, 2011 at 9:43 AM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca
>> wrote:
>> >
>> >
>> > - Original Message -
>> >> On 11/13/2011 03:06 AM, Vadim Girlin wrote:
>> >> > Hi,
>> >> >
>> >> > I found some problem with gl
- Original Message -
> On Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca
> wrote:
> >
> >
> > - Original Message -
> >> On 11/13/2011 03:06 AM, Vadim Girlin wrote:
> >> > Hi,
> >> >
> >> > I found some problem with glsl_to_tgsi: remove_output_reads
> >> > function.
> >> > It's replac
On 15 November 2011 14:52, Jose Fonseca wrote:
> Developer time is important too. And having more code paths shared with other
> drivers (even at the expense of a few extra CPU cycles every time a shader is
> created) means that developers has more time to focus on features that can
> yield sub
On Tue, 2011-11-15 at 05:52 -0800, Jose Fonseca wrote:
>
> - Original Message -
> > On 11/14/2011 07:16 AM, Marek Olšák wrote:
> > > On Mon, Nov 14, 2011 at 2:49 PM, Vadim
> > > Girlin wrote:
> > >> On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote:
> > >>>
> > >>> - Original Mess
On Tue, Nov 15, 2011 at 8:58 AM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On 11/13/2011 03:06 AM, Vadim Girlin wrote:
>> > Hi,
>> >
>> > I found some problem with glsl_to_tgsi: remove_output_reads
>> > function.
>> > It's replacing outputs with temps, producing incorrect results w
- Original Message -
> On 11/13/2011 03:06 AM, Vadim Girlin wrote:
> > Hi,
> >
> > I found some problem with glsl_to_tgsi: remove_output_reads
> > function.
> > It's replacing outputs with temps, producing incorrect results with
> > relative addressing. You can see it e.g. with
> > "vs-va
- Original Message -
> On 11/14/2011 07:16 AM, Marek Olšák wrote:
> > On Mon, Nov 14, 2011 at 2:49 PM, Vadim
> > Girlin wrote:
> >> On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote:
> >>>
> >>> - Original Message -
> Hi,
>
> I found some problem with glsl_to_t
On 11/14/2011 07:16 AM, Marek Olšák wrote:
On Mon, Nov 14, 2011 at 2:49 PM, Vadim Girlin wrote:
On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote:
- Original Message -
Hi,
I found some problem with glsl_to_tgsi: remove_output_reads function.
It's replacing outputs with temps, pr
On 11/13/2011 03:06 AM, Vadim Girlin wrote:
Hi,
I found some problem with glsl_to_tgsi: remove_output_reads function.
It's replacing outputs with temps, producing incorrect results with
relative addressing. You can see it e.g. with
"vs-varying-array-mat2-col-rd.shader_test". Here is a dump:
VE
On 14 November 2011 17:29, Christoph Bumiller
wrote:
> And r600, I think, just stores them all in TEMP space and exports them
> in the end, so it's rather a property of the shader backend that the
> device (I may be wrong though).
>
Instructions generally all work on GPRs (and a couple of special
On 11/14/2011 03:14 PM, Henri Verbeet wrote:
> On 14 November 2011 14:49, Vadim Girlin wrote:
>> By the way, which drivers do not support reading outputs? I haven't done
>> a full piglit run with llvmpipe, but IIRR the single test mentioned
>> above was also fixed for llvmpipe without this output
On Mon, Nov 14, 2011 at 2:49 PM, Vadim Girlin wrote:
> On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote:
>>
>> - Original Message -
>> > Hi,
>> >
>> > I found some problem with glsl_to_tgsi: remove_output_reads function.
>> > It's replacing outputs with temps, producing incorrect resu
On 14 November 2011 14:49, Vadim Girlin wrote:
> By the way, which drivers do not support reading outputs? I haven't done
> a full piglit run with llvmpipe, but IIRR the single test mentioned
> above was also fixed for llvmpipe without this output replacement.
>
IIRC both GLSL IR and Mesa IR took
On Mon, 2011-11-14 at 05:22 -0800, Jose Fonseca wrote:
>
> - Original Message -
> > Hi,
> >
> > I found some problem with glsl_to_tgsi: remove_output_reads function.
> > It's replacing outputs with temps, producing incorrect results with
> > relative addressing. You can see it e.g. with
>
- Original Message -
> Hi,
>
> I found some problem with glsl_to_tgsi: remove_output_reads function.
> It's replacing outputs with temps, producing incorrect results with
> relative addressing. You can see it e.g. with
> "vs-varying-array-mat2-col-rd.shader_test". Here is a dump:
>
> >
Hi,
I found some problem with glsl_to_tgsi: remove_output_reads function.
It's replacing outputs with temps, producing incorrect results with
relative addressing. You can see it e.g. with
"vs-varying-array-mat2-col-rd.shader_test". Here is a dump:
> VERT
> DCL IN[0]
> DCL OUT[0], POSITION
> DCL O
21 matches
Mail list logo
