Am 12.12.2013 23:47, schrieb Aaron Watry:
Prevents a potential memory leak found when tracking down something else.
Patch is : Reviewed-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/vdpau/device.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Kenneth Graunke kenn...@whitecape.org writes:
On 11/26/2013 12:02 AM, Francisco Jerez wrote:
[snip]
+ add_image_function(imageLoad,
+ image_builtin_builder(*this)
+ .emit_stub(__intrinsic_image_load)
+ .has_return()
+
This is worse for SW renderers...
Jose
- Original Message -
From: Marek Olšák marek.ol...@amd.com
---
src/mesa/state_tracker/st_cb_clear.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_clear.c
Also move a comment that was in the wrong place.
---
src/gallium/drivers/radeonsi/si_state.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index d99cfe8..ee2372f 100644
---
It will only be worse for combined Z-stencil buffers if Z and
stencil are interleaved, and if SW rasterizers don't support any kind
of fast clear.
Marek
On Fri, Dec 13, 2013 at 3:21 PM, Jose Fonseca jfons...@vmware.com wrote:
This is worse for SW renderers...
Jose
- Original Message
What you mean by fast clear?
llvmpipe depth-stencil buffers are interleaved, and AFAICT partial clears will
be done with quads. In other words, this will make llvmpipe slower.
In truth, this will all drivers with interleaved z/s bufferss slower. That is,
this is optimizing for some drivers
HiS might be useful for anything that uses id Tech 4, like Doom 3,
ETQW, etc. I'm not sure about later chips, but R300-R500 has to
disable HiZ entirely if certain stencil operations are used.
Marek
On Fri, Dec 13, 2013 at 4:58 PM, Andreas Hartmetz ahartm...@gmail.com wrote:
Also move a comment
Hi Chris,
How goes arb_texture_view?
I'd like to see what you have. Please let me know if I can help.
Thanks,
Courtney
On Mon, Nov 25, 2013 at 1:42 PM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
I've added a viewport_array-rc2 branch to my github repository with
updates from the
On Thu, Dec 12, 2013 at 01:26:36AM -0800, Kenneth Graunke wrote:
The PIPE_CONTROL packet actually has 5 DWords on Gen6+:
1. Header
2. Flags
3. Address
4. Immediate Data: Lower DWord
5. Immediate Data: Upper DWord
We just never emitted the last one. While it appears to work, it's
On Thu, Dec 12, 2013 at 01:26:37AM -0800, Kenneth Graunke wrote:
The kernel doesn't even set up the aliasing PPGTT on Sandybridge, so any
writes marked as PPGTT will likely just get dropped on the floor.
Ermh, aliasing ppgtt is enabled on snb. But the CS write stuff is broken
and will always
On Thu, Dec 12, 2013 at 01:26:38AM -0800, Kenneth Graunke wrote:
I believe that PIPE_CONTROL uses the length field to decide whether to
do 32-bit or 64-bit writes. A length of 4 would do a 32-bit write,
while a length of 5 would do a 64-bit write. (I haven't verified this,
though.)
For
On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
and the second DWord is the high 16 bits.
Since individual buffers shouldn't be larger than 4GB in size, any
offsets into those buffers (buffer-offset +
On 12/13/2013 09:28 AM, Daniel Vetter wrote:
On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
and the second DWord is the high 16 bits.
Since individual buffers shouldn't be larger than 4GB in size, any
From: Roland Scheidegger srol...@vmware.com
Didn't really work as well as hoped (in particular it was not generally
more accurate), will solve this differently.
---
src/gallium/drivers/llvmpipe/lp_state_setup.c | 70 ++---
1 file changed, 4 insertions(+), 66 deletions(-)
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Didn't really work as well as hoped (in particular it was not generally
more accurate), will solve this differently.
---
src/gallium/drivers/llvmpipe/lp_state_setup.c | 70
++---
1 file
I agree that this seems to be pretty bad if you have interleaved
depth/stencil buffers (and no way to fast-clear them independently),
though I wonder which apps actually hit this? It looks to me like the
conditions you'd hit quad clear with one of depth/stencil but normal
clear with the other are
I got it sort of running on Jenkins, on the master branch.
I can't have it build all the way through, because I'm a bit worried it'll
try to overwrite my currently installed version of Mesa on my system.
But it does tell me :
Run 'make' to build Mesa
Finished: SUCCESS
I'm guessing tests have
I'll add a cap then.
The fast clear is a technique that doesn't actually clear memory.
Instead, it postpones clearing until later time in hope that the
cleared area will be overdrawn anyway and no clearing will have to be
done. The idea is to have a clear/non-cleared 1-bit flag per tile.
Instead
This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full miptrees where were found to be common activities
in the Smokin' Guns game. The issue was found while profiling the app
but that part is
MESA_FORMAT_XRGB is equivalent to MESA_FORMAT_ARGB in terms
of storage on the device, so okay to use this optimized copy routine.
This series builds on work from Frank Henigman to optimize the
process of uploading a texture to the GPU. This series adds support for
MESA_XRGB_ and full
Support all levels of a supported texture format.
Using 1024x1024, RGBA source, mipmap
internal-format Before (MB/sec) mipmap (MB/sec)
GL_RGBA 627.15 615.90
GL_RGB 456.35 611.53
512x512
GL_RGBA 597.00 619.95
GL_RGB 440.62
https://bugs.freedesktop.org/show_bug.cgi?id=72582
--- Comment #1 from Ian Romanick i...@freedesktop.org ---
I haven't look at this test (and for some reason it doesn't show up in my
piglit runs), but I suspect this is the same issue at the copyteximage test.
copyteximage tries to use array
From: Roland Scheidegger srol...@vmware.com
The argument is a i8 pointer not a i32 pointer (even though the value actually
stored/loaded IS i32). Older llvm versions didn't care but 3.2 and newer do
leading to crashes.
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c |9 +++--
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=72582
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Just use the gl_texture_object::_IsInteger field instead of
computing it from scratch.
---
src/mesa/state_tracker/st_atom_sampler.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_sampler.c
b/src/mesa/state_tracker/st_atom_sampler.c
---
src/mesa/state_tracker/st_format.c |6 +++---
src/mesa/state_tracker/st_format.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index ec25523..6acf983 100644
---
---
src/mesa/state_tracker/st_atom_sampler.c |6 +++---
src/mesa/state_tracker/st_texture.h |6 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_sampler.c
b/src/mesa/state_tracker/st_atom_sampler.c
index 989e42c..447788c 100644
---
The GL_ARB_shadow spec says the shadow compare mode should have no
effect when sampling a color texture. As it was, it was up to
drivers to check for that (softpipe, llvmpipe, svga and probably
the rest don't do that). Note: it looks like DX10 allows shadow
compare with some non-depth formats,
https://bugs.freedesktop.org/show_bug.cgi?id=72600
--- Comment #10 from Ian Romanick i...@freedesktop.org ---
OpenGL ES 3.0 is intended to be almost completely backwards compatible with
OpenGL ES 2.0. The only known incompatibilities are cubemap filtering (ES3
requires seamless filtering, but
https://bugs.freedesktop.org/show_bug.cgi?id=72600
--- Comment #11 from org.freedesk...@io7m.com ---
Yes, those are the conclusions I came to as well.
The only issue here, then, is the minor irritation of the ES3 context not
setting
EGL_OPENGL_ES3_BIT_KHR. I think that's a conformance issue but
Looks good. Thanks Roland!
- Original Message -
From: Roland Scheidegger srol...@vmware.com
The argument is a i8 pointer not a i32 pointer (even though the value
actually
stored/loaded IS i32). Older llvm versions didn't care but 3.2 and newer do
leading to crashes.
---
https://bugs.freedesktop.org/show_bug.cgi?id=72600
--- Comment #12 from Jordan Justen jljus...@gmail.com ---
(In reply to comment #11)
The only issue here, then, is the minor irritation of
the ES3 context not setting EGL_OPENGL_ES3_BIT_KHR.
I think that's a conformance issue but I doubt
Am 13.12.2013 21:32, schrieb Brian Paul:
The GL_ARB_shadow spec says the shadow compare mode should have no
effect when sampling a color texture. As it was, it was up to
drivers to check for that (softpipe, llvmpipe, svga and probably
the rest don't do that). Note: it looks like DX10 allows
I tried to tackle this issue:
There is still the issue regarding the following:
According to the spec, it should be possible to clear some part of a
buffer, even if a different, non-overlapping part is mapped, this is
currently not possible. It was suggested to implement ClearBufferSubData
On 12/12/2013 01:56 PM, Brian Paul wrote:
---
include/GL/glext.h | 68
++--
1 file changed, 61 insertions(+), 7 deletions(-)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index fea9e1f..7d6033e 100644
--- a/include/GL/glext.h
+++
On Fri, Dec 13, 2013 at 10:04:53AM -0800, Kenneth Graunke wrote:
On 12/13/2013 09:28 AM, Daniel Vetter wrote:
On Thu, Dec 12, 2013 at 01:26:40AM -0800, Kenneth Graunke wrote:
Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
and the second DWord is the high 16 bits.
On 11/21/2013 08:12 PM, Keith Packard wrote:
The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
On 11/25/2013 09:35 PM, Keith Packard wrote:
Move the depth field up with width and height.
Remove unused previous_time and frames fields.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/glx/dri3_priv.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
---
src/mesa/drivers/dri/swrast/swrast.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/swrast/swrast.c
b/src/mesa/drivers/dri/swrast/swrast.c
index cfa9316..79a2740 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++
---
src/gallium/state_trackers/dri/sw/drisw.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/dri/sw/drisw.c
b/src/gallium/state_trackers/dri/sw/drisw.c
index 64a64af..6f50b05 100644
--- a/src/gallium/state_trackers/dri/sw/drisw.c
+++
On 12/13/2013 03:17 PM, Pi Tabred wrote:
I tried to tackle this issue:
There is still the issue regarding the following:
According to the spec, it should be possible to clear some part of a
buffer, even if a different, non-overlapping part is mapped, this is
currently not possible. It was
Kenneth Graunke kenn...@whitecape.org writes:
I see that Eric reviewed it, and that it has not landed. Are there any
objections to merging it?
They're on top of a series of DRI3/Present patches, not all of which
have seen review. I was hoping the rest of that series would get
reviewed so that
These are the same address, but different types and driContextSetFlags wants
a gl_context pointer.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/mesa/drivers/dri/swrast/swrast.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/swrast/swrast.c
These are duplicates from gl.h; I'm not sure which file they belong in, but
you don't get to have them in both places.
Signed-off-by: Keith Packard kei...@keithp.com
---
include/GL/glext.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index
It is the maximum number of back buffers, but the name is confusing and is
easily read as the maximum back buffer index. Chage to DRI3_NUM_BACK to make
the intended usage a bit clearer.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/glx/dri3_glx.c | 4 ++--
src/glx/dri3_priv.h | 10
This series has a bunch of DRI3 cleanups and fixes followed by a few patches
that finish up DRI3 support in gallium.
The first two patches have nothing to do with DRI3, just some warning fixes:
[PATCH 01/18] Remove glBlendColor and glBlendEquations decls from
[PATCH 02/18] dri/swrast: Passing
Tracking the full 64-bit SBC values makes it clearer how those values are
being used, and simplifies the wait_msc code. The only trick is in
re-constructing the full 64-bit value from Present's 32-bit serial number that
we use to pass the SBC value from request to event.
Signed-off-by: Keith
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac | 8 -
src/glx/dri3_common.c | 85 ++-
2
Now that we're tracking SBC values correctly, and the X server has the ability
to send the GLX swap events from a PresentPixmap request, enable this extension.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/glx/dri3_glx.c | 18 +-
1 file changed, 1 insertion(+), 17
XCB doesn't flush the output buffer automatically, so we have to call
xcb_flush ourselves before waiting.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/glx/dri3_glx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index c26d6e5..7982f6b
Move the depth field up with width and height.
Remove unused previous_time and frames fields.
Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
---
src/glx/dri3_priv.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
Just copying code from the dri2 path to set up the fast color clear state.
This also removes a couple of bogus intel_region_reference calls.
Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Eric Anholt e...@anholt.net
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 +++---
Eric figured out that glXWaitForSbcOML wanted to block until the requested SBC
had been completed, which means to wait until the PresentCompleteNotify event
for that SBC had been received.
This replaces the simple sleep(1) loop (which was bogus) with a loop that just
checks to see if we've seen
The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
__DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
From: Ben Skeggs bske...@redhat.com
Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Keith Packard kei...@keithp.com
---
src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Ben Skeggs bske...@redhat.com
Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Keith Packard kei...@keithp.com
---
src/gallium/state_trackers/dri/drm/dri2.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
Upper levels of the stack use base.stamp to tell when a drawable needs to be
revalidated, but the dri state tracker was using dPriv-lastStamp. Those two,
along with dri2.stamp, all get simultaneously incremented when a dri2
invalidate event was delivered, and so end up containing precisely the
libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which
works when the fence is a linux futex. However, version 1.1
changes the exported datatype to 'struct xshmfence *'
Require libxshmfence version 1.1 and switch the API around.
Signed-off-by: Keith Packard kei...@keithp.com
---
Always nice to clean up after ourselves.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/glx/dri3_glx.c | 17 -
src/glx/dri3_priv.h | 5 -
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 1834c6d..4c0dc29
The buffer-object is the persistent thing passed through the loader, so when
updating an image buffer, check to see if it is already bound to the provided
bo. The region, on the other hand, is allocated separately for the miptree,
and so will never be the same as that passed back from the loader.
Provide the hook to pull textures out of __DRIimage structures and use them as
renderbuffers.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/gallium/state_trackers/dri/drm/dri2.c | 238 +-
1 file changed, 230 insertions(+), 8 deletions(-)
diff --git
On 12/13/2013 05:25 PM, Keith Packard wrote:
These are duplicates from gl.h; I'm not sure which file they belong in, but
you don't get to have them in both places.
Signed-off-by: Keith Packard kei...@keithp.com
---
include/GL/glext.h | 2 --
1 file changed, 2 deletions(-)
diff --git
On 11/18/2013 12:58 PM, Emil Velikov wrote:
On 18/11/13 01:08, Keith Packard wrote:
libudev doesn't have a stable API/ABI, and if the application wants to use
one
version, we'd best not load another into libGL.
Signed-off-by: Keith Packard kei...@keithp.com
---
Hi Keith,
Did you had
On 12/13/2013 05:25 PM, Keith Packard wrote:
libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which
works when the fence is a linux futex. However, version 1.1
changes the exported datatype to 'struct xshmfence *'
Require libxshmfence version 1.1 and switch the API around.
None of the other 3-component 16bpc formats are directly supported, so
they get promoted to XRGB equivalents. *Not* promoting RGB16F the same
way makes texture views much more fiddly -- we don't want to have to do
crazy copying behind the scenes.
(with my other master + my experimental
Kenneth Graunke kenn...@whitecape.org writes:
NAK. These headers come directly from Khronos; we need to somehow get
this fixed upstream and take their version.
Until they're fixed upstream, we should fix them when incorporating them
into the repository. Having broken headers in our code just
Kenneth Graunke kenn...@whitecape.org writes:
Would be great to line these comments up.
Fixed.
Patches 2 and 4-6 are:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Review marked. Thanks much!
--
keith.pack...@intel.com
pgpkJlR4qfmew.pgp
Description: PGP signature
67 matches
Mail list logo
