On Mon, Mar 11, 2013 at 5:28 PM, Brian Paul wrote:
> On Sat, Mar 2, 2013 at 7:29 AM, Brian Paul wrote:
>> I've respun my remove-mfeatures branch as remove-mfeatures-2. It's in my
>> repo on freedesktop.org
>>
>> This removes the mfeatures.h file and the last of the #ifdef FEATURE_x
>> code
>> fr
Jon,
It looks like this commit (and the other ones in the series) aren't
present in the mesa git tree. It also looks like the last commit was
pushed twice, and is present with the hash from the second time.
Stéphane
On Tue, Mar 5, 2013 at 5:26 AM, Jon TURNEY
wrote:
> Module: Mesa
> Branch: mas
On 03/11/2013 04:11 PM, Eric Anholt wrote:
This avoids some snooping overhead between EUs processing separate shaders
(so VS versus FS).
Improves performance of a minecraft trace with shader_time by 28.9% +/-
18.3% (n=7), and performance of my old GLSL demo by 93.7% +/- 0.8% (n=4).
---
src/mes
On 03/11/2013 04:11 PM, Eric Anholt wrote:
We were sparsely using some of these message types, but I'll just fill
them all in now. It will be used for fixing shader_time on HSW.
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/drivers/dri/i965/brw_defines.h | 36 ++
On Mon, Mar 11, 2013 at 1:44 PM, Christian König
wrote:
> Hi everybody,
>
> this problem has been open for quite some time now, with a bunch of different
> opinions and sometimes even patches floating on the list.
>
> The solutions proposed or implemented so far all more or less incomplete, so
> t
On Mon, Mar 11, 2013 at 6:49 PM, Ian Romanick wrote:
> Once upon a time Matt Turner was talking about using pixman to accelerate
> operations like this in Mesa. It has a lot of highly optimized paths for
> just this sort of thing. Since it's used by other projects, it gets a lot
> more testing,
We were sparsely using some of these message types, but I'll just fill
them all in now. It will be used for fixing shader_time on HSW.
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/drivers/dri/i965/brw_defines.h | 36 +++
1 file changed, 36 insertions(+
---
src/gallium/state_trackers/osmesa/Makefile.am | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
create mode 100644 src/gallium/state_trackers/osmesa/Makefile.am
diff --git a/src/gallium/state_trackers/osmesa/Makefile.am
b/src/gallium/state_trackers/osmesa/M
---
src/gallium/state_trackers/osmesa/osmesa.c | 828
1 files changed, 828 insertions(+), 0 deletions(-)
create mode 100644 src/gallium/state_trackers/osmesa/osmesa.c
diff --git a/src/gallium/state_trackers/osmesa/osmesa.c
b/src/gallium/state_trackers/osmesa/osmesa
---
docs/osmesa.html | 65 -
1 files changed, 25 insertions(+), 40 deletions(-)
diff --git a/docs/osmesa.html b/docs/osmesa.html
index b0609cf..8487545 100644
--- a/docs/osmesa.html
+++ b/docs/osmesa.html
@@ -18,77 +18,62 @@
-Mesa's off-
---
src/gallium/targets/osmesa/Makefile.am | 91
1 files changed, 91 insertions(+), 0 deletions(-)
create mode 100644 src/gallium/targets/osmesa/Makefile.am
diff --git a/src/gallium/targets/osmesa/Makefile.am
b/src/gallium/targets/osmesa/Makefile.am
new file m
To allow rendering in 16-bit/channel RGBA buffers.
---
src/mesa/state_tracker/st_cb_fbo.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 72bc960..87c5b04 100644
--- a/src/mesa/state_tracker/s
---
configure.ac |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 3204869..c42d0b0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -805,6 +805,8 @@ fi
if test "x$enable_osmesa" = xyes; then
DRIVER_DIRS="$DRIVER_DIRS osmesa"
+
---
src/gallium/targets/osmesa/target.c | 55 +++
1 files changed, 55 insertions(+), 0 deletions(-)
create mode 100644 src/gallium/targets/osmesa/target.c
diff --git a/src/gallium/targets/osmesa/target.c
b/src/gallium/targets/osmesa/target.c
new file mode 10064
This series let us use the OSMesa interface with gallium
llvmpipe/softpipe drivers.
The OSMesa interface is pretty old and ugly but I think most OSMesa
users would rather not have to port their apps to a new interface.
When Mesa is configured with --enable-osmesa a new
lib/gallium/libOSMesa.
On Sat, Mar 2, 2013 at 7:29 AM, Brian Paul wrote:
> I've respun my remove-mfeatures branch as remove-mfeatures-2. It's
in my
> repo on freedesktop.org
>
> This removes the mfeatures.h file and the last of the #ifdef
FEATURE_x code
> from core Mesa.
>
> Note, however, that the scons/makefiles
From: Kenneth Graunke
Haswell's "Data Cache" data port is a single unit, but split into two
SFIDs to allow for more message types without adding more bits in the
message descriptor.
Untyped Atomic Operations are now message 0010 in the second data cache
data port, rather than 6 in the first.
v2
This avoids some snooping overhead between EUs processing separate shaders
(so VS versus FS).
Improves performance of a minecraft trace with shader_time by 28.9% +/-
18.3% (n=7), and performance of my old GLSL demo by 93.7% +/- 0.8% (n=4).
---
src/mesa/drivers/dri/i965/brw_fs.cpp|2 +-
sr
From: Kenneth Graunke
Untyped Atomic Operation messages are illegal for non-RAW formats. The
IVB hardware proceeds happily (after all, who cares what the format of the
surface is if you're doing untyped ops on it?), but later hardware
apparently doesn't. The simulator for gen7 does complain, th
On 03/11/2013 12:44 PM, ritvik_sha...@dell.com wrote:
Hi All,
I don’t have any Graphic Cards that support OpenGL , so I want to
perform software rendering with Mesa without X, DRM etc. Also can
someone explain how are the functions for eg. glClear (_mesa_clear the
actual implementation) are invo
From: Kenneth Graunke
This is basically a copy and paste of gen7_create_constant_surface, but
with the parameters filled in to offer a simpler interface.
It will diverge shortly.
I didn't bother adding it to the vtable for now since shader time is only
exposed on Gen7+.
v2: Replace tabs in the
Here's my rebase of Ken's shader_time updates for Haswell, attempting to
incorporate review feedback plus my discomfort with the discussion of
addressing changes (it was superfluous -- the messages we're sending are
the untyped byte offsets same both ways, and the RAW vs RGBA32F in the
surface stat
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #11 from Keith Kriewall ---
I just tried that (signed fields ahead of unsigned) and it didn't help in this
case. The modified struct began as:
struct prog_src_register
{
GLint Index:(INST_INDEX_BITS+1); /**< Extra bit here for si
This patch makes the following search-and-replace changes:
gl_frag_attrib -> gl_varying_slot
FRAG_ATTRIB_* -> VARYING_SLOT_*
FRAG_BIT_* -> VARYING_BIT_*
--
Note: this patch is very large, so for purposes of mailing list
discussion I've trimmed it down to representative example hunks. To
see the
Now that there is no difference between the enums that represent
vertex outputs and fragment inputs, there's no need for a conversion
function.
---
src/mesa/drivers/dri/i965/gen6_sf_state.c | 15 +++
src/mesa/main/mtypes.h| 26 +-
2 files cha
Now that there is no difference between the enums that represent
vertex outputs and fragment inputs, there's no need for a conversion
function. But we still need to be able to detect when a given vertex
output has no corresponding fragment input. So it is replaced by a
new function, _mesa_varying
This paves the way for eliminating the gl_frag_attrib enum entirely.
---
src/mesa/main/mtypes.h| 45 ++-
src/mesa/program/prog_print.c | 15 +++
2 files changed, 34 insertions(+), 26 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src
This patch makes the following search-and-replace changes:
gl_geom_result -> gl_varying_slot
GEOM_RESULT_* -> VARYING_SLOT_*
---
src/mesa/main/context.c| 2 --
src/mesa/main/mtypes.h | 28 --
src/mesa/program/program.c |
This paves the way for eliminating the gl_geom_result enum entirely.
---
src/mesa/main/mtypes.h | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index c01d584..d760d21 100644
--- a/src/me
This patch makes the following search-and-replace changes:
gl_geom_attrib -> gl_varying_slot
GEOM_ATTRIB_* -> VARYING_SLOT_*
GEOM_BIT_* -> VARYING_BIT_*
---
src/mesa/main/context.c | 2 --
src/mesa/main/mtypes.h | 41 -
src/mesa/progra
This paves the way for eliminating the gl_geom_attrib enum entirely.
---
src/mesa/main/mtypes.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 1e62e19..b39c9c5 100644
--- a/src/mesa/main/mtypes.
This patch makes the following search-and-replace changes:
gl_vert_result -> gl_varying_slot
VERT_RESULT_* -> VARYING_SLOT_*
--
Note: this patch is very large, so for purposes of mailing list
discussion I've trimmed it down to representative example hunks. To
see the complete patch, please refer
This paves the way for eliminating the gl_vert_result enum entirely.
---
src/mesa/main/mtypes.h| 67 +--
src/mesa/program/prog_print.c | 4 +++
2 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/m
Future patches will make use of the enum. It will eventually take the
place of the existing enums gl_vert_result, gl_geom_attrib,
gl_geom_result, and gl_frag_attrib, all of which represent essentially
the same information but using inconsistent values.
---
src/mesa/main/mtypes.h | 70
This patch updates the bitfields brw_context::wm.input_size_masks,
tracker::size_masks, and brw_wm_prog_key::proj_attrib_mask, all of
which are indexed by gl_frag_attrib, from 32-bit to 64-bit.
This paves the way for supporting geometry shaders, and for merging
the gl_frag_attrib and gl_vert_resul
This patch series combines the enums gl_vert_result, gl_geom_attrib,
gl_geom_result, and gl_frag_attrib into a single enum.
These four enums serve very similar purposes: they all identify data
that flows through the pipeline from vertex shader to fragment shader,
but their definitions don't match.
Both patches are
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
- Original Message -
> Am 11.03.2013 15:52, schrieb Jose Fonseca:
> > Christian,
> >
> > I didn't comment on the previous threads, but the approach mentioned in
> > http://lists.freedesktop.org/archives/mesa-dev/2012-November/030476.html
> > seems sensible to me.
> >
> > I think after the
On 11.03.2013 19:33, Brian Paul wrote:
> On 03/11/2013 06:44 AM, Christian König wrote:
>> Hi everybody,
>>
>> this problem has been open for quite some time now, with a bunch of
>> different
>> opinions and sometimes even patches floating on the list.
>>
>> The solutions proposed or implemented so
Ian Romanick writes:
> On 03/11/2013 07:56 AM, Jose Fonseca wrote:
>> I'm surprised this is is faster.
>>
>> In particular, for big things we'll be touching memory twice.
>>
>> Did you measure the speed up?
>
> The second hit is cache-hot, so it may not be too expensive. I suspect
> memcpy is o
- Original Message -
> On 03/11/2013 11:30 AM, Jose Fonseca wrote:
> > - Original Message -
> >> On 03/11/2013 07:56 AM, Jose Fonseca wrote:
> >>> I'm surprised this is is faster.
> >>>
> >>> In particular, for big things we'll be touching memory twice.
> >>>
> >>> Did you measure
Kenneth Graunke writes:
> This makes dump_instructions more useful.
Reviewed-by: Eric Anholt
pgpH3SqL1AwC7.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 03/11/2013 11:30 AM, Jose Fonseca wrote:
- Original Message -
On 03/11/2013 07:56 AM, Jose Fonseca wrote:
I'm surprised this is is faster.
In particular, for big things we'll be touching memory twice.
Did you measure the speed up?
The second hit is cache-hot, so it may not be too
Hi All,
I don't have any Graphic Cards that support OpenGL , so I want to perform
software rendering with Mesa without X, DRM etc. Also can someone explain how
are the functions for eg. glClear (_mesa_clear the actual implementation) are
invoked without glx?
Thanks
Ritvik
___
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #10 from Brian Paul ---
Can you try reordering the fields such that all the signed fields come before
the unsigned fields (or vice versa)? I was tinkering with a test program and
that seemed to help, but I haven't done extensive test
On Mon, Mar 11, 2013 at 1:30 PM, Jose Fonseca wrote:
> - Original Message -
> > On 03/11/2013 07:56 AM, Jose Fonseca wrote:
> > > I'm surprised this is is faster.
> > >
> > > In particular, for big things we'll be touching memory twice.
> > >
> > > Did you measure the speed up?
> >
> > Th
On 03/11/2013 06:44 AM, Christian König wrote:
Hi everybody,
this problem has been open for quite some time now, with a bunch of different
opinions and sometimes even patches floating on the list.
The solutions proposed or implemented so far all more or less incomplete, so
this approach was des
Since apps typically begin rendering with a call to glClear(), it is
likely that when brw_workaround_depthstencil_alignment() moves a
miplevel to a temporary buffer, it can avoid doing a blit, since the
contents of the miplevel are about to be erased.
This patch adds the necessary plumbing to dete
Fast depth clears have the same depth/stencil alignment requirements
as other drawing operations. Therefore, we need to call
brw_workaround_depthstencil_alignment() from both the clear and
drawing paths.
Without this fix, we get image corruption if the following conditions
hold: (a) the first eve
- Original Message -
> On 03/11/2013 07:56 AM, Jose Fonseca wrote:
> > I'm surprised this is is faster.
> >
> > In particular, for big things we'll be touching memory twice.
> >
> > Did you measure the speed up?
>
> The second hit is cache-hot, so it may not be too expensive.
Yes, but t
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #9 from Keith Kriewall ---
Sorry, I didn't mean to imply that the signed issue is causing this problem.
I've tried increasing the 'File' bit field size by one, and it made no obvious
difference. I just wanted to note the difference
This patch didn't incorporate review from last time.
pgpf0iYPA7iZ9.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Matt Turner writes:
> One fewer place to have to update.
In a couple places here you changed "MESA" to "Mesa" in user-visible
version strings. I think this is a reasonable and good thing to do, but
it's not mentioned in the commit message. If you split that out into a
separate patch, then patc
Alan Hourihane writes:
> On 03/06/13 18:36, Brian Paul wrote:
>> On 03/06/2013 11:23 AM, Alan Hourihane wrote:
>>> If the sampler object has been deleted on another context, an
>>> alternative context may reference the old sampler. So ensure the sampler
>>> object still exists.
>>
>> Alan, is thi
Matt Turner writes:
> A step toward working make dist/distcheck.
> ---
> configure.ac | 37 -
> src/Makefile.am | 30 +++---
> src/mapi/Makefile.am | 42 ++
> 3 files changed, 7
This makes dump_instructions more useful.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 16
1 file changed, 16 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index f319f32..8e65be8 100644
I don't think you have to worry about the difference in buffer depths.
If you really want a 24-bit depth buffer you can do 'export
MESA_GLX_DEPTH_BITS=24'
-Brian
On 03/09/2013 12:48 AM, jupiter wrote:
Hi Brian,
Please see attached config.log. Le me make a correction, I mean 32
buffer bit an
On 03/11/2013 07:56 AM, Jose Fonseca wrote:
I'm surprised this is is faster.
In particular, for big things we'll be touching memory twice.
Did you measure the speed up?
The second hit is cache-hot, so it may not be too expensive. I suspect
memcpy is optimized to fill the cache in a more eff
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #8 from Roland Scheidegger ---
(In reply to comment #7)
> In case it helps, it appears that MSVC always treats enum values as signed
> int. E.g. see:
>
> http://compgroups.net/comp.lang.c++/problem-with-visual-c++-7.1.3088-and-bit-
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #7 from Keith Kriewall ---
In case it helps, it appears that MSVC always treats enum values as signed int.
E.g. see:
http://compgroups.net/comp.lang.c++/problem-with-visual-c++-7.1.3088-and-bit-fields/1013665
GCC appears to use un
https://bugs.freedesktop.org/show_bug.cgi?id=61907
--- Comment #3 from Colin McDonald ---
The piglit test tests/texturing/tex-skipped-unit.c demonstrates the
problem, as it uses texture unit 1 with glTexCoordPointer.
Using direct rendering, test passes.
$ piglit-run.py --tests=skip tests/all.te
Vinson Lee writes:
> Fixes mixing enum types defects reported by Coverity.
Reviewed-by: Eric Anholt
I'm disappointed in gcc that there's -Wenum-compare, but nothing to
complain about implicit conversions between enum types. (between an enum
and int I'm fine with, unlike C++, but enum to enum i
I only skimmed, but looks good in principle.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Previously, the derivatives were calculated and passed in a packed form
> to the sample code (for implicit derivatives, explicit derivatives were
> packed to the same format).
> There's
On Sun, Mar 10, 2013 at 11:56 PM, Vinson Lee wrote:
> Fixes mixing enum types defects reported by Coverity.
>
> Signed-off-by: Vinson Lee
> ---
> src/mesa/main/errors.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
>
On Mon, Mar 11, 2013 at 3:56 PM, Jose Fonseca wrote:
> I'm surprised this is is faster.
>
> In particular, for big things we'll be touching memory twice.
>
> Did you measure the speed up?
I tested it with the previous patch, with GL_UNSIGNED_BYTE, and on
that case it was faster, but since that pa
- Original Message -
> hot to build mesa
> in
> windows
> use
> mingw scons ?
>
> if use `scons platform=windows toolchain=crossmingw machine=x86 build=release
> mesagdi libgl-gdi`
>
> will happan
>
> [build\windows-x86\mesa\libmesa.a] Error 1
>
> without any tips
Surely there must be
Am 11.03.2013 15:52, schrieb Jose Fonseca:
Christian,
I didn't comment on the previous threads, but the approach mentioned in
http://lists.freedesktop.org/archives/mesa-dev/2012-November/030476.html seems
sensible to me.
I think after the first round we should have this in a branch to allow d
On 11.03.2013 15:38, Christian König wrote:
> Am 11.03.2013 14:47, schrieb Christoph Bumiller:
>> On 11.03.2013 13:44, Christian König wrote:
>>> Hi everybody,
>>>
>>> this problem has been open for quite some time now, with a bunch of
>>> different
>>> opinions and sometimes even patches floating
On Mon, Mar 11, 2013 at 9:56 AM, Jose Fonseca wrote:
> I'm surprised this is is faster.
>
> In particular, for big things we'll be touching memory twice.
>
> Did you measure the speed up?
>
> Jose
>
I'm sorry to be dull, but is there a SSE2 implementation of this somewhere
for x86 / x64 CPUs?
P
I'm surprised this is is faster.
In particular, for big things we'll be touching memory twice.
Did you measure the speed up?
Jose
- Original Message -
> ---
> src/mesa/main/readpix.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/readpix.c
Christian,
I didn't comment on the previous threads, but the approach mentioned in
http://lists.freedesktop.org/archives/mesa-dev/2012-November/030476.html seems
sensible to me.
I think after the first round we should have this in a branch to allow drivers
to catch up with the interface change
Am 11.03.2013 14:47, schrieb Christoph Bumiller:
On 11.03.2013 13:44, Christian König wrote:
Hi everybody,
this problem has been open for quite some time now, with a bunch of different
opinions and sometimes even patches floating on the list.
Nice, finally someone implements a proper solution.
- Original Message -
> On 11.03.2013 11:26, Jose Fonseca wrote:
> > First email was too long, so re-sending just the interesting bits)
>
> Please tell me removing this came to mind because you're going to
> release a better D3D9,10/11 state tracker :)
> (Nah I guess it would be too much tr
On 11.03.2013 13:44, Christian König wrote:
> Hi everybody,
>
> this problem has been open for quite some time now, with a bunch of different
> opinions and sometimes even patches floating on the list.
Nice, finally someone implements a proper solution.
However, it seems like this isn't used for ar
On Mon, Mar 11, 2013 at 11:54 AM, Michel Dänzer wrote:
> On Son, 2013-03-10 at 23:05 +0100, Martin Andersson wrote:
>> ---
>> src/mesa/main/readpix.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
>> index 2f130ae..349
On 11.03.2013 11:26, Jose Fonseca wrote:
> First email was too long, so re-sending just the interesting bits)
Please tell me removing this came to mind because you're going to
release a better D3D9,10/11 state tracker :)
(Nah I guess it would be too much trouble if there's no users for it ...)
Th
From: Christian König
To further improve the optimization of source and destination
indirect addressing we need the ability to store a reference
to the declaration of the addressed operands.
Since most of the fields in tgsi_src_register doesn't apply for
an indirect addressing operand replace it
From: Christian König
Nobody seems to be using it, and only nv50 had a partial implementation.
Signed-off-by: Christian König
---
src/gallium/auxiliary/tgsi/tgsi_build.c| 19 -
src/gallium/auxiliary/tgsi/tgsi_dump.c | 38 -
src/gallium/auxiliary/tgsi/tgs
From: Christian König
They shouldn't be necessary any more.
Signed-off-by: Christian König
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 36 +++-
1 file changed, 3 insertions(+), 33 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/s
From: Christian König
Instead of allocating everything as temporaries, use the
new array allocation functions.
Signed-off-by: Christian König
---
src/mesa/main/mtypes.h |1 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 83 ++--
2 files changed
From: Christian König
Signed-off-by: Christian König
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 131e
From: Christian König
Don't bother with free temporaries, just allocate them at
the end and also emit them in their own declaration.
Signed-off-by: Christian König
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 55
src/gallium/auxiliary/tgsi/tgsi_ureg.h | 38
From: Christian König
Instead of emitting each temporary separately, emit them in a chunk.
Signed-off-by: Christian König
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 53 ++--
1 file changed, 17 insertions(+), 36 deletions(-)
diff --git a/src/gallium/auxiliary/tg
Hi everybody,
this problem has been open for quite some time now, with a bunch of different
opinions and sometimes even patches floating on the list.
The solutions proposed or implemented so far all more or less incomplete, so
this approach was designed in mind with both completeness and compatib
On Son, 2013-03-10 at 23:05 +0100, Martin Andersson wrote:
> ---
> src/mesa/main/readpix.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
> index 2f130ae..349b0bc 100644
> --- a/src/mesa/main/readpix.c
> +++ b/src/mesa/m
First email was too long, so re-sending just the interesting bits)
From: José Fonseca
Unused/unmaintained.
---
configure.ac | 21 -
src/gallium/docs/source/context.rst|2 +-
src/gallium/state_trackers/d3d1x/.gitignore| 20 -
https://bugs.freedesktop.org/show_bug.cgi?id=59187
kost BebiX changed:
What|Removed |Added
CC||k...@ya.ru
--
You are receiving this mail
87 matches
Mail list logo
