I have a local change which extends ApiTrace to better support the various
debug extensions, and have used it to mark up my traces. I don't track the
whole log or handle the registering of callback functions, but do allow
glDebugMessageInsertARB(..) and a few others to be included in the trace
Fixes Resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/drivers/radeonsi/radeonsi_compute.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_compute.c
https://bugs.freedesktop.org/show_bug.cgi?id=61919
--- Comment #6 from Quentin Glidic sardemff7+freedesk...@sardemff7.net ---
I think the issue can be fixed patching
src/gallium/winsys/sw/xlib/Makefile.am to use $(XCB_DRI2_CFLAGS) instead of
$(X11_CFLAGS). Do you want a patch?
--
You are
- Original Message -
Michel Dänzer mic...@daenzer.net writes:
On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
them with endian-variant BGR565 and RGB565 makes a lot of sense (as
the swapped version
On Die, 2013-06-04 at 01:15 -0700, Jose Fonseca wrote:
- Original Message -
Michel Dänzer mic...@daenzer.net writes:
On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
them with endian-variant BGR565
- Original Message -
- Original Message -
Michel Dänzer mic...@daenzer.net writes:
On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
them with endian-variant BGR565 and RGB565 makes a lot
From: Mike Stroyan m...@lunarg.com
When building dri-swrast, use gallium_check_st to set HAVE_COMMON_DRI.
Commit 07f2dee7 added setting of HAVE_COMMON_DRI in gallium_check_st.
But the dri-swrast case did not use gallium_check_st.
So dri/common was still not built.
v2: set HAVE_COMMON_DRI=yes
Jose Fonseca jfons...@vmware.com writes:
Yeah, that's what the patch was trying to do. Even though the formats
were defined as ints, the int layout was extra information on top of
what's already there. The int information didn't change or replace the
array information.
So the idea is that
On 3 June 2013 22:16, Kenneth Graunke kenn...@whitecape.org wrote:
I don't think we should implement front buffer rendering for EGL unless
someone presents a compelling use case. In my mind, front buffer rendering
is only something used historically...it has all kinds of caveats about
On Mon, 2013-06-03 at 12:14 -0400, Adam Jackson wrote:
diff --git a/src/gallium/docs/format.rst b/src/gallium/docs/format.rst
new file mode 100644
index 000..e6de569
--- /dev/null
+++ b/src/gallium/docs/format.rst
@@ -0,0 +1,39 @@
+Formats in gallium
+==
+
+Gallium
- Original Message -
On Die, 2013-06-04 at 01:15 -0700, Jose Fonseca wrote:
- Original Message -
Michel Dänzer mic...@daenzer.net writes:
On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
I agree that with non-array formats, like B5G6R5 and R5G6B5,
- Original Message -
Jose Fonseca jfons...@vmware.com writes:
Yeah, that's what the patch was trying to do. Even though the formats
were defined as ints, the int layout was extra information on top of
what's already there. The int information didn't change or replace the
array
On Die, 2013-06-04 at 10:47 +0100, Richard Sandiford wrote:
(2) it uses PIPE_FORMAT_INT_* names with the lsb first rather than the
mesa-like ones with msb first. (I'm happy to change the names to
something else though.)
The patch isn't in a submittable state yet. I just thought
https://bugs.freedesktop.org/show_bug.cgi?id=61919
--- Comment #7 from Darxus dar...@chaosreigns.com ---
Quentin: I think it is safe to say that creating, verifying, and uploading a
patch would be helpful.
--
You are receiving this mail because:
You are the assignee for the bug.
- Original Message -
From: Roland Scheidegger srol...@vmware.com
The code was designed to handle no-op concat but failed (unless the
caller was using same pointer for src and dst).
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c |6 +-
1 file changed, 5 insertions(+), 1
Adds the dependencies of builtin_compiler as sources when cross
compiling instead of using libtool to share compilation with src/glsl.
The builtin_compiler executable is built for the host when cross
compiling so it doesn't make sense to share compilation with src/glsl
built for the target in this
The AC_CHECK_FILE macro can't be used for cross compiling as it will
result in error: cannot check for file existence when cross compiling.
Replace it with the AS_IF macro.
Signed-off-by: Jonathan Liu net...@gmail.com
---
configure.ac | 12 ++--
1 file changed, 6 insertions(+), 6
Hello,
First of all, I'm not sure if it's the right place to ask such a question,
but I'll try. I've started learning OpenGL and I really want to contribute
to Mesa project, but the way to do it had always been a mistery for me. As
a beginner contributor, I still don't understand which bugs
Am 04.06.2013 14:38, schrieb Jose Fonseca:
- Original Message -
From: Roland Scheidegger srol...@vmware.com
The code was designed to handle no-op concat but failed (unless the
caller was using same pointer for src and dst).
---
src/gallium/auxiliary/gallivm/lp_bld_pack.c |6
I haven't been following this thread too closely, but FWIW, if people
are interested in implementing the GL_KHR_debug extension in Mesa, I've
got some unfinished code that implements debug labels (glObjectLabel,
glGetObjectLabel, etc). I'd happily pass it along to anyone who wants
to work on
https://bugs.freedesktop.org/show_bug.cgi?id=65226
--- Comment #1 from Brian Paul bri...@vmware.com ---
This test used to be skipped. We're mistakenly reporting support for more than
one address register, when Mesa doesn't really handle that. I'm posting a
patch to mesa-dev...
--
You are
We've never properly supported more than one address register. There
isn't even a field in prog_src_register or prog_dst_Register to indicate
which address register to use if RelAddr!=0.
In the state tracker, clamp MaxAddressRegs against MAX_PROGRAM_ADDRESS_REGS
since many gallium drivers do
This patch unifies mesa's PACKAGE_VERSION on autotools, scons and
Android build systems.
Current behaviour is:
- Autotools uses 9.2.0 as PACKAGE_VERSION
- Scons and Android use 9.2-devel as PACKAGE_VERSION
With this patch all three build systems use 9.2.0-devel as
PACKAGE_VERSION.
---
- Original Message -
We've never properly supported more than one address register. There
isn't even a field in prog_src_register or prog_dst_Register to indicate
which address register to use if RelAddr!=0.
In the state tracker, clamp MaxAddressRegs against
https://bugs.freedesktop.org/show_bug.cgi?id=65226
Brian Paul brian.e.p...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Brian Paul bri...@vmware.com writes:
We've never properly supported more than one address register. There
isn't even a field in prog_src_register or prog_dst_Register to indicate
which address register to use if RelAddr!=0.
In the state tracker, clamp MaxAddressRegs against
On 06/04/2013 06:37 AM, Arnas Milaševičius wrote:
Hello,
First of all, I'm not sure if it's the right place to ask such a
question, but I'll try. I've started learning OpenGL and I really want
to contribute to Mesa project, but the way to do it had always been a
mistery for me. As a beginner
https://bugs.freedesktop.org/show_bug.cgi?id=65373
Priority: medium
Bug ID: 65373
Assignee: mesa-dev@lists.freedesktop.org
Summary: Rename the _mesa_lookup_enum_by_nr() function
Severity: trivial
Classification: Unclassified
On 31.05.2013 14:37, Vadim Girlin wrote:
There are no regressions on evergreen with piglit tests or any
other apps that I tested, with and without llvm backend.
(Issue with Unigine Heaven that I mentioned on #dri-devel
yesterday was in fact caused by my own well-hidden bug, now it's fixed).
https://bugs.freedesktop.org/show_bug.cgi?id=65374
Priority: medium
Bug ID: 65374
Assignee: mesa-dev@lists.freedesktop.org
Summary: Remove outdated version comments throughout Mesa
Severity: trivial
Classification: Unclassified
On 06/04/2013 11:40 AM, Andreas Boll wrote:
This patch unifies mesa's PACKAGE_VERSION on autotools, scons and
Android build systems.
Current behaviour is:
- Autotools uses 9.2.0 as PACKAGE_VERSION
- Scons and Android use 9.2-devel as PACKAGE_VERSION
With this patch all three build systems
Le 04/06/2013 21:54, Brian Paul a écrit :
On 06/04/2013 06:37 AM, Arnas Milaševičius wrote:
Hello,
First of all, I'm not sure if it's the right place to ask such a
question, but I'll try. I've started learning OpenGL and I really want
to contribute to Mesa project, but the way to do it had
On 06/04/2013 01:08 PM, Benjamin Bellec wrote:
Le 04/06/2013 21:54, Brian Paul a écrit :
On 06/04/2013 06:37 AM, Arnas Milaševičius wrote:
Hello,
First of all, I'm not sure if it's the right place to ask such a
question, but I'll try. I've started learning OpenGL and I really want
to
draw_vertex_buffer declared the size field to be a size_t, but the LLVM
code used an int32 instead. This caused problems on big-endian 64-bit
targets, because the first 32-bit chunk of the 64-bit size_t was always 0.
In one sense size_t seems like a good choice for a size, so one fix
would have
https://bugs.freedesktop.org/show_bug.cgi?id=65373
--- Comment #1 from Arnas giant...@gmail.com ---
I'm taking this task!
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=65376
Priority: medium
Bug ID: 65376
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] img_filter_3d_linear returns incorrect
results due to texture cache aliasing
https://bugs.freedesktop.org/show_bug.cgi?id=65376
Arseny Kapoulkine arseny.kapoulk...@gmail.com changed:
What|Removed |Added
Attachment #80309|text/plain |image/png
2013/6/4 Brian Paul bri...@vmware.com
On 06/04/2013 11:40 AM, Andreas Boll wrote:
This patch unifies mesa's PACKAGE_VERSION on autotools, scons and
Android build systems.
Current behaviour is:
- Autotools uses 9.2.0 as PACKAGE_VERSION
- Scons and Android use 9.2-devel as
On 04/06/13 21:42, Andreas Boll wrote:
2013/6/4 Brian Paul bri...@vmware.com
On 06/04/2013 11:40 AM, Andreas Boll wrote:
This patch unifies mesa's PACKAGE_VERSION on autotools, scons and
Android build systems.
Current behaviour is:
- Autotools uses 9.2.0 as PACKAGE_VERSION
- Scons
SSCALED/USCALED are integer which appear as float in shaders (e.g. as
a floating-point vertex shader input). Every type except UINT/SINT
appears as float in shaders and therefore can be used as a type of a
non-integer (=floating-point) vertex shader input, non-integer
sampler, and non-integer
btw, please ignore the 20/20 in the subject line :-) The patch was
tested in isolation and there aren't 19 other patches to come.
Richard
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I've fixed the first bug but I wonder what would be the right way to
submit this patch, because I needed to change like 100 or more files?
On Tue, Jun 4, 2013 at 11:16 PM, Brian Paul bri...@vmware.com wrote:
On 06/04/2013 01:08 PM, Benjamin Bellec wrote:
Le 04/06/2013 21:54, Brian Paul a
From: Roland Scheidegger srol...@vmware.com
We use 128bit vector interleave for untwiddling in the blend code (with
256bit vectors). llvm generates terrible code for this for some reason,
so instead of generating a shuffle for 2 128bit vectors use a
extract/insert shuffle instead (it only seems
When processing a buffer received from the X server,
intel_process_dri2_buffer() examines intel_region::name to determine
whether it's received a brand new buffer, or the same buffer it
received from the X server the last time it made a request.
However, this didn't work properly, because in the
Changes since the previous version:
- Because of objections, I've dropped the patch intel: Create
intel_miptree_get_region() to prepare for fast color clear.
Instead of using an accessor function to ensure that appropriate
resolves are performed before any access to
This patch includes code to update the fast color clear state
appropriately when rendering occurs. The state will also need to be
updated when a fast clear or a resolve operation is performed; those
state updates will be added when the fast clear and resolve operations
are added.
v2: Create a
On Gen7+, MCS buffers are used both for compressed multisampled color
buffers and for fast clear of single-sampled color buffers.
Previous to this patch series, we didn't support fast clear, so we
only used MCS with multisampled bolor buffers.
As a first step to implementing fast clears, this
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 119 +
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 9 ++
2 files changed, 128 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index
Since we defer allocation of the MCS miptree until the time of the
fast clear operation, this patch also implements creation of the MCS
miptree.
In addition, this patch adds the field
intel_mipmap_tree::fast_clear_color_value, which holds the most recent
fast color clear value, if any. We use it
The fragment shaders that to do color clears will be re-used to
perform so-called render target resolves (the resolves associated
with fast color clears). To prepare for that, this patch expands the
class hierarchy for blorp params by adding
brw_blorp_const_color_params (which will be used for
This patch implements the render target resolve blorp operation.
This will be needed when a buffer that has experienced a fast color
clear is later used for a purpose other than as a render target
(texturing, glReadPixels, or swapped to the screen). It resolves any
remaining deferred clear
We already had code in intel_downsample_for_dri2_flush() for
downsampling front and back buffers when multisampling was in use.
This patch extends that function to perform fast color clear resolves
when necessary.
To account for the additional functionality, the function is renamed
to simply
In certain circumstances the memory region underlying a miptree is
shared with other miptrees, or with other code outside Mesa's control.
This happens, for instance, when an extension like GL_OES_EGL_image or
GLX_EXT_texture_from_pixmap extension is used to associate a miptree
with an image
Resolve color buffers that have been fast-color cleared:
1. before texturing from the buffer (brw_predraw_resolve_buffers())
2. before using the buffer as the source in a blorp blit
(brw_blorp_blit_miptrees())
3. before mapping the buffer's miptree (intel_miptree_map_raw(),
This patch adds code to place mcs_state into INTEL_MCS_STATE_RESOLVED
for miptrees that are capable of supporting fast color clears. This
will have no effect on buffers that don't undergo a fast color clear;
however, for buffers that do undergo a fast color clear, an MCS
miptree will be allocated
https://bugs.freedesktop.org/show_bug.cgi?id=65376
--- Comment #1 from Roland Scheidegger srol...@vmware.com ---
I think this is all the same issue as bug #62922, #62482. This sort of aliasing
problem only got noticeable when we shrunk the cache size (probably was always
present just not
https://bugs.freedesktop.org/show_bug.cgi?id=65376
--- Comment #2 from Arseny Kapoulkine arseny.kapoulk...@gmail.com ---
My version of Mesa predates the change mentioned in these two bugs - i.e. my
number of texture tiles is actually 50, not 4. Note that in this case the hash
collision happens
Current implementation of ext_framebuffer_multisample_blit_scaled in
i965/blorp uses nearest filtering for multisample scaled blits. Using
nearest filtering produces blocky artifacts and negates the benefits
of MSAA. That is the reason why extension was not enabled on i965.
This patch implements
This patch enables ext_framebuffer_multisample_blit_scaled extension
on intel h/w = gen6.
Note: Patches for piglit tests to verify this functionality are out
for review on piglit mailing list. Tests pass for all of the scaling
factors from 0.1 to 2.4.
Comment from Paul Berry on my previous
+* - Compute avearge of samples 0 and 7 and leave the result in sample 0
Typo in `average`
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Patches 7-9 need to be reworked a little bit.
First, the dri and egl/dri2 commit have intermingled changes to the
intel driver. The changes to the intel driver should be pulled out into a
separate final commit.
Second, the commit subjects are imprecise and difficult to understand. If I
were to
On 05/28/2013 02:17 AM, Topi Pohjolainen wrote:
v2:
- upon success close the given file descriptors
v3:
- use specific entry for dma buffers instead of the basic for
primes, and enable the extension based on the availability
of the hook
v4 (Chad):
- use ARRAY_SIZE
-
Patches 1-5 are
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
I'm still looking at the other ones.
On 05/28/2013 02:17 AM, Topi Pohjolainen wrote:
Otherwise 'intel_set_texture_image_region()' won't have enough
details to work with.
Signed-off-by: Topi Pohjolainen
On 05/28/2013 02:17 AM, Topi Pohjolainen wrote:
No functional change in preparation for supporting multiple planes
per image each having its own region.
v2 (Chad): Clarify how valid regions are detected. Originally I
thought one could also support cases where one region
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
error on at least OpenBSD.
Problem originally noticed in libdrm by Mark Kettenis.
Dave Airlie pointed out that mesa has the same
65 matches
Mail list logo
