On 13 December 2012 03:44, Ian Romanick wrote:
> Patches 1 through 4 are
>
> Reviewed-by: Ian Romanick
>
> I'll try to make it through the rest tomorrow. I have skimmed them, and
> it looks mostly okay. I thing a good follow-up patch will be to pull a
> bunch of the new stuff out to a new file
Patches 1 through 4 are
Reviewed-by: Ian Romanick
I'll try to make it through the rest tomorrow. I have skimmed them, and
it looks mostly okay. I thing a good follow-up patch will be to pull a
bunch of the new stuff out to a new file link_varyings.cpp or something.
linker.cpp is getting a
On 12 December 2012 12:53, Marek Olšák wrote:
> On Wed, Dec 12, 2012 at 9:21 PM, Eric Anholt wrote:
> > Marek Olšák writes:
> >
> >> On Wed, Dec 12, 2012 at 5:06 PM, Paul Berry
> wrote:
> >>> On 11 December 2012 23:49, Aras Pranckevicius
> wrote:
> Not sure if relevant for Mesa, but e.g.
On 12 December 2012 12:44, Aras Pranckevicius wrote:
>
> Not sure if relevant for Mesa, but e.g. on PowerVR SGX it's really bad to
>>> pack two vec2 texture coordinates into a single vec4. That's because var.xy
>>> texture read can be "prefetched", whereas var.zw texture read is not
>>> prefetche
On Wed, Dec 12, 2012 at 9:21 PM, Eric Anholt wrote:
> Marek Olšák writes:
>
>> On Wed, Dec 12, 2012 at 5:06 PM, Paul Berry wrote:
>>> On 11 December 2012 23:49, Aras Pranckevicius wrote:
Not sure if relevant for Mesa, but e.g. on PowerVR SGX it's really bad to
pack two vec2 texture co
> Not sure if relevant for Mesa, but e.g. on PowerVR SGX it's really bad to
>> pack two vec2 texture coordinates into a single vec4. That's because var.xy
>> texture read can be "prefetched", whereas var.zw texture read is not
>> prefetched (essentially treated as a dependent texture read), and oft
Marek Olšák writes:
> On Wed, Dec 12, 2012 at 5:06 PM, Paul Berry wrote:
>> On 11 December 2012 23:49, Aras Pranckevicius wrote:
>>> Not sure if relevant for Mesa, but e.g. on PowerVR SGX it's really bad to
>>> pack two vec2 texture coordinates into a single vec4. That's because var.xy
>>> text
On Wed, Dec 12, 2012 at 7:51 PM, Paul Berry wrote:
> On 12 December 2012 10:21, Paul Berry wrote:
>>
>> On 12 December 2012 09:09, Marek Olšák wrote:
>>>
>>> R300 and R400 support 4 texture indirections (as defined by
>>> ARB_fragment_program). Adding ALU instructions before the first TEX
>>> in
On 12 December 2012 10:21, Paul Berry wrote:
> On 12 December 2012 09:09, Marek Olšák wrote:
>
>> R300 and R400 support 4 texture indirections (as defined by
>> ARB_fragment_program). Adding ALU instructions before the first TEX
>> instruction increases the number of texture indirections by 1, w
On 12 December 2012 09:09, Marek Olšák wrote:
> R300 and R400 support 4 texture indirections (as defined by
> ARB_fragment_program). Adding ALU instructions before the first TEX
> instruction increases the number of texture indirections by 1, which
> might make some shaders not be executable on t
On 12 December 2012 09:51, Eric Anholt wrote:
> Paul Berry writes:
>
> > On 12 December 2012 00:02, Eric Anholt wrote:
> >
> >> Paul Berry writes:
> >>
> >> > This patch series adds varying packing to Mesa, so that we can handle
> >> > varyings composed of things other than vec4's without usin
Paul Berry writes:
> On 12 December 2012 00:02, Eric Anholt wrote:
>
>> Paul Berry writes:
>>
>> > This patch series adds varying packing to Mesa, so that we can handle
>> > varyings composed of things other than vec4's without using up extra
>> > varying components.
>>
>> Results for glbenchma
On Wed, Dec 12, 2012 at 5:06 PM, Paul Berry wrote:
> On 11 December 2012 23:49, Aras Pranckevicius wrote:
>>
>>
>>> For the initial implementation I've chosen a strategy that operates
>>> exclusively at the GLSL IR level, so that it doesn't require the
>>> cooperation of the driver back-ends.
>>
On 12 December 2012 00:02, Eric Anholt wrote:
> Paul Berry writes:
>
> > This patch series adds varying packing to Mesa, so that we can handle
> > varyings composed of things other than vec4's without using up extra
> > varying components.
>
> Results for glbenchmark 2.7 at 320x240 (units of fps
On 11 December 2012 23:49, Aras Pranckevicius wrote:
>
> For the initial implementation I've chosen a strategy that operates
>> exclusively at the GLSL IR level, so that it doesn't require the
>> cooperation of the driver back-ends.
>
>
> Wouldn't this negatively affect performance of some GPUs?
On 12 December 2012 00:02, Eric Anholt wrote:
> Paul Berry writes:
>
> > This patch series adds varying packing to Mesa, so that we can handle
> > varyings composed of things other than vec4's without using up extra
> > varying components.
>
> Results for glbenchmark 2.7 at 320x240 (units of fps
Paul Berry writes:
> This patch series adds varying packing to Mesa, so that we can handle
> varyings composed of things other than vec4's without using up extra
> varying components.
Results for glbenchmark 2.7 at 320x240 (units of fps):
N Min MaxMedian
> For the initial implementation I've chosen a strategy that operates
> exclusively at the GLSL IR level, so that it doesn't require the
> cooperation of the driver back-ends.
Wouldn't this negatively affect performance of some GPUs?
Not sure if relevant for Mesa, but e.g. on PowerVR SGX it's re
This patch series adds varying packing to Mesa, so that we can handle
varyings composed of things other than vec4's without using up extra
varying components.
For the initial implementation I've chosen a strategy that operates
exclusively at the GLSL IR level, so that it doesn't require the
cooper
19 matches
Mail list logo
