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 i
Patches 1-5 are
Reviewed-by: Chad Versace
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
---
src/mesa/drivers/dri/intel/intel_screen.c
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
i
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 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
+* - 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
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 imple
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 t
https://bugs.freedesktop.org/show_bug.cgi?id=65376
--- Comment #2 from Arseny Kapoulkine ---
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 before doing the % NUM_ENTRIES
https://bugs.freedesktop.org/show_bug.cgi?id=65376
--- Comment #1 from Roland Scheidegger ---
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 visible). I guess we're mis
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
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(),
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 existin
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 intel
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 opera
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 a
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 t
---
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 60166
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 p
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 new
This patch ifdefs out intel_mipmap_tree::mcs_mt when building the i915
(pre-Gen4) driver (MCS buffers aren't supported until Gen7, so there
is no need for this field in the i915 driver). This should make it a
bit easier to implement fast color clears without undue risk to i915.
---
src/mesa/drive
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
intel_mipmap_tree::re
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 c
From: Roland Scheidegger
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 to matter we're not
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 wrote:
> On 06/04/2013 01:08 PM, Benjamin Bellec wrote:
>
>> Le 04/06/2013 21:54, Brian Paul a écrit :
>>
>>>
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
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 rende
On 04/06/13 21:42, Andreas Boll wrote:
> 2013/6/4 Brian Paul
>
>> 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
>>> - S
2013/6/4 Brian Paul
> 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
>
https://bugs.freedesktop.org/show_bug.cgi?id=65376
Arseny Kapoulkine changed:
What|Removed |Added
Attachment #80309|text/plain |image/png
mime type|
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
Sever
https://bugs.freedesktop.org/show_bug.cgi?id=65373
--- Comment #1 from Arnas ---
I'm taking this task!
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.free
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 b
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 contribut
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 d
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 u
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 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).
Impr
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 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 con
Brian Paul 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 MAX_PROGRAM_ADDRESS_REGS
> si
https://bugs.freedesktop.org/show_bug.cgi?id=65226
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
- 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 MAX_PROGRAM_ADDRES
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.
---
Android
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 supp
https://bugs.freedesktop.org/show_bug.cgi?id=65226
--- Comment #1 from Brian Paul ---
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 receiving this mail be
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 t
Am 04.06.2013 14:38, schrieb Jose Fonseca:
>
>
> - Original Message -
>> From: Roland Scheidegger
>>
>> 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 +++
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 should
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
---
configure.ac | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --g
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
- Original Message -
> From: Roland Scheidegger
>
> 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 deletion(-)
https://bugs.freedesktop.org/show_bug.cgi?id=61919
--- Comment #7 from Darxus ---
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.
__
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 thou
- Original Message -
> Jose Fonseca writes:
> >> Yeah, that's what the patch was trying to do. Even though the formats
> >> were defined as "int"s, the int layout was extra information on top of
> >> what's already there. The int information didn't change or replace the
> >> array inform
- Original Message -
> On Die, 2013-06-04 at 01:15 -0700, Jose Fonseca wrote:
> > - Original Message -
> > > Michel Dänzer writes:
> > > > On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
> > > >>
> > > >> I agree that with non-array formats, like B5G6R5 and R5G6B5, replac
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
> +==
> +
>
On 3 June 2013 22:16, Kenneth Graunke 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
> synchronization, doesn't
Jose Fonseca writes:
>> Yeah, that's what the patch was trying to do. Even though the formats
>> were defined as "int"s, 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 the a
From: Mike Stroyan
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 instead of using ga
- Original Message -
> - Original Message -
> > Michel Dänzer 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 o
On Die, 2013-06-04 at 01:15 -0700, Jose Fonseca wrote:
> - Original Message -
> > Michel Dänzer 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 -
> Michel Dänzer 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 will p
https://bugs.freedesktop.org/show_bug.cgi?id=61919
--- Comment #6 from Quentin Glidic ---
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 receiving this mail because:
You are
64 matches
Mail list logo
