Nothing uses this structure, removal fixes Klocwork error about
the possible oom condition in _mesa_symbol_table_iterator_ctor.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/program/symbol_table.c | 86 -
src/mesa/program/symbol_table.h |
Probably depending on compiler settings, the definition can be hidden,
so undefined reference error can be encountred during linking
https://bugs.freedesktop.org/show_bug.cgi?id=75528
---
src/gbm/main/gbm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gbm/main/gbm.c
On 02/27/2014 12:30 AM, Ian Romanick wrote:
Did you piglit run this? I applied it on current master, and about
2,700 piglit tests assert.
Yes, at the time there were no piglit errors. Confirmed, the patch
series breaks current master.
Not to mention it doesn't apply cleanly anymore
https://bugs.freedesktop.org/show_bug.cgi?id=63717
--- Comment #3 from Kenneth Graunke kenn...@whitecape.org ---
I suspect that upgrading to Mesa 10.1 (due to be released in a few days) should
help quite a bit, though I haven't measured it.
In particular, Matt's vectorizer work reduces sequences
Am 27.02.2014 03:14, schrieb Jason Wood:
On 02/26/2014 06:55 PM, Ian Romanick wrote:
On 02/26/2014 05:22 PM, Jason Wood wrote:
On 02/26/2014 04:27 PM, Adel Gadllah wrote:
Move the pdraw != NULL check out so that they don't
have to be duplicated.
Signed-off-by: Adel Gadllah
https://bugs.freedesktop.org/show_bug.cgi?id=74010
Evgeny Bobkin evgen.i...@gmail.com changed:
What|Removed |Added
Attachment #92718|text/plain |video/webm
https://bugs.freedesktop.org/show_bug.cgi?id=74010
--- Comment #7 from Evgeny Bobkin evgen.i...@gmail.com ---
Thank you for the explanation, maybe your are correct. From my point of view it
should definitely not end up with a segmentation fault.
(In reply to comment #6)
I've encountered this
v2: Don't add function parameters, pass the required size in
prog_data-nr_params.
v3:
- Use the name uniform_array_size instead of uniform_param_count.
- Round up when dividing param_count by 4.
- Use MAX2() instead of taking the maximum by hand.
- Don't crash if prog_data passed to vec4_visitor
Fixing https://bugs.freedesktop.org/show_bug.cgi?id=71254 once again.
Rebased for current master, plumbing-class changes to patch 1/2. Fixed
one of the asserts in patch 2/2.
Full piglit run shows no regressions.
Petri Latvala (2):
i965: Allocate vec4_visitor's uniform_size and
v2: vec4_visitor::pack_uniform_registers(): Use correct comparison in the
assert, this-uniforms is already adjusted. Compare the actual value used to
index uniform_size and uniform_vector_size instead.
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
On 27/02/14 08:23, Marek Chalupa wrote:
Probably depending on compiler settings, the definition can be hidden,
so undefined reference error can be encountred during linking
When building with automake, the definition will be hidden if the
compiler supports visibility flags. This was done with
Kenneth Graunke kenn...@whitecape.org writes:
API is always API_OPENGL_COMPAT (since commit 4e4a537ad55f61a25,
meta: Push into desktop GL mode when doing meta operations.),
so most of these checks do nothing.
We could instead check save-API to only bother setting/restoring
relevant GL
With commit 0432aa064b(configure: use shared-glapi when more than one
gl* API is used) we removed disable shared-glapi when building without
dri hunk.
In the good old days of classic mesa, dri and xlib-glx were mutually
exclusive thus the hunk made sense.
Currently enable-dri is used as a
On Thu, Feb 27, 2014 at 11:03 AM, Emil Velikov emil.l.veli...@gmail.comwrote:
With commit 0432aa064b(configure: use shared-glapi when more than one
gl* API is used) we removed disable shared-glapi when building without
dri hunk.
In the good old days of classic mesa, dri and xlib-glx were
glGetTexImage(GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8) was just
using memcpy() instead of _mesa_unpack_uint_24_8_depth_stencil_row()
to convert texels from the hardware format to the GL format.
Fixes issue reported by David Meng at Intel. The new piglit
ext_packed_depth_stencil-getteximage test
GLX can be either dri or xlib based, while enable_dri is
used in a variety of contexts.
With enable_dri_glx the context is clearly visible.
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
configure.ac | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git
From: Jerome Glisse jgli...@redhat.com
There is no reason anymore to load with RTLD_GLOBAL and for some driver
this even result in dlclose failing to unload leading to catastrophic
failure with swrast fallback.
Signed-off-by: Jérôme Glisse jgli...@redhat.com
---
src/glx/dri_common.c | 10
On Thu, Feb 27, 2014 at 10:32 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
GLX can be either dri or xlib based, while enable_dri is
used in a variety of contexts.
With enable_dri_glx the context is clearly visible.
I think this makes it more confusing...
We're just adding an extra
On 27/02/14 19:04, Matt Turner wrote:
On Thu, Feb 27, 2014 at 10:32 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
GLX can be either dri or xlib based, while enable_dri is
used in a variety of contexts.
With enable_dri_glx the context is clearly visible.
I think this makes it more
https://bugs.freedesktop.org/show_bug.cgi?id=75584
Priority: medium
Bug ID: 75584
Assignee: mesa-dev@lists.freedesktop.org
Summary: Request write access to mesa repository
Severity: normal
Classification: Unclassified
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=75584
--- Comment #1 from Courtney Goeltzenleuchter court...@lunarg.com ---
Created attachment 94849
-- https://bugs.freedesktop.org/attachment.cgi?id=94849action=edit
GPG public key
--
You are receiving this mail because:
You are the assignee for
On 25/02/14 08:24, Matt Turner wrote:
On Mon, Feb 24, 2014 at 3:05 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Building to provide accelration using swrast does not make
sense.
Note: update your build script to explicitly mention svga
in the gallium drivers list, if you are building
Since RC2 there have been 37 commits to the 10.1 branch. There are at
least 4 patches on the mailing list for review that are tagged for
inclusion in the branch.
The plan of record is to release 10.1 tomorrow. I don't think that's a
good idea. How do people feel about having an RC3
While in expected usage patterns nobody will ever hit this path, doubling
our bandwidth usedd used seems like a waste, and it cost us extra code too.
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 103 ---
src/mesa/drivers/dri/i965/intel_buffer_objects.h | 7 +-
2
On LLC, it should always be better to use a cached mapping than the GTT.
On non-LLC, it seems pretty silly to try to optimize read performance for
the INVALIDATE_RANGE_BIT case. This will make the buffer_storage logic
easier.
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 6 +++---
1
One thing I noticed while working on this was that we only reallocate buffer
storage for INVALIDATE_BUFFER_BIT when UNSYNCHRONIZED_BIT is unset. The
ARB_mbr spec says that the contents may be discarded, not must be
discarded. However, while writing the glamor code I happened to type this
for the
It looks like there's no big difference for write-only workloads, but
using a CPU map means that if they happen to read without having set the
MAP_READ_BIT, they get 100x the performance for those reads.
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 2 +-
1 file changed, 1 insertion(+),
It turns out we can allow COHERENT storage/mappings all the time,
regardless of LLC vs non-LLC. It just means never using temporary
mappings to avoid GPU stalls, and on non-LLC we have to use the GTT intead
of CPU mappings. If we were to use CPU maps on non-LLC (which might be
useful if apps end
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/api_arrayelt.c | 111 ++-
1 file changed, 57 insertions(+), 54 deletions(-)
It's possible that this patch fixes a segfault in FlightGear (see bug 73504),
so I think it's a candidate for the 10.1
Sounds fine to me.
-Brian
On 02/27/2014 02:08 PM, Ian Romanick wrote:
Since RC2 there have been 37 commits to the 10.1 branch. There are at
least 4 patches on the mailing list for review that are tagged for
inclusion in the branch.
The plan of record is to release 10.1 tomorrow. I don't
Hey!
I thank you for the information!
Dragomir has also provided me with some helpful links and jljusten solved a
lot of my queries on IRC.
I am trying to understand how things are working and will start working on
a proposal!
Thanks!
Chirag Agrawal
Department of Computer Science
BITS Pilani,
I've been following mesa development for a while and am hoping to find a
good project in either the r600 or radeonsi drivers that would give me a
place to start learning about the general structure of mesa dev. I have a
solid understanding of C and a reasonable familiarity with OpenGL.
Suggestions
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Note: this applies on top of airlied's r600g-texture-gather branch.
Appears to pass all 4 piglit tests. The conversion from what the instruction
outputs is the same as what the blob does.
src/gallium/drivers/nouveau/codegen/nv50_ir.h |
This is needed for MIN2/MAX2
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/auxiliary/util/u_range.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_range.h
b/src/gallium/auxiliary/util/u_range.h
index 4b1d0d1..efe25ef 100644
---
j.gli...@gmail.com writes:
From: Jerome Glisse jgli...@redhat.com
There is no reason anymore to load with RTLD_GLOBAL and for some driver
this even result in dlclose failing to unload leading to catastrophic
failure with swrast fallback.
I don't remember the last time drivers relied on GL
Brian Paul bri...@vmware.com writes:
glGetTexImage(GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8) was just
using memcpy() instead of _mesa_unpack_uint_24_8_depth_stencil_row()
to convert texels from the hardware format to the GL format.
Fixes issue reported by David Meng at Intel. The new piglit
36 matches
Mail list logo
