-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
> ---
> src/mesa/drivers/dri/intel/intel_buffers.c| 21 +
> src/mesa/drivers/dri/intel/intel_extensions.c |1 +
> 2 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/drivers/dri
---
src/mesa/drivers/dri/intel/intel_buffers.c| 21 +
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c
b/src/mesa/drivers/dri/intel/intel_buffers.c
index 6b1
I'd like to get it either into this release or the point release after it --
giving people the tools to use OpenGL appropriately seems important.
(idr noted that we don't need the extension enable in the driver, since it's
always there)
This replaces the st_cb_get wrapper around glGet with using the FB's fields.
---
src/mesa/sources.mak|1 -
src/mesa/state_tracker/st_cb_fbo.c | 16 ++
src/mesa/state_tracker/st_cb_get.c | 97 ---
src/mesa/state_tracker/st_cb_get.h |
The spec quite reasonably says it's dependent on the current read surface,
so it doesn't look like a Const.
---
src/mesa/main/context.c|4
src/mesa/main/framebuffer.c|5 +
src/mesa/main/get.c| 16
src/mesa/main/get_gen.py
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
> Ian Romanick wrote:
>> Ian Romanick wrote:
>>> Brian Paul wrote:
Ian Romanick wrote:
> Why is the DataType for MESA_FORMAT_Z24_S8 and related types
> GL_UNSIGNED_INT? Right now the Intel drivers manually set the
>
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ian Romanick wrote:
>> Brian Paul wrote:
>>> Ian Romanick wrote:
Why is the DataType for MESA_FORMAT_Z24_S8 and related types
GL_UNSIGNED_INT? Right now the Intel drivers manually set the
renderbuffer DataTyp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
> Brian Paul wrote:
>> Ian Romanick wrote:
>>> Why is the DataType for MESA_FORMAT_Z24_S8 and related types
>>> GL_UNSIGNED_INT? Right now the Intel drivers manually set the
>>> renderbuffer DataType for these types to GL_UNSIGNED_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
> Ian Romanick wrote:
>>
>> Why is the DataType for MESA_FORMAT_Z24_S8 and related types
>> GL_UNSIGNED_INT? Right now the Intel drivers manually set the
>> renderbuffer DataType for these types to GL_UNSIGNED_INT_24_8 for these
>> f
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Why is the DataType for MESA_FORMAT_Z24_S8 and related types
> GL_UNSIGNED_INT? Right now the Intel drivers manually set the
> renderbuffer DataType for these types to GL_UNSIGNED_INT_24_8 for these
> formats.
The renderbu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Why is the DataType for MESA_FORMAT_Z24_S8 and related types
GL_UNSIGNED_INT? Right now the Intel drivers manually set the
renderbuffer DataType for these types to GL_UNSIGNED_INT_24_8 for these
formats.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Roland Scheidegger wrote:
> Keith,
>
> I think there might be some slight issue with some of the changes in the
> drivers I did. In particular, I was under the impression it would be ok
> to do something like
> union a_union {
> int i;
> double d;
> };
> int f() {
>double d = 3.0;
>ret
On 08.12.2009 20:57, Martin Olsson wrote:
> Roland Scheidegger wrote:
>> Keith,
>>
>> I think there might be some slight issue with some of the changes in the
>> drivers I did. In particular, I was under the impression it would be ok
>> to do something like
>> union a_union {
>> int i;
>> doubl
Christoph Bumiller pisze:
> michal schrieb:
>
>> This branch simplifies pipe/p_format.h by making enum pipe_format what
>> it should have been -- an enum.
>>
>> ...
>>
>> I would like to hear from r300 and nouveau guys, as those drivers were
>> using some internal macros and I weren't 100% sur
It was TexSubImage, and i added FLUSH_CURRENT after
ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH and it seems to fix the issue. The
difference between the two is that one triggers on NeedFlush &
FLUSH_UPDATE_CURRENT and the other on NeedFlush &
FLUSH_STORED_VERTICES. Any idea what the problem is?
Maarten.
On 08.12.2009 18:12, Roland Scheidegger wrote:
> On 08.12.2009 17:37, Keith Whitwell wrote:
>> On Tue, 2009-12-08 at 08:31 -0800, Roland Scheidegger wrote:
>>> Keith,
>>>
>>> I think there might be some slight issue with some of the changes in the
>>> drivers I did. In particular, I was under the i
On 08.12.2009 17:37, Keith Whitwell wrote:
> On Tue, 2009-12-08 at 08:31 -0800, Roland Scheidegger wrote:
>> Keith,
>>
>> I think there might be some slight issue with some of the changes in the
>> drivers I did. In particular, I was under the impression it would be ok
>> to do something like
>> un
michal schrieb:
> This branch simplifies pipe/p_format.h by making enum pipe_format what
> it should have been -- an enum.
>
> ...
>
> I would like to hear from r300 and nouveau guys, as those drivers were
> using some internal macros and I weren't 100% sure I got the conversion
> right.
>
Hi
On Tue, 2009-12-08 at 08:31 -0800, Roland Scheidegger wrote:
> Keith,
>
> I think there might be some slight issue with some of the changes in the
> drivers I did. In particular, I was under the impression it would be ok
> to do something like
> union a_union {
> int i;
> double d;
> };
> int
On Tue, 2009-12-08 at 08:33 -0800, Younes Manton wrote:
> On Tue, Dec 8, 2009 at 9:55 AM, michal wrote:
> > This branch simplifies pipe/p_format.h by making enum pipe_format what
> > it should have been -- an enum.
> >
> > As a result there is no extra information encoded in it and one needs to
>
Roland,
Looks good to me too.
Jose
On Tue, 2009-12-08 at 08:19 -0800, Keith Whitwell wrote:
> Roland,
>
> This looks OK to me, hopefully this will see us getting on top of strict
> aliasing issues after all these years...
>
> Keith
>
> On Mon, 2009-12-07 at 18:14 -0800, Roland Scheidegger wr
On Tue, Dec 8, 2009 at 9:55 AM, michal wrote:
> This branch simplifies pipe/p_format.h by making enum pipe_format what
> it should have been -- an enum.
>
> As a result there is no extra information encoded in it and one needs to
> use auxiliary/util/u_format.h to get that info instead. Linking to
Keith,
I think there might be some slight issue with some of the changes in the
drivers I did. In particular, I was under the impression it would be ok
to do something like
union a_union {
int i;
double d;
};
int f() {
double d = 3.0;
return ((union a_union *) &d)->i;
};
but in fact gcc
On Tue, 2009-12-08 at 08:16 -0800, Roland Scheidegger wrote:
> On 08.12.2009 16:49, michal wrote:
> > Roland Scheidegger pisze:
> >> On 08.12.2009 15:55, michal wrote:
> >>
> >>> This branch simplifies pipe/p_format.h by making enum pipe_format what
> >>> it should have been -- an enum.
> >>>
>
Roland,
This looks OK to me, hopefully this will see us getting on top of strict
aliasing issues after all these years...
Keith
On Mon, 2009-12-07 at 18:14 -0800, Roland Scheidegger wrote:
> Hello,
>
> I'm planning to merge gallium-strict-aliasing branch soon, which will
> bring another gallium
On 08.12.2009 16:49, michal wrote:
> Roland Scheidegger pisze:
>> On 08.12.2009 15:55, michal wrote:
>>
>>> This branch simplifies pipe/p_format.h by making enum pipe_format what
>>> it should have been -- an enum.
>>>
>>> As a result there is no extra information encoded in it and one needs to
On Tue, 2009-12-08 at 07:49 -0800, michal wrote:
> Roland Scheidegger pisze:
> > On 08.12.2009 15:55, michal wrote:
> >
> >> This branch simplifies pipe/p_format.h by making enum pipe_format what
> >> it should have been -- an enum.
> >>
> >> As a result there is no extra information encoded in
Roland Scheidegger pisze:
> On 08.12.2009 15:55, michal wrote:
>
>> This branch simplifies pipe/p_format.h by making enum pipe_format what
>> it should have been -- an enum.
>>
>> As a result there is no extra information encoded in it and one needs to
>> use auxiliary/util/u_format.h to get t
On 08.12.2009 15:55, michal wrote:
> This branch simplifies pipe/p_format.h by making enum pipe_format what
> it should have been -- an enum.
>
> As a result there is no extra information encoded in it and one needs to
> use auxiliary/util/u_format.h to get that info instead. Linking to the
> a
This branch simplifies pipe/p_format.h by making enum pipe_format what
it should have been -- an enum.
As a result there is no extra information encoded in it and one needs to
use auxiliary/util/u_format.h to get that info instead. Linking to the
auxiliary/util lib is necessary.
Please review
On Fri, 2009-12-04 at 13:51 -0800, Maarten Maathuis wrote:
> I recently noticed a regression in the nv50 gallium driver, with a few
> hours of bisecting i figured out i need FLUSH_CURRENT called
> unconditionally in st_teximage_flush_before_map(). Otherwise in
> warzone2100 several small textures (
On Mon, 2009-12-07 at 05:01 -0800, Marek Olšák wrote:
> Hi,
>
> Because some hardware under some circumstances (e.g. disabled tiling)
> may not be able to use a hardware-specific clear path, it would be
> nice to let a state tracker do the clearing by drawing a
> screen-aligned quad. I am proposin
32 matches
Mail list logo
