Brian Paul 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
> ext_packed_d
j.gli...@gmail.com writes:
> From: Jerome Glisse
>
> 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 symbols being
p
This is needed for MIN2/MAX2
Signed-off-by: Ilia Mirkin
---
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
--- a/src/gallium/auxiliary/util/u_ran
Signed-off-by: Ilia Mirkin
---
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 | 1 +
.../drivers/nouv
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
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, Go
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 thin
Cc: "10.1"
---
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 branch, but maybe not for 10.1.0
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
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
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(+), 1
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 fil
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 file
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 tomorrow
On 25/02/14 08:24, Matt Turner wrote:
> On Mon, Feb 24, 2014 at 3:05 PM, Emil Velikov
> 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 the vmwgfx
>>
https://bugs.freedesktop.org/show_bug.cgi?id=75584
--- Comment #1 from Courtney Goeltzenleuchter ---
Created attachment 94849
--> https://bugs.freedesktop.org/attachment.cgi?id=94849&action=edit
GPG public key
--
You are receiving this mail because:
You are the assignee for the bug.
_
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: All
On 27/02/14 19:04, Matt Turner wrote:
> On Thu, Feb 27, 2014 at 10:32 AM, Emil Velikov
> 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...
>
>
On Thu, Feb 27, 2014 at 10:32 AM, Emil Velikov 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 variable and not simplifyin
From: Jerome Glisse
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
---
src/glx/dri_common.c | 10 +-
1 file changed, 5 insertions(+)
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
---
configure.ac | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.a
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 ch
On Thu, Feb 27, 2014 at 11:03 AM, Emil Velikov wrote:
> 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
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 synon
Kenneth Graunke 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 state, but I'm not
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 wit
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
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 ++
s
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 uniform_vector_s
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
https://bugs.freedesktop.org/show_bug.cgi?id=74010
--- Comment #7 from Evgeny Bobkin ---
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 segfault before, and i
https://bugs.freedesktop.org/show_bug.cgi?id=74010
Evgeny Bobkin changed:
What|Removed |Added
Attachment #92718|text/plain |video/webm
mime type|
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
Reviewed-by: Ian R
https://bugs.freedesktop.org/show_bug.cgi?id=63717
--- Comment #3 from Kenneth Graunke ---
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 of 4 extended math
op
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 anyway
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 b/s
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
---
src/mesa/program/symbol_table.c | 86 -
src/mesa/program/symbol_table.h | 13 ---
2 files ch
36 matches
Mail list logo
