-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
> Ian, I'm still getting up to speed on the new compiler, but it looks
> like a full 4-element temp/const vector is allocated for each GLSL
> float. The previous compiler would try to pack four floats into a
> single vector whenever
On Tue, 31 Aug 2010 19:35:09 -0600, Brian Paul wrote:
> On 08/31/2010 02:57 PM, Ian Romanick wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
...
> > So... what are our collective criteria for a 7.9 release to happen?
>
> Ian, I'm still getting up to speed on the new compiler, but i
> I think we need to be sure we're not infringing on this patent. Until
> we know one way or the other I'd prefer that we don't merge this
> branch into master. In the mean time I'll see if I can learn more
> about the situation and find a way to proceed.
For anyone interested in determining the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbieri wrote:
>> But we've been seeing some results which point that the whole color
>> buffer swizzling idea might be overrated: it increases memory bandwidth
>> usage substantially,
>
> Why?
> It should decrease it due to a lower number of c
On Fri, Aug 27, 2010 at 6:49 AM, Luca Barbieri wrote:
> I created a new branch called "floating" which includes an apparently
> successful attempt at full support of floating-point textures and
> render targets.
[...]
I've spoken to Luca offline about this.
I'm hesitant to have this work merge
keith whitwell writes:
> On Wed, Sep 1, 2010 at 8:34 PM, tom fogal wrote:
> > Luca Barbieri writes:
> >> Note that this totally destroys the ability to use llvmpipe for
> >> high dynamic range rendering, which fundamentally depends on the
> >> ability to store unclamped and relatively high preci
On Wed, Sep 1, 2010 at 8:34 PM, tom fogal wrote:
> Luca Barbieri writes:
>> > It's an impressive amount of work you did here. I'll comment only
>> > on the llvmpipe of the changes for now.
>>
>> Thanks for your feedback!
>
> While we're on the topic: yes, this is great to see Luca. Thank you!
>
On Wed, Sep 1, 2010 at 7:54 PM, Luca Barbieri wrote:
>> It still sounds that you're referring to sampling from a texture and not
>> rendering/blending to it. Of course the are related (we only want one
>> swizzled layout at most), but the current swizzled layout was chosen to
>> make blending easy
Luca Barbieri writes:
> > It's an impressive amount of work you did here. I'll comment only
> > on the llvmpipe of the changes for now.
>
> Thanks for your feedback!
While we're on the topic: yes, this is great to see Luca. Thank you!
> > So instead of going through a lot of work to support mul
> It still sounds that you're referring to sampling from a texture and not
> rendering/blending to it. Of course the are related (we only want one
> swizzled layout at most), but the current swizzled layout was chosen to
> make blending easy; and not to make texture sampling easy.
>
> No SoA swizzl
On Wed, 2010-09-01 at 09:24 -0700, Luca Barbieri wrote:
> > It's an impressive amount of work you did here. I'll comment only on the
> > llvmpipe of the changes for now.
>
> Thanks for your feedback!
>
> > Admittedly, always using a floating point is not ideal. A better
> > solution would be to c
> Well, don't forget that you have to populate the tile from somewhere -
> so you'll hit all of the same cachelines that the non-swizzled version
> would have.
>
> We still get locality from binning, meaning that all accesses to a group
> of cachelines come in a single burst, after which they are d
On Wed, 2010-09-01 at 09:24 -0700, Luca Barbieri wrote:
> > It's an impressive amount of work you did here. I'll comment only on the
> > llvmpipe of the changes for now.
>
> Thanks for your feedback!
>
> > Admittedly, always using a floating point is not ideal. A better
> > solution would be to c
> It's an impressive amount of work you did here. I'll comment only on the
> llvmpipe of the changes for now.
Thanks for your feedback!
> Admittedly, always using a floating point is not ideal. A better
> solution would be to choose a swizzled data type (unorm8, fixed point,
> float, etc) that ma
On Fri, 2010-08-27 at 05:49 -0700, Luca Barbieri wrote:
> I created a new branch called "floating" which includes an apparently
> successful attempt at full support of floating-point textures and
> render targets.
>
> I believe it is fundamentally correct, but should be considered a
> prototype an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
> I was looking at glsl-vs-point-size in piglit today and it doesn't
> work on gallium.
>
> void main()
> {
> gl_Position = vec4(0.0, 0.0, 0.0, 1.0);
> gl_PointSize = 16.0;
> gl_FrontColor = vec4(1.0, 1.0, 1.
https://bugs.freedesktop.org/show_bug.cgi?id=29909
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29282
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29910
--- Comment #3 from Bruce Merry 2010-09-01 00:25:15 PDT ---
> Bruce, are you talking about seeing GL_ARB_shading_language_120 in the list of
extensions?
Sorry yes, that's what I meant: it's the fact that it's showing up in
GL_EXTENSIONS that is
On Wed, Sep 1, 2010 at 7:14 AM, Dave Airlie wrote:
> I was looking at glsl-vs-point-size in piglit today and it doesn't
> work on gallium.
>
> void main()
> {
> gl_Position = vec4(0.0, 0.0, 0.0, 1.0);
> gl_PointSize = 16.0;
> gl_FrontColor = vec4(1.0, 1.0, 1.0, 1.0);
> }
>
> S
20 matches
Mail list logo
