https://bugs.freedesktop.org/show_bug.cgi?id=59187
kost BebiX k...@ya.ru changed:
What|Removed |Added
CC||k...@ya.ru
--
You are receiving
First email was too long, so re-sending just the interesting bits)
From: José Fonseca jfons...@vmware.com
Unused/unmaintained.
---
configure.ac | 21 -
src/gallium/docs/source/context.rst|2 +-
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
+++
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
From: Christian König christian.koe...@amd.com
Instead of emitting each temporary separately, emit them in a chunk.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 53 ++--
1 file changed, 17 insertions(+), 36
From: Christian König christian.koe...@amd.com
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 christian.koe...@amd.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 55
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
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
From: Christian König christian.koe...@amd.com
Instead of allocating everything as temporaries, use the
new array allocation functions.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/mesa/main/mtypes.h |1 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |
From: Christian König christian.koe...@amd.com
Nobody seems to be using it, and only nv50 had a partial implementation.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/auxiliary/tgsi/tgsi_build.c| 19 -
src/gallium/auxiliary/tgsi/tgsi_dump.c
From: Christian König christian.koe...@amd.com
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
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 ...)
On Mon, Mar 11, 2013 at 11:54 AM, Michel Dänzer mic...@daenzer.net 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
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
- 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 trouble
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
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
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
On Mon, Mar 11, 2013 at 9:56 AM, Jose Fonseca jfons...@vmware.com 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 /
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 the list.
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
- 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 more output
On Mon, Mar 11, 2013 at 3:56 PM, Jose Fonseca jfons...@vmware.com 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,
On Sun, Mar 10, 2013 at 11:56 PM, Vinson Lee v...@freedesktop.org wrote:
Fixes mixing enum types defects reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/mesa/main/errors.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
I only skimmed, but looks good in principle.
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
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
Vinson Lee v...@freedesktop.org writes:
Fixes mixing enum types defects reported by Coverity.
Reviewed-by: Eric Anholt e...@anholt.net
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
https://bugs.freedesktop.org/show_bug.cgi?id=61907
--- Comment #3 from Colin McDonald cjmmail10...@yahoo.co.uk ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #7 from Keith Kriewall keith.kriew...@attachmate.com ---
In case it helps, it appears that MSVC always treats enum values as signed int.
E.g. see:
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #8 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #7)
In case it helps, it appears that MSVC always treats enum values as signed
int. E.g. see:
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
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
This makes dump_instructions more useful.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
Matt Turner matts...@gmail.com writes:
A step toward working make dist/distcheck.
---
configure.ac | 37 -
src/Makefile.am | 30 +++---
src/mapi/Makefile.am | 42 ++
3
Alan Hourihane al...@fairlite.co.uk 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,
Matt Turner matts...@gmail.com 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #9 from Keith Kriewall keith.kriew...@attachmate.com ---
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
- 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 the size in
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
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
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
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
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
Kenneth Graunke kenn...@whitecape.org writes:
This makes dump_instructions more useful.
Reviewed-by: Eric Anholt e...@anholt.net
pgpH3SqL1AwC7.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
- 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 the speed up?
The
Ian Romanick i...@freedesktop.org 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
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 far all more
- 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 first round
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
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 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
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_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
---
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 -
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
---
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_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
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,
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #11 from Keith Kriewall keith.kriew...@attachmate.com ---
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
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
From: Kenneth Graunke kenn...@whitecape.org
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+.
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
From: Kenneth Graunke kenn...@whitecape.org
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
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 +-
From: Kenneth Graunke kenn...@whitecape.org
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
On Sat, Mar 2, 2013 at 7:29 AM, Brian Paul bri...@vmware.com 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
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
---
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
---
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
+
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
---
---
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
---
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 @@
p
-Mesa's
---
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
---
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
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
On Mon, Mar 11, 2013 at 6:49 PM, Ian Romanick i...@freedesktop.org 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
On Mon, Mar 11, 2013 at 1:44 PM, Christian König
deathsim...@vodafone.de 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
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 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).
---
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
jtur...@kemper.freedesktop.org
On Mon, Mar 11, 2013 at 5:28 PM, Brian Paul bri...@vmware.com wrote:
On Sat, Mar 2, 2013 at 7:29 AM, Brian Paul bri...@vmware.com 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
82 matches
Mail list logo
