El dj 03 de 02 de 2011 a les 03:15 +0100, en/na Daniel va escriure:
> Hi people,
>
> Is it at all possible to run Wayland using an Intel 82865G integrated
> card?
Sorry, wrong list.
___
mesa-dev mailing list
mesa-dev@lists.freedesk
Hi people,
Is it at all possible to run Wayland using an Intel 82865G integrated
card?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
C; if that could be put in now, that would be great.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
promos
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
On 14 July 2015 at 02:21, Brian Paul wrote:
> +
> +
> +
Surely texture rather than program?
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
rom 584 years to 292 years - likely not a big deal.
>
> which doesn't make sense. If we feel like we need to point out that
> we've fixed the bug, that's fine, but keep the part about how some
> kernels are broken so it's clear why the workaround is needed.
That fi
te but I think we can live with it. Would like to
> see if Matt/other have objections against this, but as-is
I'd suggest using "RM ?= rm -f", but obviously that doesn't work on
non-GNU make either ...
Cheers,
Daniel
___
use of it and in the process fix my reversed
> > detection of the buggy reads for unpatched kernels.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Martin Peres
> > Cc: Kenneth Graunke
> > Cc: Michał Winiarski
> > Cc: Daniel Vetter
> > ---
> >
>>
> >
> > Sure, attached is the hang I get if I don't set the restriction in
> > gen8_misc_state.c and try to use the full 48-bit range
> > (i915_error_state_nowa.txt). This is just running gfxbench t-rex.
> >
> > I see the same hang signature when it is only applied to the scratch bos (in
> > gen8_vs_state.c, gen8_gs_state.c and gen8_ps_state.c -
> > i915_error_state_scratchbo.txt).
> >
> > 3DSTATE_VIEWPORT_STATE_POINTERS_CC (0x7823) is defined here:
> > https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-bdw-vol02a-commandreference-instructions_0.pdf
> > (page 256)
>
> I applied your mesa and libdrm patches and then backed out the 4G
> restriction in the STATE_BASE_ADDRESS relocations. I was not able to
> reproduce any hang with trex or glxgears. I confirmed (using
> INTEL_DEBUG=bat) that gem actually placed BOs above the 4G mark and
> got this:
>
> 0: 8 @ 0xfff9 (miptree)
> 1: 9 @ 0xfff78000 (hiz)
> 2: 4 @ 0xfff77000 (pipe_control workaround)
> 3: 5 @ 0xfff76000 (program cache)
> 4: 12 @ 0x (miptree)
> 5: 7 @ 0x1000 (image)
> 6: 10 @ 0xfff5a000 (miptree)
> 7: 13 @ 0xfff59000 (bufferobj)
> 8: 11 @ 0xfff51000 (bufferobj)
> 9: 14 @ 0xfff5 (bufferobj)
> 10: 15 @ 0xfff4 (batchbuffer)@0x 0020 -> 8
> (miptree)@0x fff9 + 0x
> 10: 15 @ 0xfff4 (batchbuffer)@0x 0040 -> 9
> (hiz)@0x fff78000 + 0x
> 10: 15 @ 0xfff4 (batchbuffer)@0x 0098 -> 4
> (pipe_control workaround)@0x fff77000 + 0x
> ...
>
> In particular, the mesa batchbuffer is placed at 0xfff4, and
> all the STATE_BASE_ADDRESS heaps are in that bo. In other words, all
> heap bases are set to 0xfff4.
>
> The offset in 3DSTATE_VIEWPORT_STATE_POINTERS_CC is indeed only 32
> bits, but that only affects how far from the dynamic state base
> address we can place that. In mesas case, it's always inside the batch
> buffer, which is at most 32k, so that's never a problem. If a driver
> uses dynamic state in a heapless fashion, then you need to be careful
> to place the CC viewport state below 4g.
>
> What I was able to confirm is that scratch buffer I/O (which we use
> for spilling) does break with 48 bit ppgtt. If you run glxgears with
> INTEL_DEBUG=spill_fs set, you can see lots of rendering artifacts as
> the 4G limit on the general state heap caps attempts to spill and fill
> from the vertex shader. Using OUT_RELOC64_INSIDE_4G() when setting up
> the scratch BOs in 3DSTATE_VS and 3DSTATE_PS fixes the problem.
Ok, so we do still need the 4G limit bit (i.e. I don't have to revert the
kernel side for lack of open-source userspace), just not at the place we
originally thought. I guess lesson learned is to actually test stuff first
before I pull in the kernel side. Michel, did you not see the spilling
corruptions when testing the mesa patches? Kristian, does this also blow
up with just a piglit run?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
about that.
Please send in your proposal to bo...@foundation.x.org latest by 28th
Oct to make sure the baord can consider it.
Thanks,
Daniel, secretary of the board
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffw
onstant GTT size as it also computes addition information not
> used here and has the side-effect of doing a sysfs scan for PCI
> devices.)
>
> Signed-off-by: Chris Wilson
Since I just pulled in the kernel side earlier today:
Reviewed-by: Daniel Vetter
> Cc: Daniel Vetter
>
d treating tiling as some magic driver-specific thing, using
DRM format modifiers during the import allows you to do tiling import
correctly the first time, including a full validation of the
applicable restrictions.
Thanks a lot for your work and all the thoughtful comments here. This
has been a pain point for a while now, though atomic modesetting and
other work within Wayland/Weston itself have more pressing, so I
haven't been able to expend much any time on it. I'm really glad to
see someone having picked this up though, and if done properly,
everyone with an ARM or a multi-GPU system will thank you. :)
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
I know this isn't your fault, but I really really don't see any reason
why the vl winsys bits should continue to exist. We already have a
winsys/presentation layer in Mesa ...
Cheers,
Daniel
On 29 October 2015 at 17:40, Julien Isorce wrote:
> This patch allows to use gallium
ying the existing internal EGL platform API to be able to use it
from vl_*, rather than straight reuse. DItto for gbm if there's
anything useful in there that could use the same codepaths.
Cheers,
Daniel
> Cheers
> Julien
>
>
> On 30 October 2015 at 08:47, Daniel Stone wrote:
>&
d comment again to clarify NO_RELOC case (Chris). checkpatch cleanup.
> > >
> > > v6: Rebase on top of current nightly. Dropped any references to
> > > EXEC_OBJECT_SUPPORTS_48BBADDRESS since those don't exist in
> > upstream
> > > yet, and are not a depend
ys sending full-surface damage.
bce64c6c provides the explanation for why we send maximum-range damage,
rather than the full size of the surface: in the presence of buffer
transformations, full-surface damage may not actually cover the entire
surface.
Signed-off-by: Daniel Stone
Cc: Jasper
; pushed now as d1314de.
Emil, this would make a good stable candidate.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
l seem to be pretty unstable and break a bunch of
stuff, and buffer_age is definitely a useful optimisation for non-TBDR
platforms, so I don't see why not.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
t;
Shouldn't this contain the modifier(s) as well?
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
On 3 March 2015 at 18:40, Chad Versace wrote:
> On 03/03/2015 12:13 AM, Daniel Stone wrote:
>> On Tuesday, March 3, 2015, Dave Airlie > <mailto:airl...@gmail.com>> wrote:
>> +EGLBoolean eglExportDMABUFIm
t - a change which was deemed totally
fine to enforce on people because it improved performance and matched
the spec.
Perhaps a better interim solution is to assume for Wayland that
EGL_TRANSPARENT_TYPE == EGL_DONT_CARE means that applications will get
a format determined by ALPHA_SIZE (i.e. size 8 means AR
ntations, I'm not really sure that I want
to leave them to chance another, much less standard, spec, which has
less of a precedent around it.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
tion to make informed calls about when to throttle and how.
So is there no gl entry point in mesa we can abuse and make this happen?
Citing the spec doesn't make the real world issue go away.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ff
think it's probably ok either way.
>>
>
> The biggest problem is if I change it (see hunk below) is that it
> potentially
> doesn't match the old behavior, and I don't really have a great way to test
> this
> outside of our environment. I went with the
; image
>> doesn't support linear. As a result, you are correct. I think for this case,
>> the
>> client can handle it pretty easily, and returning INVALID is the right
>> thing to do.
>>
>> Daniel, are you okay with changing this to return DRM_FORMAT
rs support, so you
can both import buffers with modifiers, as well as query the
implementation for which formats/modifiers it supports.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
mats would fail with an
error.
Signed-off-by: Daniel Stone
Cc: Emil Velikov
Cc: mesa-sta...@lists.freedesktop.org
Fixes: cb5e799448 ("egl/wayland: unify dri2_wl_create_surface implementations")
---
src/egl/drivers/dri2/platform_wayland.c | 21 ++---
1 file changed,
Hey,
On 13 February 2017 at 17:27, Emil Velikov wrote:
> On 13 February 2017 at 14:06, Daniel Stone wrote:
>> static EGLBoolean
>> dri2_wl_swrast_allocate_buffer(struct dri2_egl_display *dri2_dpy,
>> - int
Hi,
On 13 February 2017 at 17:49, Emil Velikov wrote:
> On 13 February 2017 at 17:34, Daniel Stone wrote:
>> On 13 February 2017 at 17:27, Emil Velikov wrote:
>>> Wouldn't it be better to have this in dri2_wl_create_window_surface() ?
>>> As-is we're passi
---
ARB_dsa / GL 4.5 add indexed GL_TEXTURE_BINDING_* and GL_SAMPLER_BINDING
queries, as well as a GL_TEXTURE_TARGET query on texture objects.
The implementation for the GL_TEXTURE_BINDING_* and GL_SAMPLER_BINDING
queries is based on their non-indexed variants. To map the binding enum
to a textur
Ping.
Can someone please review and/or commit this.
I noticed ARB_dsa is already exposed in Mesa 10.6 - should this patch be Cc'd
to that?
--
Daniel
On 2015-07-25 08:12, Daniel Scharrer wrote:
> ---
>
> ARB_dsa / GL 4.5 add indexed GL_TEXTURE_BINDING_* and GL_SAMPLER_BINDING
Hi,
thanks for looking at this.
On 2015-08-03 16:18, Brian Paul wrote:
> On 08/03/2015 06:01 AM, Daniel Scharrer wrote:
>> Ping.
>>
>> Can someone please review and/or commit this.
>>
>> I noticed ARB_dsa is already exposed in Mesa 10.6 - should this patch b
CC: "10.6"
---
v2: added CC for 10.6
renamed _mesa_tex_target_to_index to tex_target_to_index
moved declaration of variable before code
added missing spaces in ternary operators
src/mesa/main/get.c | 93
src/mesa/main/texparam.c
y add stalls on old kernels.
Note that read-read has only landed in 4.2, hence we might want to hold
off on this one a bit until most distros have upgraded to this ;-)
-Daniel
>
> Signed-off-by: Chris Wilson
> ---
> src/mesa/drivers/dri/i965/intel_buffer_objects.c | 12 --
On 2015-08-06 15:46, Brian Paul wrote:
> On 08/06/2015 07:44 AM, Daniel Scharrer wrote:
>> CC: "10.6"
>>
>> ---
>>
>> v2: added CC for 10.6
>> renamed _mesa_tex_target_to_index to tex_target_to_index
>> moved declaration of varia
On 2015-08-12 17:14, Brian Paul wrote:
> Another question below...
>
> On 08/12/2015 08:31 AM, Daniel Scharrer wrote:
>> On 2015-08-06 15:46, Brian Paul wrote:
>>> On 08/06/2015 07:44 AM, Daniel Scharrer wrote:
>>>> CC: "10.6"
>>>>
&
Hi,
On 2015-08-12 18:05, Fredrik Höglund wrote:
> On Thursday 06 August 2015, Daniel Scharrer wrote:
>> CC: "10.6"
>
> I think the commit message should say which queries are added.
>
>>
>> ---
>>
>> v2: added CC for 10.6
>>
If the sampler object has been deleted in the same context the binding
will have been cleared. If it has been deleted in another context, the
spec does not say what should returned. None of the other binding point
queries check for deletion in another context.
Also, as names of deleted objects are
This adds index queries (glGet*i_v) for GL_TEXTURE_BINDING_* and
GL_SAMPLER_BINDING, as well as textue queries
(glGetTex{,ture}Parameter*) for GL_TEXTURE_TARGET.
CC: "10.6"
---
v3: fixed uper limit for texture units
don't use extension suffixes for core tokens
mention added queries in com
This adds index queries (glGet*i_v) for GL_TEXTURE_BINDING_* and
GL_SAMPLER_BINDING, as well as textue queries
(glGetTex{,ture}Parameter*) for GL_TEXTURE_TARGET.
CC: "10.6 11.0"
---
v4: fixed trivial merge conflict in texparam.c
added 11.0 to stable tag
v3: fixed uper limit for texture units
If the sampler object has been deleted in the same context the binding
will have been cleared. If it has been deleted in another context, the
spec does not say what should returned. None of the other binding point
queries check for deletion in another context.
Also, as names of deleted objects are
On 16 September 2016 at 18:02, Emil Velikov wrote:
> Introduce a helper and use it throughout the platform code. This allows
> us to reduce the amount of ifdef(s) and (potentially) use
> kms_swrast_dri.so for !drm platforms (namely wayland and x11).
Reviewed-by: Dan
ainst older OpenGL versions.
Maybe Mesa should limit the context version to the one requested by the
application. The blob drivers seem to do this (at least the AMD one) and the
current behaviour has already caused problems before:
https://bugs.freedesktop.org/show_bug.cgi?id=95374
--
Da
roy(dri2_dpy->wl_queue);
> cleanup_dpy:
> free(dri2_dpy);
Adding wl_display_disconnect should be a separate change, and in any
case needs to come after wl_event_queue_destroy to avoid a
use-after-free.
With those fixed, assuming we're fine with an increased har
This was first fixed in commit b3f9c5c and then broken again in commit
fe2d2c7, which removed the abs modifier from input registers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91342
Signed-off-by: Daniel Scharrer
Cc: "12.0"
---
src/mesa/main/ffvertex_prog.c | 14 ++-
This was first fixed in commit b3f9c5c and then broken again in commit
fe2d2c7, which removed the abs modifier from input registers.
v2: Don't change the size of struct ureg.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91342
Signed-off-by: Daniel Scharrer
Cc: "12.0"
On 2016-08-14 06:38, Matt Turner wrote:
> On Sat, Aug 13, 2016 at 5:07 PM, Daniel Scharrer wrote:
>> This was first fixed in commit b3f9c5c and then broken again in commit
>> fe2d2c7, which removed the abs modifier from input registers.
>>
>> Bugzilla: https://bugs.free
t/gregkh/staging.git/
This seems to be patches against igt (but the series is lacking the i-g-t-
subject tag per CONTRIBUTING). I'm ok with that, but I thought the idea
was to merge these testcases into the kernel's selftests? Did the plan
change?
-Daniel
>
> Robert Foss (
On Wed, Aug 24, 2016 at 04:41:02PM -0400, Gustavo Padovan wrote:
> 2016-08-24 Daniel Vetter :
>
> > On Tue, Aug 23, 2016 at 01:56:02PM -0400, robert.f...@collabora.com wrote:
> > > From: Robert Foss
> > >
> > > This series implements the sw_sync test and
915_PARAM_MMAP_GTT_VERSION:
> + /* 0 - Objects have to be smaller than aperture,
> + * all simultaneous users have to fit within the
> + * available space within the aperture.
> + * 1 - Objec
the mappable aperture.
>
> Signed-off-by: Chris Wilson
> Cc: Kenneth Graunke
Reviewed-by: Daniel Vetter
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 17 ++---
> src/mesa/drivers/dri/i965/brw_context.h | 2 +-
> src/mesa/dri
nly report now, but unless the world has switched to
requiring get_all_proc_addresses, it'll break a hell of a lot more.
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
: much like Jonas's fix for
wayland-egl, all the Wayland objects created by the WSI _must_ use a
separate event queue.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
erate on a Minnowboard, due to spending a great deal of
its time attempting to query the age of the next buffer before redraw.
Revert to the previous behaviour of allowing rendering to begin but
delaying SwapBuffers, unless and until we can find a more gentle
behaviour.
Signed-off-by: Daniel Stone
ts its own copy, and the share group gets a copy.
> Writes to state go to both the local copy and the shared copy. Reads
> come only from the local copy. glBindTexture updates the local copy
> from the shared copy. The local copies are basically a write-through
> cache. I'm not sur
arguably the feature
> it exposes currently provides broken counter data without Rob's work.
> But the others...you're not going to remove.
>
> If you start taking away features, the version getparam is entirely
> meaningless. We can't infer anything from it, an
ed by default on
> all kernel versions exposing cmd_parser_version >= 2? Wouldn't this
> break things if the command parser is disabled in the kernel command
> line? [Currently it would just cause some extensions to be disabled]
We have the stance that touching an
On 24 October 2016 at 20:42, Daniel Stone wrote:
> This reverts commit 25cc889004aad6d1cab9edd76db898658e347b97, though
> since the code has changed, it was applied manually.
>
> The intent of moving blocking from SwapBuffers to get_back_bo, was to
> avoid unnecessary triple-buffer
Hi,
On 10 November 2016 at 06:08, Jonas Ådahl wrote:
> On Mon, Oct 24, 2016 at 08:42:59PM +0100, Daniel Stone wrote:
>> The intent of moving blocking from SwapBuffers to get_back_bo, was to
>> avoid unnecessary triple-buffering by ensuring that the compositor had
>> fully p
a changes from
frame to frame. I do not believe that this is a common case, and even if it
were, the downside of this is not as bad as the downside of picking the
youngest.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
estroy/resize/ ... ? The patch itself looks fine, but I don't
really see how the description relates.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
t, resize_callback is essentially a no-op:
the flush extension doesn't exist for swrast, so resize_callback will
explode if ever called on swrast. Does this mean that 1/3 is generally
wrong, and needs to set destroy_window_callback rather than
resize_callback instead?
Cheers,
Daniel
__
me callback in
> get_back_bo not dri2_swap_buffers"")
> Cc: Daniel Stone
> Signed-off-by: Emil Velikov
Not sure how I missed this; apologies. Pushed now with my R-b.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop
This fixes a NULL pointer dereference for intrinsics with more than
one function attribute introduced in commit 2fdaf38.
The fix is ported from the lp_build_intrinsic changes in commit 8bdd52c.
---
I'm a bit unsure about the index change from 0 to -1, but the gallium code does
this as well and wit
r / attr_to_str that catches this.
> Either way, this patch is
> Reviewed-by: Bas Nieuwenhuizen
Thanks. I don't have commit access so I'll need someone else to push it.
> On Fri, Nov 11, 2016 at 9:36 PM, Daniel Scharrer wrote:
>> This fixes a NULL pointer dereference
On Sat, Nov 12, 2016 at 3:01 PM, Rob Clark wrote:
> On Sat, Nov 12, 2016 at 8:30 AM, Daniel Vetter wrote:
>> On Fri, Nov 11, 2016 at 05:57:54PM +0100, Wladimir J. van der Laan wrote:
>>> Vivante GPUs with HALTI0 feature support a DRAW_INSTANCED command in the
>>> comm
uld never reach here, since the extension should be
> advertised only if the API is available.
>use new API
> else
>use old API
Actually, present-and-zero modifier has a very well-defined meaning:
it _forces_ linear interpretation of the buffer, wher
Hi Emil,
On 18 November 2016 at 15:24, Emil Velikov wrote:
> On 18 November 2016 at 15:17, Daniel Stone wrote:
>> Actually, present-and-zero modifier has a very well-defined meaning:
>> it _forces_ linear interpretation of the buffer, whereas a non-present
>> modifier may
that). It also doesn't
> support downloading patches in the mbox format (only plain diffs).
> Based on that, I don't recommend it.
Off-topic indeed. Arcanist is crippled, as you say, and I don't like
its UI. But git-phab does exist to let you attach patch series, e.
Hi Jonas,
On 21 November 2016 at 05:56, Jonas Ådahl wrote:
> On Thu, Nov 10, 2016 at 10:38:51AM +0000, Daniel Stone wrote:
>> On 10 November 2016 at 06:08, Jonas Ådahl wrote:
>> > On Mon, Oct 24, 2016 at 08:42:59PM +0100, Daniel Stone wrote:
>> That relies on the composi
lients will utilize #3 and #4 to use CCS.
> 6. Protocol work, EGL, Wayland, DRIX - etc
Wayland has modifier support already; there are patches out for review
for Weston to support this via the EGL extension above, as well as
inside KMS (part of the atomic branch).
> When Kristian's int
dri_format, dri_use,
> + modifiers, count,
> + bo);
> if (bo->image == NULL)
>goto failed;
>
> + bo->base.base.modifiers = calloc(count, sizeof(*modifie
modifiers */
+ if (!bo->image)
+ return 0;
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
rary
ABI, so if it doesn't change anything then it doesn't help, and if it
does then it's an ABI break, so NAK from me.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi Ben,
On 2 December 2016 at 18:17, Ben Widawsky wrote:
> On 16-12-02 18:07:22, Daniel Stone wrote:
>> On 2 December 2016 at 17:56, Eric Engestrom
>> wrote:
>> I have to admit I didn't catch this one. It doesn't help on 64-bit
>> since unsigned int is sti
ould
> think about merging the mesa patch ;-)
Yeah, the fact there are three different email addresses for you in
this thread probably says that it's been long enough. ;) Pushed now.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
re
> welcome, I think this little lib can improve the life of many SoC users.
Check out Ben Widawsky's 'Renderbuffer Decompression (and GBM
modifiers)' patchset. With this, as well as krh's pending GETPLANE2
ioctl that will allow us to get a list of acceptable modifiers
- first bugfix release.
Not being funny, but does this mean that 17.02 bugfix releases would
have to all be done in February, or could .mm.xx with xx > 0, mean
that the release was not done in that month, but just the branching
was?
Cheers,
Daniel
__
ormats (multiple fds,
multiple pitches, per-plane offset parameter)
- an out parameter for format, using the DRM FourCC format codes
- out parameters for a DRM modifier per-plane, to account for tiling
etc (and no longer calling anv_gem_set_tiling)
Cheers,
On 20 July 2016 at 13:47, Daniel Stone wrote:
> On 19 July 2016 at 20:47, Jonathan wrote:
>> +typedef VkResult (VKAPI_PTR *PFN_vkGetDmaBufINTEL)(VkDevice device,
>> VkDeviceMemory mem, VkImage image, int *fd, uint32_t *pitch);
>
> Some things you should consider adding
or the drmDevice libdrm API. It can provide a list
> of devices with all the nodes and other misc info. Thus we could use
> the render/card/other node as any point as needed.
Indeed.
I don't believe Jonny is working on this anymore, and I'm pretty
preoccupied, so it would be great
reenode) tends to be much faster, since you can follow up
right away.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
y interpret the data. We don't need a depth format, but we do
> need the right number of components and data type (FLOAT).
>
> For Z32F, this means using R32_FLOAT.
>
> Signed-off-by: Kenneth Graunke
R32_FLOAT instead of R16_UNORM in the subject.
-Daniel
> ---
> src
t or so might be good.
Otherwise I've had plenty fun reading around in blorp and the format
tables, so fwiw (and hey, it's very little!)
Reviewed-by: Daniel Vetter
It's a bit hairy how the outermost blt code needs to check the depth
stuff, I'd have prefered to keep that logi
n the write_reg
helper used by the gen6 queryobj code.
Cc: Kenneth Graunke
Signed-off-by: Daniel Vetter
---
src/mesa/drivers/dri/i965/gen6_queryobj.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c
b/src/mesa/drivers/dri/i965/gen6_q
>From bf60ddd081bd66d1364bf7973e664af46335dfd6 Mon Sep 17 00:00:00 2001
From: Daniel Czarnowski
Date: Wed, 16 Oct 2013 13:35:20 +0200
Subject: [PATCH] Support of GLX_RGBA*_FLOAT_BIT*, and correct setting of the
flags. Also commented each renderType use with information
which (fbconfig or cont
>From f93a54e7447a6f30c68d31ac82637e724c3953eb Mon Sep 17 00:00:00 2001
From: Daniel Czarnowski
Date: Wed, 16 Oct 2013 13:36:33 +0200
Subject: [PATCH] Support of GLX_RGBA*_FLOAT_BIT*, and correct setting of the
flags. Also commented each renderType use with information which (fbconfig
>From 762d184225d5f4c6c46ff302725063483ebd8bf0 Mon Sep 17 00:00:00 2001
From: Daniel Czarnowski
Date: Thu, 17 Oct 2013 12:27:15 +0200
Subject: [PATCH] Enables the fbconfig_float extension in list of supported
extensions, and adds it to known extensions table.
---
glx/extension_string.c |
apps. So imo this should go to stable, but maybe
after an extended soaking time.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
, using
that ioctl allows the kernel to limit your usage in case the available
ram is less than the virtual size of the gtt (atm we don't bother with
that much cleverness, but probably will in the future). See
DRM_IOCTL_I915_GEM_GET_APERTURE in libdrm (it's unfortunately not
expos
On Thu, Nov 07, 2013 at 04:23:12PM -0800, Ian Romanick wrote:
> On 11/07/2013 01:33 PM, Daniel Vetter wrote:
> > On Sat, Oct 12, 2013 at 12:10 AM, Ian Romanick wrote:
> >> + /* Once a batch uses more than 75% of the maximum mappable size, we
> >> +
mbie and commited it shortly
before the branch point. Please rip this out asap before it shows up
anywhere in a release and use the gem aperture ioctl instead.
That would also fix things for gen4, where the hardwired 2G isn't really
the truth of things either.
Yours, decently pissed,
-D
On Mon, Nov 11, 2013 at 11:03:49AM -0800, Ian Romanick wrote:
> On 11/09/2013 02:44 AM, Daniel Vetter wrote:
> > On Fri, Oct 11, 2013 at 03:10:14PM -0700, Ian Romanick wrote:
> >> From: Ian Romanick
> >>
> >> Signed-off-by: Ian Romanick
> >> ---
&
t; Signed-off-by: Ian Romanick
> Cc: Daniel Vetter
> Cc: "10.0"
> ---
> src/mesa/drivers/dri/i965/intel_screen.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/
On Mon, Nov 11, 2013 at 01:45:43PM -0800, Ian Romanick wrote:
> On 11/11/2013 01:35 PM, Daniel Vetter wrote:
> > On Mon, Nov 11, 2013 at 11:19:07AM -0800, Ian Romanick wrote:
> >> From: Ian Romanick
> >>
> >> Systems with little physical memory installed will
nter stuff with the CS checker.
- What about OA users on other rings? Iirc that stuff might be useful for
opencl running on the VCS ring, too. Otoh we don't have that need right
now, and the kernel could always just pass an OA token between rings and
synchronize with semaphores. Without the
---
src/glx/dri2_glx.c| 99 +++--
src/glx/glx_pbuffer.c |8 ++--
2 files changed, 98 insertions(+), 9 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 7ce5775..d0f284d 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_g
afraid to create long-term maintainance madness here with the
kernel's iron thou-shalt-not-break-userspace-ever rule ... Not likely
we'll ever accept srgb for framebuffers though.
-Daniel
> ---
>
> This gets iceweasel running with the GL compositor enabled.
>
> inc
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote:
> Daniel Vetter writes:
>
>> Hm, where do we have the canonical source for all these fourcc codes? I'm
>> asking since we have our own copy in the kernel as drm_fourcc.h, and that
>> one is part of the userspac
Author: Daniel Manjarres
Date: Sun Jun 22 09:47:58 2014 -0700
glx: Fix glxUseXFont for glxWindow and glxPixmaps
The current implementation of glxUseXFont requires creating
a temporary pixmap and graphics context, which requires a real
old-school X11 Window, not a glxDrawable
1 - 100 of 1281 matches
Mail list logo
