Re: Degugging with gdb

[Adam Jackson]

I don't know anything about using Mesa as a meson subproject, but the way I
usually test a local Mesa build is:

https://docs.mesa3d.org/install.html#running-against-a-local-build-easy-way

For example if I wanted to run gdb on glxgears I might say:

$ meson devenv -C build gdb -q glxgears

You can also just say "meson devenv -C build" to get a subshell in the
build environment. Note that the initial working directory is set to the
build dir, which can be a little confusing if your command line includes
relative paths, so don't use relative paths if you can help it.

- ajax

On Sat, Mar 30, 2024 at 4:05 PM Manuel Dun  wrote:

> Hello
>
> This is a continuation from a question I made in the mesa-user mailing
> list.
>
> how would I set up mesa 3d to debug with gdb? and is it reasonable to do
> so?
>
> I usually set libraries as meson subprojects but I don't know how to
> get the meson dependency for mesa 3d.
>
>

Re: Queries regarding the Khronos specification license

[Adam Jackson]

For what it's worth, I did raise this as a potential issue with the apache2
license migration for Khronos projects, and explicitly asked about MIT
dual-licensing at least for the GL headers. (The morbidly curious with a
Khronos membership may find the relevant discussion in the arb-nextgen
archives from May 2016.) I am not a lawyer, I am extremely not your lawyer,
and I am especially extremely not OpenBSD's lawyer, but my considered
opinion is OpenBSD is just straight up misguided about this and they do
themselves a disservice here. Whatever, not my circus, not my monkeys.

I don't imagine Mesa is ever going to stop using the Khronos-generated
headers as we have very good reasons to want not to diverge from them, so I
would encourage thinking of this as unavoidable, like it is for llvm, which
you're already building the OS with, so.

- ajax

Re: GBM as standalone buffer allocator

[Adam Jackson]

On Mon, Oct 23, 2023 at 6:39 AM Srinivas Pullakavi (QUIC) <
quic_spull...@quicinc.com> wrote:

> Hi,
>
>
>
> We are planning to enhance GBM as a standalone buffer allocator, which can
> be used for all multi-media clients. Ex: video, camera, display etc;
>
>
>
> GBM create device expects a file descriptor to be passed, which points to
> drm node. This brings in a dependency on display for buffer allocation. On
> headless devices where display driver is not present, GBM cannot be used
> for buffer allocations. E.g. Recording cases where pipeline is setup
> between Camera, Video, Graphics.
>

I don't understand the objection. drm devices are not compelled to have
display support. The panfrost drm driver for example does not have any
display support, only rendering.

- ajax

>

Re: Venus crashes guest if vkCreateInstance is called on MoltenVK

[Adam Jackson]

Nothing userspace can do should be able to crash the hypervisor. If it can,
that's a qemu bug.

- ajax

On Fri, May 26, 2023 at 9:22 PM DUO Labs  wrote:

> I'm working on integrating virglrenderer with MoltenVK on MacOS. However,
> I found that when vkCreateInstance is called, even though the instance is
> successfully created, mesa on the guest crashes, bring down QEMU with it.
>
>

Re: Performance issues with Lavapipe in Windows (?)

[Adam Jackson]

My first suspicion would be to rule out window system interaction. If you
render to your own VkImage instead of to a swapchain, how fast can you go?

- ajax


On Tue, Apr 4, 2023 at 12:56 PM George Karpathios  wrote:

> Hi list, I hope all is well.
>
> I would like to ask if there are any known issues regarding the
> performance of Lavapipe in Windows 10.
>
> I'm trying to add support for Vulkan software rendering into a relatively
> large 3d modeling/rendering application, so I opted to try Mesa and
> Lavapipe. I built LLVM 16.0.0 and Mesa 23.0.1 using the documentation
> (thanks for that!). My environment is an 8-core Intel i7 (with an
> integrated iGPU) with 32GiB RAM, an nVidia RTX 3070 and Visual Studio
> 2019/MSVC.
>
> The build procedure seems to be ok (Release builds, proper linking with
> either MT or MD runtime libraries, proper DLL loading via VK_ICD_FILENAMES)
> but the performance I'm getting during runtime is very slow. It looks like
> it needs 1-1.5 seconds to render a virtually empty scene (think just a
> floor grid of lines)  and over 15-20 seconds for a frame of a few thousand
> vertices. The CPU utilisation also seems to be low, under 20-25%.
>
> I understand that the information I provide is probably vague, but at this
> point I just want to rule some probable causes out, like is there any
> version of LLVM or Mesa or combination of them that is known to have such
> issues? Maybe some build/installation configuration parameter or
> environment variable that is important in Windows specifically and I may
> have missed (I tried tweaking LP_NUM_THREADS but didn't change anything) ?
> Anything that could point me in the right direction is highly valuable &
> appreciated.
>
> Also probably worth noting is the fact that the vkcube(pp) demo from the
> Vulkan SDK seems to run ok with Lavapipe, but in this case I also notice
> (in task manager) a ~50% utilization of the integrated iGPU (why?). In the
> aforementioned larger application I don't notice any usage of the
> integrated iGPU.
>
> Any advice on what I could check/double check is more than welcome. Thank
> you in advance for your time.
>
> Best regards,
> George
>
>
>

Re: Headless OpenGL Rendering using SSH and X11 forwarding

[Adam Jackson]

12290 is indeed EGL_BAD_ACCESS, and it's pretty much impossible for Mesa's
eglInitialize to return that, so (if I had to guess) you have nvidia's
driver installed as well, and (extra guessing now) nvidia's EGL only works
with connections to the local machine and not over the network. Mesa
shouldn't have that problem because it would select llvmpipe instead of a
native driver in that scenario, I think.

If "render to png" really is what you're trying to accomplish you might do
better to use EGL_EXT_platform_device to get a direct connection to the GPU
without involving a display server.

- ajax

On Tue, Mar 7, 2023 at 8:17 PM Richard Haney  wrote:

> Please help,
>
> I have been going around and around with this problem but cannot seem to
> make any headway. I hope that one of you OpenGL EGL experts can help. [image:
> :slight_smile:]
>
> I have created a program that uses OpenGL EGL (version 1.5) with OpenGL 3
> that successfully renders an offscreen triangle and saves it to an image
> file (PNG) when I ssh *without* X11 forwarding on my Linux (Ubuntu 22.04)
> machine.
>
> However when I try the same thing using ssh *with* X11 forwarding enabled
> I get the following EGL error when I call eglInitialize(…): 12290 (I
> *think* is EGL_BAD_ACCESS).
>
> This seems really weird and I hope it is something simple that I am just
> not currently seeing.
>
> I really like using OpenGL with EGL but need a way to remedy this
> situation if possible. Is there a way for EGL to determine if X11
> forwarding is being employed and to ignore it or some other solution?
>
> The snippet of relevant C++ code follows, with area where error occurs
> marked:
>
> #include  #include  #include  #define
> EGL_EGLEXT_PROTOTYPES #define GL_GLEXT_PROTOTYPES #include 
> #include  ... EGLDisplay display = 
> eglGetDisplay(EGL_DEFAULT_DISPLAY);
> if(display == EGL_NO_DISPLAY) { std::cerr << "Failed to get EGL display: "
> << eglGetError() << std::endl; exit(EXIT_FAILURE); } EGLint major; EGLint
> minor; if(eglInitialize(display, , ) == EGL_FALSE) { // ERROR
> 12290 is generated here std::cerr << "Failed to initialize EGL: " <<
> eglGetError() << std::endl; exit(EXIT_FAILURE); } ...
>
>
> Any help would be greatly appreciated.
>

Re: [EXTERNAL] Re: Zink MR signoff tags

[Adam Jackson]

Same for the X11 backends (xlib, glx, egl/x11, wsi/x11).

On Tue, Oct 18, 2022 at 6:14 PM Karol Herbst  wrote:

> and for Nouveau while I am at it.
>
> Unless somebody screams and still wants them.
>
> On Wed, Oct 19, 2022 at 12:12 AM Karol Herbst  wrote:
> >
> > Same for Rusticl
> >
> > On Mon, Oct 17, 2022 at 10:28 PM Jesse Natalie 
> wrote:
> > >
> > > Jumping on the bandwagon, I'm going to adopt this for Microsoft-owned
> code as well (src/gallium/d3d12, src/microsoft/*).
> > >
> > > -Jesse
> > >
> > > -Original Message-
> > > From: mesa-dev  On Behalf Of
> Gert Wollny
> > > Sent: Friday, October 7, 2022 2:37 AM
> > > To: erik.faye-lund ; Alyssa Rosenzweig <
> aly...@collabora.com>; Mike Blumenkrantz 
> > > Cc: ML mesa-dev 
> > > Subject: [EXTERNAL] Re: Zink MR signoff tags
> > >
> > > On Wed, 2022-10-05 at 17:21 +0200, Erik Faye-Lund wrote:
> > > > On Wed, 2022-10-05 at 08:20 -0400, Alyssa Rosenzweig wrote:
> > > > > + for not requiring rb/ab tags ...
> > > >
> > > > I think it's time to think about making this change all over Mesa as
> > > > well. We're deeply in bed with GitLab by now, so I don't think
> there's
> > > > a realistic chance that this isn't going to just be duplicate info
> any
> > > > time soon...
> > >
> > > Agreed, I'll certainly do this for r600 from now on.
> > >
> > > - Gert
>
>

Re: Question about eglCreatePbufferSurface with empty attrib_list

[Adam Jackson]

AFAIK this was the pre-framebuffer-object / OES_surfaceless_context way of
making a context current without (really) having a bound surface. That said
I don't think Mesa actually implements that feature correctly, atm I think
you'll get a BadValue from the xcb_create_pixmap call, but patches to fix
that would be welcome.

- ajax

On Mon, Jul 18, 2022 at 10:28 PM Lin, Shuicheng 
wrote:

> Hi,
>
> In spec, eglCreatePbufferSurface is allowed to be called with attrib_list
> is NULL or empty, which means EGL_WIDTH/EGL_HEIGHT for the surface is 0.
>
> And in mesa code, specific to android path, I cannot find the width/height
> could be updated to a normal value.
>
> Also the eglMakeCurrent call after the eglCreatePbufferSurface, will use
> the 0 width/height to allocate buffer, which seems un-reasonable.
>
> Could you share me why 0 is allowed for width/height, and how app will use
> the PbufferSurface later?
>
> Thanks.
>
>
>
> Best Regards
>
> Shuicheng
>
>
>

Re: Amber branch plan

[Adam Jackson]

At the moment 21.3.8 is the last planned Mesa 21.3.Z. So I kind of
imagine 21.3.9 being the first "amber-only" release where we flip the
meson option for amber to true by default, and we'd keep that branch
going for as long as people want to keep it compiling and fixing bugs
in it.

- ajax

On Fri, Feb 18, 2022 at 6:35 AM Timo Aaltonen  wrote:
>
> Dylan Baker kirjoitti 7.12.2021 klo 1.51:
> > Since classic is gone,  I thought I'd lay out my thinking for Amber.
> >
> > I'm assuming that we'll branch Amber from the 21.3 branch, after that
> > reaches normal EOL. That gives us the benefit of developing on top of a
> > known good state for classic drivers, and should minimize friction for
> > distros dealing with classic. If anyone wants to backport changes from
> > main to amber they can obviously do so.
> >
> > Are there any objections to that plan?
> >
> > Dylan
>
> Is there going to be a separate tarball release of Amber?
>
>
> --
> t
>

Re: Amber branch plan

[Adam Jackson]

This is my plan as well. I'm aiming to get amber packaged for Fedora
before February so I'll want to see !10557 merged pretty soon.

- ajax

On Mon, Dec 6, 2021 at 7:36 PM Jason Ekstrand  wrote:
>
> +1
>
> On Mon, Dec 6, 2021 at 5:51 PM Dylan Baker  wrote:
>>
>> Since classic is gone,  I thought I'd lay out my thinking for Amber.
>>
>> I'm assuming that we'll branch Amber from the 21.3 branch, after that
>> reaches normal EOL. That gives us the benefit of developing on top of a
>> known good state for classic drivers, and should minimize friction for
>> distros dealing with classic. If anyone wants to backport changes from
>> main to amber they can obviously do so.
>>
>> Are there any objections to that plan?
>>
>> Dylan

Re: [Mesa-dev] Request for developer access for Tony Wasserka

[Adam Jackson]

Done, welcome aboard.

- ajax

On Fri, Nov 20, 2020 at 4:49 AM Samuel Pitoiset
 wrote:
>
> +1
>
> On 11/20/20 10:44 AM, Daniel Schürmann wrote:
> > Hi,
> >
> > I would like to request developer access for our new team member, Tony
> > Wasserka.
> >
> > He has proven himself capable with a number of MRs and works actively
> > on the ACO backend.
> >
> > His gitlab nick is neobrain.
> >
> > Thanks in advance,
> > Daniel
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Intent to retire ancient driver support

[Adam Jackson]

Sending this on to the list for visibility, since not everyone follows
everything on gitlab. In this merge request:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7660

I retire support for DRI drivers older than Mesa 8.0, which was
February 2012. In particular this retires the ability for libGL to
even load DRI1 drivers, which last existed in Mesa 7.11. We are not
aware of any currently supported distros trying to ship both DRI1
drivers and anything newer. In fact the only distro I'm aware of that
ever _tried_ was RHEL 6, which goes into extended-life support at the
end of the month, and which is currently shipping Mesa 11.0.7 and is
thus _way_ behind the times in terms of hardware enablement.

Eric Anholt suggested that glvnd is the better way to retain DRI1
support at this point, and to that end there is also:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7674

Which allows us to override the glvnd vendor name. xserver could then
select a different name for DRI1 screens, and now you get
parallel-installable Mesa packages, which could be nice for a bunch of
reasons.

If you still care about DRI1 support, I am very sorry, but hopefully
!7674 (backported to 20.x) and a bit of polish to xserver should keep
things working for you, and your feedback/testing would be greatly
appreciated.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Heads up: new GLX/WSI presentation features in git

[Adam Jackson]

I've landed a couple of changes to the GLX and X11 WSI code that
enable GLX_EXT_swap_control_tear and VK_PRESENT_MODE_FIFO_RELAXED_KHR,
respectively. These enable the app to request that "late" swaps (that
missed the requested MSC or UST) post immediately instead of waiting
for the next vblank, which can reduce presentation jitter, keep you
from falling all the way from 60 to 30 fps, etc. I normally wouldn't
make a big deal about announcing it but it's likely that these could
expose new code paths through the 2D driver in ways that would show up
in test cases, particularly full-screen games and such.

Please let me know about any bugs you encounter due to these features.
Please include the X server and driver in use when you do, as most of
the heavy lifting for this is on the server side. Or, if they work for
you, let me know how much your FPS improved in Half Life or Stardew
Valley or what have you.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] swrast gallium provider doesn't work on Solaris SPARC (Mesa 20 with LLVM 10)

[Adam Jackson]

On Wed, 2020-05-13 at 18:27 +0200, Petr Sumbera wrote:
> Hi,
> 
> I have difficulties with Mesa update from version Mesa 18 (LLVM 6) where 
> it used to work.
> 
> Now with Mesa 20 and LLVM 10 glxgears doesn't show wheels but just some 
> random rectangles. Please see attached picture.
> 
> Any idea what could be possibly wrong?

You have the misfortune to be using a big-endian CPU, and that
corruption looks quite a lot like the vertex processing stage getting
channel order wrong. Since the internals of both TGSI and NIR ought to
be endian-indifferent, I suspect the error would be at point where you
acquire the vertex data from the app and need to do machine-specific
unpacking, but that's just a guess. Dumping the IR generated by each
should hopefully be instructive.

It might also be worth trying to build Mesa 20 against LLVM 6 to see if
that points to anything in LLVM, but that's probably a bit less likely.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Adam Jackson]

On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer  wrote:
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> > 
> > Thanks for the suggestion! I implemented something like this for Mesa:
> > 
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
> 
> I wouldn't mind manually triggering pipelines, but unless there is
> some trick I'm not realizing, it is super cumbersome.  Ie. you have to
> click first the container jobs.. then wait.. then the build jobs..
> then wait some more.. and then finally the actual runners.  That would
> be a real step back in terms of usefulness of CI.. one might call it a
> regression :-(

I think that's mostly a complaint about the conditionals we've written
so far, tbh. As I commented on the bug, when I clicked the container
job (which the rules happen to have evaluated to being "manual"), every
job (recursively) downstream of it got enqueued, which isn't what
you're describing. So I think if you can describe the UX you'd like we
can write rules to make that reality.

But I don't really know which jobs are most expensive in terms of
bandwidth, or storage, or CPUs, and even if I knew those I don't know
how to map those to currency. So I'm not sure if the UI we'd like would
minimize the cost the way we'd like.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Adam Jackson]

On Sun, 2020-03-29 at 09:45 -0700, Kristian Høgsberg wrote:

> As for loading, doesn't glvnd solve that?

It could. It does not. Right now there's not a (good) way for the DDX
driver to communicate a preferred implementation name to the GLX
client. xserver's glx just knows it needs an implementation named mesa,
and nvidia's glx, nvidia. Not a hard thing to wire up, and in fact you
can give multiple names and the client side will try them in sequence
so fallback stands a chance of working.

Now, if we're doing that, we should maybe consider using glvnd's
libGLdispatch directly, as I think right now we have an ugly double-
indirection between glHamSandwichEXT and _mesa_HamSandwichEXT if you're
building for glvnd. The only thing in the world besides Mesa that cares
about glapi and what a DRI driver interface is is xserver, and that's a
detail I'd like to eliminate and the new EGL-backed GLX in Xwayland
gets really close to eliminating it. But if nobody else gets excited
that much about fixing GLX, I completely understand.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

[Adam Jackson]

On Tue, 2020-03-17 at 10:12 -0700, Jacob Lifshay wrote:
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks) but need to synchronize with other
> drivers/processes is that there should be some way to create an
> explicit fence/semaphore from userspace and later signal it. This
> seems to conflict with the requirement for a sync_file to complete in
> finite time, since the user process could be stopped or killed.

DRI3 (okay, libxshmfence specifically) uses futexes for this. Would
that work for you? IIRC the semantics there are that if the process
dies the futex is treated as triggered, which seems like the only
sensible thing to do.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

[Adam Jackson]

On Wed, 2020-03-11 at 12:31 -0500, Jason Ekstrand wrote:

>  - X11: With present, it has these "explicit" fence objects but
> they're always a shmfence which lets the X server and client do a
> userspace CPU-side hand-off without going over the socket (and
> round-tripping through the kernel).  However, the only thing that
> fence does is order the OpenGL API calls in the client and server and
> the real synchronization is still implicit.

I'm pretty sure "the only thing that fence does" is an implementation
detail. PresentPixmap blocks until the wait-fence signals, but when and
how it signals are properties of the fence itself. You could have drm
give the client back a fence fd, pass that to xserver to create a fence
object, and name that in the PresentPixmap request, and then drm can do
whatever it wants to signal the fence.

> From my perspective, as a Vulkan driver developer, I have to deal with
> the fact that Vulkan is an explicit sync API but Wayland and X11
> aren't.

I'm quite sure we can give you an explicit-sync X11 API. I think you
may already have one.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] libdrm can't be released because of meson

[Adam Jackson]

On Wed, 2019-10-16 at 15:36 -0400, Marek Olšák wrote:
> Hi,
> 
> Since autotools is no longer in libdrm, it's not possible to make a release:

Apparently meson support in release.sh has been languishing unmerged
for a while:

https://gitlab.freedesktop.org/xorg/util/modular/merge_requests/8

This didn't work for me out of the box because it relied on very
specific formatting of the meson.build file. I updated it to use 'meson
introspect' (which I don't think existed when that MR was first
written), and now 'release.sh --dry-run .' looks like it works.

Note you'll need to install jq for this to work, which is sort of like
grep-on-steroids for json so it's quite nice to have around anyway.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gitlab issue migration, labels & triage

[Adam Jackson]

On Mon, 2019-09-23 at 11:50 +0300, Denys wrote:
> Hello Adam.
> I would ask to get a permissions to edit/triage the issues, as we did before 
> in bugzilla. We have a small team working on mesa project (right now intel 
> part mostly), so it would be great to have possibility to sort user issues 
> according to their components.
> paul.che10...@gmail.com
> den.kos...@gmail.com

I've added these accounts at Reporter level, you should be able to edit
issues now. Let me know if anything still isn't working.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/gbm: Fix config validation

[Adam Jackson]

On Sat, 2019-09-21 at 18:07 +0100, Robin Murphy wrote:
> In converting to shift/size-based validation, we lost a condition from
> the ARGB/XRGB equivalence check, which left it working one way round
> but not the other, and broke applications like glmark2-es2-drm on some
> platforms. Restore the equivalent check that *both* configs actually
> have an alpha channel before considering a mismatch.
> 
> Fixes: 7b4ed2b513ef ("egl: Convert configs to use shifts and sizes instead of 
> masks")
> Signed-off-by: Robin Murphy 

Makes sense to me.

Reviewed-by: Adam Jackson 

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gitlab issue migration, labels & triage

[Adam Jackson]

On Wed, 2019-09-18 at 23:41 +0200, Bas Nieuwenhuizen wrote:

> Has anybody put any though in how to best manage things here? e.g.
> some process, or do we want some form of automatic labeling, or is my
> concern overblown?

Well, there's the list of issues with no label:

https://gitlab.freedesktop.org/mesa/mesa/issues?scope=all=%E2%9C%93=opened_name[]=None

We can almost certainly keep that list empty if we're diligent about
it. And if there's volunteers sufficiently interested in triage but not
necessarily development we can add them with Reporter access. I'm a
_little_ surprised issue reporters don't automatically get that... but
on the other hand, as Mark Janes pointed out, we're likely to be using
labels for quite a lot now, so the ability to delete labels probably
should be restricted to Developer and up.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Release workflow with gitlab issues

[Adam Jackson]

On Wed, 2019-09-18 at 12:08 -0700, Mark Janes wrote:
> Adding the release managers to the CC to make sure they see the thread...
> 
> Dylan Baker  writes:
> 
> > Hi everyone,
> > 
> > Since we're migrating to gitlab issues, it seems like a good time to review 
> > how
> > we track stable releases, particularly release blockers.

For the avoidance of doubt and confusion, I don't plan to migrate any
of the components with bugs on the 19.2 release tracker until 19.2 is
actually released.

> > I'd like to use a gitlab milestone as a replacement for the tracker issues 
> > from
> > gitlab. The process would work much the same way as it does now, but with a
> > milestone.
> 
> Right now, anyone can create milestones.  Is there a way to limit the
> capability to release managers?  Would that be desirable?
> 
> I see the same issue with labels...  Anyone could delete a label, and
> I'm not sure how we would recover that information.

Strictly, the "Reporter" access level and above can manage labels,
milestones require "Developer" or above. Not super meaningful since the
mesa group really only has Developer or above.

I'm not super worried about it to be honest, people tend not to be
malicious.

> > We'll also need to replace the Bugzilla: tag with a tag that gitlab 
> > recognizes
> > for closing issues. Since we already use "Fixes:" for something else, I'd 
> > like
> > to propose "Closes:"
> > 
> > so we'd replace:
> > Buzilla: https://...
> > with:
> > Closes: !0
> 
> A more exact replacement would be:
>   Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/{issue}
> 
> Is there an advantage to the !{issue} format?  Perhaps gitlab parses it
> and closes the issue?

gitlab can parse both the !nnn format and full URLs, and yes, it does
close issues when a commit with such a Closes: line is merged.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?

[Adam Jackson]

On Thu, 2019-08-29 at 11:52 -0700, Kenneth Graunke wrote:

> What do people think?  If folks are in favor, Daniel can migrate
> everything for us, like he did with the other projects.  If not,
> I'd like to hear what people's concerns are.

It's been almost three weeks, and this seems to have resulted in broad
consensus and very little objection, mostly around how to build
searches effectively. So, let's do it.

I've enabled filing issues for the remaining mesa projects that didn't
have it already (vkpipeline-db, shader-db, drm, and mesa itself). I
also turned merge requests on for mesa/drm (which is just libdrm, not
the kernel). I'll be going through bugzilla for the Mesa and DRI
products and migrating or closing bugs as appropriate. After each
component is migrated it will be closed for bug entry, so there will be
a small window here where bugs can be filed in two places, hopefully
this shouldn't cause too much confusion.

The remaining bikeshed here is the drm kernel repository, and
relatedly, what to do with bugs that are kernel issues. For now I'm
going to handle that by trying to avoid migrating obvious kernel
issues. There's the outline of a migration plan already in:

https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/69

If the kernel maintainers are ready to move the canonical repo URL and
issues, then let's get that moving sooner rather than later.

For progress on the migration, suggestions about how and where to move
issues, etc., please see:

https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/190

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] demos: eglinfo: Add support for surfaceless EGL platform

[Adam Jackson]

On Sun, 2019-09-15 at 17:53 +0300, Matwey V. Kornilov wrote:
> Signed-off-by: Matwey V. Kornilov 

Thanks! I had an equivalent hack in my local copy and hadn't pushed it,
tsk tsk. I've opened a merge request for yours here:

https://gitlab.freedesktop.org/mesa/demos/merge_requests/4

Will merge in a day or so if nobody objects.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Moving libglvnd to FreeDesktop Gitlab

[Adam Jackson]

On Wed, 2019-09-04 at 14:27 -0600, Kyle Brenneman wrote:
> On 9/4/19 8:44 AM, Daniel Stone wrote:
> > Hi,
> > 
> > On Wed, 4 Sep 2019 at 15:12, Chuck Atkins  wrote:
> > > Can we use Gitlab's GitHub import feature?
> > > 
> > > https://gitlab.freedesktop.org/help/user/project/import/github.md
> > > 
> > > I haven't used it before but it looks like it will migrate everything, 
> > > i.e. repo, issues, prs, etc.
> > Yeah, we definitely can. We can create a new namespace for GLVND and
> > import the project into there.
> > 
> > Who else should I add to the group?
> I'm not very familiar with the administrative side of GitLab -- does 
> adding to the group just control who can check in new commits?

It's fairly fine-grained, for details see:

https://docs.gitlab.com/ee/user/permissions.html

- ajax 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?

[Adam Jackson]

On Fri, 2019-08-30 at 14:26 +0100, Chris Wilson wrote:
> Quoting Daniel Stone (2019-08-30 14:13:08)
> > Hi,
> > 
> > On Thu, 29 Aug 2019 at 21:35, Chris Wilson  wrote:
> > > 
> > > I think so. I just want a list of all bugs that may affect the code I'm
> > > working on, wherever they were filed. I have a search in bugs.fdo, I
> > > just need instructions on how to get the same from gitlab, hopefully in
> > > a compact format.
> > 
> > It's not clear to me what you need. Can you please give more details?
> 
> At the moment, I always have open a couple of searches which are basically
> 
> Product: DRI, Mesa, xorg
> Component: Driver/intel, Drivers/DRI/i830, Drivers/DRI/i915, 
> Drivers/DRI/i965, Drivers/Vulkan/intel, DRM/AMDgpu, DRM/Intel, IGT
> Status: NEW, ASSIGNED, REOPENED, NEEDINFO
> 
> I would like a similar way of getting a quick glance at the issues under
> discussion and any new issues across the products -- basically I want a
> heads up in case I've broken something, however subtle. And sometimes
> you just need to trawl through every bug in case you missed something.

You can do a top-level search for arbitrary strings, and get a list of
matching issues:

https://gitlab.freedesktop.org/search?group_id=_id=_ref==issues=i965

But that's perhaps not super useful. There's no way to globally search
for issues with a particular label, probably because labels are scoped
either to projects or groups and not site-wide. But you _do_ get
project-wide labels, so we could promote mesa/mesa's i965 label to be
usable from mesa/*. The xorg project has this already for some labels:

https://gitlab.freedesktop.org/groups/xorg/-/labels
https://gitlab.freedesktop.org/groups/xorg/-/issues?scope=all=%E2%9C%93=opened_name[]=gsoc

This probably implies that we'd want the kernel repo to be a mesa
subproject. And then you'd just have top-level label searches for the
xorg and mesa projects.

> > If you want cross-component search results in a single list, that's
> > not really something we can do today, and I don't know if it would
> > land any time soon. You can however subscribe to particular issue
> > labels, and when you see something that catches your eye add a 'todo'
> > for it, then the main UI shows all your outstanding todos, including
> > where people have mentioned you etc.
> 
> One thing we did for bugzilla was set the default QA component to a
> mailing list, so we had a single place to subscribe to get all the spam.
> I presume something similar would be available to subscribe to every
> issue across a range of categories.

You (individually) can subscribe to a label (per-project-or-group),
yes. Subscribing a mailing list to a label is somewhat awkward since
the email address for an account is where things like password reset
requests get sent.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] glx: Fix incompatible function pointer types.

[Adam Jackson]

On Tue, 2019-08-27 at 10:57 +, Jose Fonseca wrote:
> I don't know how Meson didn't hit this issue, when it too already uses
> -Werror=incompatible-pointer-types

Yeah, weird.

Reviewed-by: Adam Jackson 

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mirroring ogl-sample source code in gitlab?

[Adam Jackson]

On Wed, 2019-06-12 at 10:29 +0200, Erik Faye-Lund wrote:
> On Wed, 2019-06-12 at 10:25 +0200, Erik Faye-Lund wrote:
> > On Tue, 2019-06-11 at 12:41 -0400, Adam Jackson wrote:
> > > On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote:
> > > 
> > > > So here's the question: How does people feel about hosting this under 
> > > > https://gitlab.freedesktop.org/mesa/ogl-sample/? If people are OK with
> > > > this, I will make that happen, and send out a patch to update the link
> > > > we have in our FAQ once that's done.
> > > 
> > > Sounds fine to me. I've needed to refer to the SI more than once, I'd
> > > be happy to have it in a well-known location.
> > > 
> > > Vaguely related: Old-timers may remember that DRI used to have its own
> > > CVS repo on dri.sourceforge.net. If you want a git import of that tree,
> > > you can find it here:
> > > 
> > > https://gitlab.freedesktop.org/ajax/dri
> > 
> > Hmm, for some reason I can't see the repo here, just the (empty) issue
> > tracker. Even though the project is listed as public... Strange.

Weirdly there are separate controls for project and repository
visibility, and the latter was set to "Only project members" for some
reason. Fixed, thanks!

> > > I'd be happy to move this under mesa/ too if we want.
> > 
> > I think that'd be nice, yeah. I think it would be nice to keep things
> > like this in some central location.
> > 
> > One could also imagine that the SGI GLX realease in it's original form
> > would be interesting to preserve in case other mirrors go down as well.
> > Just for the heck of it, I've archived that as well, even though it's
> > just a single tarball, so it ends up as just a single commit:
> > 
> > https://gitlab.freedesktop.org/kusma/glx
> > 
> > This could also be a candidate for moving under the mesa-group.
> 
> Actually, perhaps this one belongs under the xorg-group instead of the
> mesa-group...

Yeah, toss-up really. The glx code drop has both the client library and
server support, so it's not entirely one or the other. libGL used to
live only in the X11 monolith, and (iirc) we moved it to Mesa during
m12n so it lived near the DRI drivers since that interface kept
growing.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mirroring ogl-sample source code in gitlab?

[Adam Jackson]

On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote:

> So here's the question: How does people feel about hosting this under 
> https://gitlab.freedesktop.org/mesa/ogl-sample/? If people are OK with
> this, I will make that happen, and send out a patch to update the link
> we have in our FAQ once that's done.

Sounds fine to me. I've needed to refer to the SI more than once, I'd
be happy to have it in a well-known location.

Vaguely related: Old-timers may remember that DRI used to have its own
CVS repo on dri.sourceforge.net. If you want a git import of that tree,
you can find it here:

https://gitlab.freedesktop.org/ajax/dri

I'd be happy to move this under mesa/ too if we want.

> I would further propose we mark the repo as archived, which would
> clearly mark that we're not maintaining it and also prevent it from
> appearing in searches.

Enh. Less sold on this, though if it's linked from the FAQ I guess it's
okay. I find that gitlab's archive makes things a little too hard to
find, I would often prefer to see archived results in searches. But
there's not really a better way to make a repo read-only, so I won't
object too strongly.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GLU and GLUT issues migrated to gitlab

[Adam Jackson]

On Mon, 2019-05-13 at 12:14 -0400, Adam Jackson wrote:
> Not, I hope, that anyone is likely to notice, but I've moved the open
> GLU and GLUT bugs from bugzilla to gitlab and closed the components in
> bugzilla. I say "moved" but really glut only had one open bug and it
> was fixed ages ago. Anyway, use gitlab now please.

mesa/demos has been migrated now as well.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] GLU and GLUT issues migrated to gitlab

[Adam Jackson]

Not, I hope, that anyone is likely to notice, but I've moved the open
GLU and GLUT bugs from bugzilla to gitlab and closed the components in
bugzilla. I say "moved" but really glut only had one open bug and it
was fixed ages ago. Anyway, use gitlab now please.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Revert "glx: Fix synthetic error generation in __glXSendError"

[Adam Jackson]

On Tue, 2019-05-07 at 20:17 +1000, Timothy Arceri wrote:

> I don't know enough about this code to take responsibility for such 
> changes. I was just trying to revert to the status quo until this could 
> be investigated again.
> 
> My suggestion is we roll back the recent change. Then someone needs to 
> create piglit test for both scenarios before trying to move forward again.
> 
> If you want to try something different then go for it :)

Don't feel bad about not understanding this code. Honestly what libGL
is doing here - fabricating an X11 protocol error out of thin air - is
completely unique to libGL among the X client libraries, and it's not
surprising that attempting to do causes issues.

I'm fine with any amount of revert here. I can't promise I'll have the
time to investigate this in any detail promptly though.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: fix pbuffers because internally they are front buffers

[Adam Jackson]

On Mon, 2019-04-29 at 20:35 -0400, Marek Olšák wrote:

> Yeah that's possible. The thing is that a GL context can have a
> doublebuffered config and begin with GL_BACK as the draw buffer, but
> MakeCurrent can set a pbuffer with a singlebuffered config and then
> nothing is rendered with Mesa because there is no back buffer. This
> case appears to work on NVIDIA.

Okay, that makes sense. Thanks for the explanation.

I think this is only true because of EGL_KHR_no_config_context? If the
context has a config, then you shouldn't be able to make a single-
buffered pbuffer current to a double-buffered context. EGL section
2.2's definition of compatibility includes having "color and ancillary
buffers of the same depth"; if you don't have a back buffer, then you
have zero bits of back buffer, and you would not be compatible with
non-zero bits of back buffer. I would think, anyway.

Now if you bind a single-buffered pbuffer to a no-config context,
obviously rendering should go to GL_FRONT.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: fix pbuffers because internally they are front buffers

[Adam Jackson]

On Fri, 2019-04-26 at 23:31 -0400, Marek Olšák wrote:

I don't claim to know what this series is trying to fix, but:

> +* 2) Pbuffers are back buffers from the application point of view,
> +*but they are front buffers from the Mesa point of view,
> +*because they are always single buffered.
> +*/

The EGL spec (back to 1.0!) says:

"The resulting pbuffer will contain color buffers and ancillary buffers
as specified by config."

This appears to be copied from GLX, which has something more elaborate:

"The resulting pbuffer will contain color buffers and ancillary buffers
as specified by config. It is possible to create a pbuffer with back
buffers and to swap the front and back buffers by calling
glXSwapBuffers. Note that pbuffers use framebuffer resources so
applications should consider deallocating them when they are not in
use."

So I'm not convinced that pbuffers are "always single-buffered". The
back buffer is definitely a color buffer, and at least under GLX it
seems like it should be possible to draw red to back, swap, draw blue
to back, glReadBuffer(GL_FRONT), and expect glReadPixels to return red.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support

[Adam Jackson]

On Tue, 2019-04-23 at 19:21 -0400, Marek Olšák wrote:

> Then I think a separate EGL extension that exposes swrast would be
> better. The thing with the device extensions is that swrast is not a
> device.

Enh. I've got dumb GPUs I need to support, they need to run OpenGL, and
if they were running swrast-on-otherwise-dumb-gem, I can make posting
the front buffer to the compositor be (at least sometimes) zero-copy,
instead of the XPutImage thing that drisw currently has to do. So I
don't think it's necessarily the case that swrast doesn't have
"hardware" support behind it.

More generally, if the term in the extension spec was "renderer" not
"device" I don't think we'd be having this discussion. And I think it's
worth having renderer selection be orthogonal in an API sense.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] egl: Fix EGL_PLATFORM_X11_SCREEN_KHR handling

[Adam Jackson]

If this was specified and a non-NULL display was passed to
eglGetPlatformDisplay, we would ignore the attribute and instead use
whatever xcb thought the default screen would be.

To fix this, store a copy of the attribute list in the _EGLDisplay, and
use that to look up any non-default screen number if we need it.
---
 src/egl/drivers/dri2/platform_x11.c | 28 --
 src/egl/main/eglapi.c   |  2 +-
 src/egl/main/egldisplay.c   | 85 +++--
 src/egl/main/egldisplay.h   |  4 +-
 4 files changed, 96 insertions(+), 23 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_x11.c 
b/src/egl/drivers/dri2/platform_x11.c
index c8c676d2f00..7b95634e77c 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -1276,24 +1276,44 @@ static const __DRIextension *swrast_loader_extensions[] 
= {
NULL,
 };
 
+static int
+dri2_find_screen_for_display(Display *dpy, _EGLDisplay *disp)
+{
+   int screen = -1;
+   const EGLAttrib *attr;
+
+   if (dpy)
+  screen = DefaultScreen(dpy);
+
+   for (attr = disp->Options.Attribs; attr; attr += 2) {
+  if (attr[0] == EGL_PLATFORM_X11_SCREEN_EXT) {
+ screen = attr[1];
+ break;
+  }
+  if (attr[0] == EGL_NONE)
+ break;
+   }
+
+   return screen;
+}
+
 static EGLBoolean
 dri2_get_xcb_connection(_EGLDriver *drv, _EGLDisplay *disp,
 struct dri2_egl_display *dri2_dpy)
 {
xcb_screen_iterator_t s;
-   int screen = (uintptr_t)disp->Options.Platform;
+   int screen;
const char *msg;
 
disp->DriverData = (void *) dri2_dpy;
if (disp->PlatformDisplay == NULL) {
-  dri2_dpy->conn = xcb_connect(NULL, );
+  dri2_dpy->conn = xcb_connect(NULL, NULL);
   dri2_dpy->own_device = true;
} else {
   Display *dpy = disp->PlatformDisplay;
-
   dri2_dpy->conn = XGetXCBConnection(dpy);
-  screen = DefaultScreen(dpy);
}
+   screen = dri2_find_screen_for_display(disp->PlatformDisplay, disp);
 
if (!dri2_dpy->conn || xcb_connection_has_error(dri2_dpy->conn)) {
   msg = "xcb_connect failed";
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 588c6a5f1eb..4696eca8f82 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -379,7 +379,7 @@ eglGetDisplay(EGLNativeDisplayType nativeDisplay)
native_display_ptr = (void*) nativeDisplay;
 
plat = _eglGetNativePlatform(native_display_ptr);
-   disp = _eglFindDisplay(plat, native_display_ptr);
+   disp = _eglFindDisplay(plat, native_display_ptr, NULL);
return _eglGetDisplayHandle(disp);
 }
 
diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c
index b26a9575087..8aae6900f09 100644
--- a/src/egl/main/egldisplay.c
+++ b/src/egl/main/egldisplay.c
@@ -202,20 +202,64 @@ _eglFiniDisplay(void)
  }
   }
 
+  free(disp->Options.Attribs);
   free(disp);
}
_eglGlobal.DisplayList = NULL;
 }
 
+static int
+_eglNumAttribs(const EGLAttrib *attrib_list)
+{
+   int ret = 0;
+   const EGLAttrib *attr;
+
+   for (attr = attrib_list; attr; attr++) {
+  ret++;
+  if ((ret % 2 == 1) && (*attr == EGL_NONE))
+ break;
+   }
+
+   return ret;
+}
+
+static int
+_eglSameAttribs(const EGLAttrib *a, const EGLAttrib *b)
+{
+   int na = _eglNumAttribs(a);
+   int nb = _eglNumAttribs(b);
+
+   /* different numbers of attributes must be different */
+   if (na != nb)
+  return 0;
+
+   /* both lists NULL are the same */
+   if (!a && !b)
+  return 1;
+
+   /* otherwise, compare the lists */
+   return memcmp(a, b, na) == 0;
+}
 
 /**
  * Find the display corresponding to the specified native display, or create a
- * new one.
+ * new one. EGL 1.5 says:
+ *
+ * Multiple calls made to eglGetPlatformDisplay with the same parameters
+ * will return the same EGLDisplay handle.
+ *
+ * We read this extremely strictly, and treat a call with NULL attribs as
+ * different from a call with attribs only equal to { EGL_NONE }. Similarly
+ * we do not sort the attribute list, so even if all attribute _values_ are
+ * identical, different attribute orders will be considered different
+ * parameters.
  */
 _EGLDisplay *
-_eglFindDisplay(_EGLPlatformType plat, void *plat_dpy)
+_eglFindDisplay(_EGLPlatformType plat, void *plat_dpy,
+const EGLAttrib *attrib_list)
 {
_EGLDisplay *disp;
+   int num_attribs = _eglNumAttribs(attrib_list);
 
if (plat == _EGL_INVALID_PLATFORM)
   return NULL;
@@ -225,7 +269,8 @@ _eglFindDisplay(_EGLPlatformType plat, void *plat_dpy)
/* search the display list first */
disp = _eglGlobal.DisplayList;
while (disp) {
-  if (disp->Platform == plat && disp->PlatformDisplay == plat_dpy)
+  if (disp->Platform == plat && disp->PlatformDisplay == plat_dpy &&
+  _eglSameAttribs(disp->Options.Attribs, attrib_list))
  break;
   disp = disp->Next;
}
@@ -237,6 +282,16 @@ _eglFindDisplay(_EGLPlatformType plat, void *plat_dpy)

Re: [Mesa-dev] Mesa compatibility range

[Adam Jackson]

On Wed, 2019-04-10 at 15:37 +, Jonathan Jackson wrote:

> 1.   My question is: Is it reasonable to think that llvmpipe (or other 
> drivers) will grand me a much wider
> array of supported system if I use that implementation over the original 
> Windows one?

I'm reasonably sure that llvmpipe implements a newer version of OpenGL
than the software renderer included with Windows.

> 2.   Another way to ask the question is: Is there a way of knowing which 
> specs a system is required to have
> so it can support Mesa’s implementation of all of OpenGL 2.1? (is it common 
> that a system(high or low end)
> will support all of Mesa’s equivalents of OpenGL 2.1 features).

llvmpipe's OpenGL version does not depend on the CPU's feature level,
it implements OpenGL 3.3 regardless of the instruction set.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] egl: add optional plat_opt to _eglFindDisplay()

[Adam Jackson]

On Thu, 2019-04-04 at 16:25 +0100, Emil Velikov wrote:

> I'm not a huge fan of this. Yet again the other platform (x11) that uses
> these has a number of issues, see below for details. Once those are resolved
> we could try and make this more uniform.
> 
>  a) spec does not mention if a new (or the existing) EGLDislay should be
> given for same native_dpy/screen_no combo.

An EGLDisplay maps to an X11 screen. EGL_KHR_platform_x11 says:

> On the X11 platform, an EGLDisplay refers to a specific X11 screen rather
> than an X11 display connection.

And EGL 1.5 says (with similar text in EGL_EXT_platform_base):

> Multiple calls made to eglGetPlatformDisplay with the same parameters will
> return the same EGLDisplay handle.

EGL_KHR_platform_x11 is a little confusing on this point in one of the
issues, because it says a new display connection is created for
EGL_DEFAULT_DISPLAY; presumably that's only for the first EGLDisplay
you create though.

>  b) the implementation has number of issues:
>  - screen 0 is hardcoded when using DEFAULT_DISPLAY

False, but:

>  - screen is _ignored_ when using !DEFAULT_DISPLAY

true, but easily fixed. We definitely store the screen number in
disp->Options.Platform in _eglParseX11DisplayAttribList, and then:

> static EGLBoolean 
>  
> dri2_get_xcb_connection(_EGLDriver *drv, _EGLDisplay *disp,   
>  
> struct dri2_egl_display *dri2_dpy)
>  
> { 
>  
>xcb_screen_iterator_t s;   
>  
>int screen = (uintptr_t)disp->Options.Platform;
>  
>const char *msg;   
>  
>   
>  
>disp->DriverData = (void *) dri2_dpy;  
>  
>if (disp->PlatformDisplay == NULL) {   
>  
>   dri2_dpy->conn = xcb_connect(NULL, );
>  
>   dri2_dpy->own_device = true;

If no display was given, we connect however xcb would, and save what it
decided was the default screen number.

>} else {   
>  
>   Display *dpy = disp->PlatformDisplay;   
>  
>   
>  
>   dri2_dpy->conn = XGetXCBConnection(dpy);
>  
>   screen = DefaultScreen(dpy);
>  
>}

If not, we use what the display already had set; this is where we
ignore the user's screen number and instead use the display's default.

I think the fix is to delete that DefaultScreen line above, and in
_eglFindDisplay call the appropriate platform's vtable to check for
identical option lists (this is your _eglSameDeviceDisplay in the next
patch, just abstracted out a bit).

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Should piglit drop bugzilla and move to using gitlab issues?

[Adam Jackson]

On Fri, 2019-03-01 at 17:35 -0800, Kenneth Graunke wrote:
> On Friday, March 1, 2019 1:30:48 PM PST Dylan Baker wrote:
> > Quoting Jordan Justen (2019-03-01 12:22:18)
> > > I guess piglit makes very light usage of bugzilla. Would it be simpler
> > > to just use gitlab issues in the piglit gitlab project?
> > > 
> > > -Jordan
> > 
> > I think we should, anecdotally it seems like there are more spam bugs 
> > against
> > piglit than real bugs anyway. And when I did some digging there's a grand 
> > total
> > of ~500 bugs filed against piglit for all time. 
> > 
> > Dylan
> 
> I would like to try it.
> 
> 1. It would give Mesa developers some more experience with Gitlab issue
>tracking, without switching Mesa over - which we aren't ready to do.
>(I personally am fairly happy with Bugzilla as it stands.)
> 
> 2. I think hardly anyone looks at Piglit Bugzilla.  There are very few
>bugs filed there---but more importantly, very few people actually
>read or update them.  Yesterday I went through them and found some
>bugs that were likely fixed ages ago, but never closed.  Others were
>filed years ago and long since forgotten.
> 
>I think using Gitlab issues would provide greater visibility to any
>issues we want to track.  They'd be right there on the same webpage
>with MRs.  MR discussions can link to them.  Email notifications can
>happen and are easily customizable.

There also seemed to be rough consensus on this on #dri-devel, and
we're getting more and more bugzilla spam, so I've closed the piglit
product in bugzilla for new bug entry and enabled gitlab issues for
mesa/piglit. There's only 27 open bugs left in bz; I'll take a pass
through them to close out anything obviously fixed or no longer
relevant, and migrate the rest.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] RFC - libglvnd and GLXVND vendor enumeration to facilitate GLX multi-vendor PRIME GPU offload

[Adam Jackson]

On Fri, 2019-02-08 at 10:19 -0800, Andy Ritger wrote:

> (1) If configured for PRIME GPU offloading (environment variable or
> application profile), client-side libglvnd could load the possible
> libGLX_${vendor}.so libraries it finds, and call into each to
> find which vendor (and possibly which GPU) matches the specified
> string. Once a vendor is selected, the vendor library could optionally
> tell the X server which GLX vendor to use server-side for this
> client connection.

I'm not a huge fan of the "dlopen everything" approach, if it can be
avoided. I think I'd rather have a new enum for GLXQueryServerString
that elaborates on GLX_VENDOR_NAMES_EXT (perhaps GLX_VENDOR_MAP_EXT),
with the returned string a space-delimited list of :.
libGL could accept either a profile or a vendor name in the environment
variable, and the profile can be either semantic like
performance/battery, or a hardware selector, or whatever else.

This would probably be a layered extension, call it GLX_EXT_libglvnd2,
which you'd check for in the (already per-screen) server extension
string before trying to actually use.

> At the other extreme, the server could do nearly all the work of
> generating the possible __GLX_VENDOR_LIBRARY_NAME strings (with the
> practical downside of each server-side GLX vendor needing to enumerate
> the GPUs it can drive, in order to generate the hardware-specific
> identifiers).

I don't think this downside is much of a burden? If you're registering
a provider other than Xorg's you're already doing it from the DDX
driver (I think? Are y'all doing that from your libglx instead?), and
when that initializes it already knows which device it's driving.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 10-bit fbconfigs break most video players using VAAPI+GLX

[Adam Jackson]

On Wed, 2019-02-06 at 10:33 -0500, Adam Jackson wrote:
> On Tue, 2019-02-05 at 17:30 -0500, Marek Olšák wrote:
> 
> > If we expose 10-bit or 16-bit formats, a lot of software will be
> > broken. Any ideas how to get out of this rabbit hole?
> 
> Use GLX_SGIX_visual_select_group to hide the depth-30 formats after the
> depth-24 ones. We're already doing this for similar reasons to mask
> Composite's synthetic argb visual on rgb565 displays. Technically
> there's nothing preventing you from doing this purely client-side, but
> properly this is a server-side change (and an easy one).

... although, this may just move the breakage around. I assume the
failure mode here is that the selected fbconfig doesn't match the
visual of the destination window? If so, then preferring the 
fbconfigs will still mismatch if the destination window really is
2101010.

(goes and actually reads libva)

So, some of this problem goes away by using GLX_EXT_no_config_context
at context creation time, if available. That at least gives you a
context that can bind to arbitrary drawables. I'm not entirely clear on
how you inform libva which window you expect to draw to, but if you had
that at CreateContext time you could also just specify the
GLX_VISUAL_ID you wanted.

But the other place it uses glXChooseFBConfig is when creating the
offscreen GLXPixmap, and honestly I don't understand why libva bothers
to do that at all. What possible benefit is derived from using
GLX_EXT_texture_from_pixmap for the rendering surface? Is someone
seriously trying to render frames from one X client and display from
another, and if so, how are they getting the GLXPixmap's XID out of
libva? Why make this a server-side resource at all?

If there are other video players / engines that need fixing, I say,
let's fix them. I'm not sure any amount of client-side workaround can
ever be satisfactory.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] 10-bit fbconfigs break most video players using VAAPI+GLX

[Adam Jackson]

On Tue, 2019-02-05 at 17:30 -0500, Marek Olšák wrote:

> If we expose 10-bit or 16-bit formats, a lot of software will be
> broken. Any ideas how to get out of this rabbit hole?

Use GLX_SGIX_visual_select_group to hide the depth-30 formats after the
depth-24 ones. We're already doing this for similar reasons to mask
Composite's synthetic argb visual on rgb565 displays. Technically
there's nothing preventing you from doing this purely client-side, but
properly this is a server-side change (and an easy one).

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/13] egl: Convert configs to use shifts instead of masks

[Adam Jackson]

On Mon, 2019-01-28 at 10:42 -0800, Kevin Strasser wrote:

> @@ -237,19 +268,35 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig 
> *dri_config, int id,
>   break;
>  
>case __DRI_ATTRIB_RED_MASK:
> - dri_masks[0] = value;
> + dri_shifts[0] = ffs(value) - 1;
> + break;
> +
> +  case __DRI_ATTRIB_RED_SHIFT:
> + dri_shifts[0] = value;
>   break;

I kind of want some paranoia here (for both cases) along the lines of:

int shift = dri_shifts[x];
if (shift != -1 && shift != value /* or ffs(value) - 1 */)
assert(!"inconsistent config mask/shift");

That's probably being too cautious, certainly not worth blocking this
series for.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/13] Enable fp16 visuals and fbconfigs

[Adam Jackson]

On Mon, 2019-01-28 at 10:42 -0800, Kevin Strasser wrote:
> This series enables fp16 fbconfigs and visuals by leveraging existing
> off-screen rendering support.
> 
> These formats can be used in conjunction with EXT_surface_SMPTE2086_metadata
> (not yet implemented by any drivers) to support EXT_gl_colorspace_scrgb /
> EXT_gl_colorspace_scrgb_linear, used in places like Android wide color
> gamut.

This looks great! Comments on 4/ and 11/ are minor, and haven't built
my way through testing this yet, but:

Reviewed-by: Adam Jackson 

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 11/13] gallium: Add buffer and configs handling or fp16 formats

[Adam Jackson]

On Mon, 2019-01-28 at 10:42 -0800, Kevin Strasser wrote:
> Expose configs when allow_fp16_configs has been enabled and
> DRI_LOADER_CAP_FP16 is set in the loader.
> 
> Also, make kms_swrast_dri respect format bpp, to allow for allocating
> buffers wider than 32 bpp.

Was this the only offender?

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fwd: Review for last remaining Mesa wayland-drm depth 30 bits?

[Adam Jackson]

On Tue, 2019-01-29 at 17:51 +0100, Mario Kleiner wrote:
> Thanks for the quick review!
> 
> Patchwork didn't pick the r-b's up though. Do i need to do anything /
> ping somebody to get those merged to master ideally before the close
> 19.0 branchpoint and not overlooked?

I've created a merge request:

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/167

I'll merge that once Travis gets a chance to build it.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Fwd: Review for last remaining Mesa wayland-drm depth 30 bits?

[Adam Jackson]

On Tue, 2019-01-29 at 14:45 +0100, Mario Kleiner wrote:
> Hi,
> 
> could i get some review of the last two missing patches of mine for
> depth 30 support in Mesa's egl/wayland wl-drm backend? They are over
> six months old now, well-tested at time of original submission:
> 
> https://patchwork.freedesktop.org/project/mesa/list/?submitter=14956
> 
> Would be good to get this into Mesa 19 before new color formats are
> added. Should be useful for new formats as well.

4 and 5 are:

Reviewed-by: Adam Jackson 

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: add toggle for TLS support in GLX

[Adam Jackson]

On Sat, 2019-01-26 at 13:56 +0100, Patrick Steinhardt wrote:

> Unfortunately, I'm not aware of any easy way to do this. The
> problem is not due to the compiler, as the program compiles and
> links just fine with musl libc. Instead, this is a runtime issue
> that happens when dlopen'ing shared objects with the
> "initial-exec" TLS model. And as far as I understand, the error
> only occurs if the PT_TLS segment size of the loaded shared
> object exceeds the space preallocated for it by the libc.

You can hit that failure mode with glibc too, it just requires many
more things trying to use TLS. Possibly we should reconsider whether
initial-exec is really that important for performance anymore or if we
can get away with global-dynamic.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 1/6] dri: Support 64 bit rgba masks

[Adam Jackson]

On Wed, 2019-01-16 at 17:58 +, Strasser, Kevin wrote:
> Adam Jackson wrote:
> 
> > Probably what I'd do is only define those masks to non-zero for <=32bpp 
> > formats,
> 
> Not sure if I understood this statement. Do you mean if we keep the _HI and 
> _LO
> attributes, only make them valid for formats that are <=64bpp, like fp16?

I was thinking:

a) Leave __DRI_ATTRIB_XXX_MASK in place, and simply set it to zero for
configs that don't fit in 32bpp

b) New attribute(s) for __DRI_ATTRIB_XXX_SHIFT, whose value is the
right-hand side of the << operator you'd use to find that channel

c) Fix dri2_add_config() and friends to work in terms of shifts not
masks

This nicely avoids worrying about just how wide a pixel will ever get
(ie how many _HI attribs you'd need for fp32, fp64, etc), because the
left-shift is a whole 32-bit integer, and we're almost certainly not
worried about needing a billion bits per channel. The only other
flexibility masks would give you is allowing discontiguous bit ranges
for color channels, but that's not a feature of any hardware we do or
will care about (and I'm not sure was ever really a thing, tbh).

Setting the MASK attribs to zero appears to magically DTRT when loading
a newer driver (with fp16 format support) on an older libEGL or
xserver; since the masks of the winsys' visuals will be non-zero, fp
formats will never match.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 1/6] dri: Support 64 bit rgba masks

[Adam Jackson]

On Wed, 2019-01-16 at 04:41 +, Strasser, Kevin wrote:
> Emil Velikov wrote:
> > 
> > Please split this up a bit. I'm thinking of:
> >  - dri_interface
> >  - mesa
> >  - egl
> >  - gbm
> >  - glx - seems sparse on updates, guessting you're followed in laster 
> > patches?
> 
> Sure, I can break it up a bit more. I didn't modify glx much as it doesn't 
> read
> the mask attributes directly, hence it can't handle configs with RGBA 
> ordering.
> I don't know the background of that limitation, but I assume there just hasn't
> been any use cases for those formats outside of Android, and so handling 
> hasn't
> been needed for glx... The intention of this series was to get fp16 working
> first for egl. Can we leave the glx side for if/when someone needs it there?

GLX handles RGBA ordering just fine. GLX doesn't expose channel
ordering because it inherits that from the X visual. But the only thing
you could do with fp16 in GLX is make a pbuffer out of it, because X
doesn't support >8bpc for windows or pixmaps, and there is no visual
corresponding to a pbuffer, so whatever channel order the hardware
wants is what you get.

That said, I note that GLX_ARB_color_buffer_float defines not just fp16
but fp32 formats, and EGL_EXT_pixel_format_float doesn't differ. If we
did want to support fp32 surfaces then simply widening attributes to 64
bits (or adding a "high" 32 bits) isn't going to be enough. Probably
what I'd do is only define those masks to non-zero for <=32bpp formats,
and add new attributes for channel left-shift instead. I realize this
contradicts what I said earlier, sorry about that.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 1/6] dri: Support 64 bit rgba masks

[Adam Jackson]

On Fri, 2019-01-11 at 15:01 +, Emil Velikov wrote:

> > @@ -460,6 +464,14 @@ driGetConfigAttribIndex(const __DRIconfig *config,
> > else
> > *value = 0;
> > break;
> > +case __DRI_ATTRIB_RED_MASK_HI:
> > +case __DRI_ATTRIB_GREEN_MASK_HI:
> > +case __DRI_ATTRIB_BLUE_MASK_HI:
> > +case __DRI_ATTRIB_ALPHA_MASK_HI:
> > +/* upper 32 bits of 64 bit fields */
> > +*value = *(unsigned int *)
> > +((char *) >modes + attribMap[index].offset + 4);
> 
> Is the "+ 4" going to work on big endian systems?

No.

I think I'd prefer to just expand config attribute values to 64-bit
across the board internally, rather than have paired 32-bit attributes
like this.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] specs: Bump GLX_MESA_query_renderer to version 9

[Adam Jackson]

Note that we have an official GL extension number, pick the appropriate
section of the GLX spec to modify, and add changelog.

Signed-off-by: Adam Jackson 
---
 docs/specs/MESA_query_renderer.spec | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/docs/specs/MESA_query_renderer.spec 
b/docs/specs/MESA_query_renderer.spec
index 0209efa1148..10f68ecc5dd 100644
--- a/docs/specs/MESA_query_renderer.spec
+++ b/docs/specs/MESA_query_renderer.spec
@@ -20,11 +20,11 @@ Status
 
 Version
 
-Version 8, 14-February-2014
+Version 9, 09 November 2018
 
 Number
 
-TBD.
+OpenGL Extension #446
 
 Dependencies
 
@@ -98,7 +98,7 @@ Additions to the OpenGL / WGL Specifications
 
 Additions to the GLX 1.4 Specification
 
-[Add the following to Section X.Y.Z of the GLX Specification]
+[Add to Section 3.3.2 "GLX Versioning" of the GLX Specification]
 
 To obtain information about the available renderers for a particular
 display and screen,
@@ -377,3 +377,9 @@ Revision History
 read GLX_RENDERER_ID_MESA. The VENDOR/DEVICE_ID
 example given in issue #17 should be 0x5143 and
 0x respectively.
+
+Version 9, 2018/11/09 - Remove GLX_RENDERER_ID_MESA, which has never been
+implemented. Remove the unnecessary interactions
+with the GLX GLES profile extensions. Note the
+official GL extension number. Specify the section
+of the GLX spec to modify.
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] specs: Remove GLES profile interaction text from GLX_MESA_query_renderer

[Adam Jackson]

In one place we say, if GLES isn't supported then the profile version
will be 0.0. Then later we say, if the GLES profile extension isn't
supported then GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA is not
mentioned in the spec. A strict reading of the latter would mean that
GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA is not a recognized token,
and the query should instead return False.

The implementation does not check for the GLES profile extensions, and
the additional complexity doesn't seem worth it. Removing the
interaction text makes the spec match the implementation.

Signed-off-by: Adam Jackson 
---
 docs/specs/MESA_query_renderer.spec | 12 
 1 file changed, 12 deletions(-)

diff --git a/docs/specs/MESA_query_renderer.spec 
b/docs/specs/MESA_query_renderer.spec
index dd45e02ba50..3b4a445cf88 100644
--- a/docs/specs/MESA_query_renderer.spec
+++ b/docs/specs/MESA_query_renderer.spec
@@ -32,9 +32,6 @@ Dependencies
 
 GLX_ARB_create_context and GLX_ARB_create_context_profile are required.
 
-This extension interacts with GLX_EXT_create_context_es2_profile and
-GLX_EXT_create_context_es_profile.
-
 Overview
 
 In many situations, applications want to detect characteristics of a
@@ -220,15 +217,6 @@ Additions to the GLX 1.4 Specification
   * If the value of GLX_RENDERER_ID_MESA specifies a non-existent
 renderer, BadMatch is generated.
 
-Dependencies on GLX_EXT_create_context_es_profile and
-GLX_EXT_create_context_es2_profile
-
-If neither extension is supported, remove all mention of
-GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA from the spec.
-
-If GLX_EXT_create_context_es_profile is not supported, remove all mention 
of
-GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA from the spec.
-
 Issues
 
 1) How should the difference between on-card and GART memory be exposed?
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/3] Update GLX_MESA_query_renderer spec

[Adam Jackson]

No functional change, just making the text match the implementation.
Will sync this to the Khronos registry once merged.

- ajax


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] specs: Remove GLX_RENDERER_ID_MESA from GLX_MESA_query_renderer

[Adam Jackson]

This has not even had an attempt at implementation. If you asked for
renderer 0 - which, the spec implies, should always work - then
dri2_convert_glx_attribs would fail, we'd silently fall back to creating
an indirect context, and xserver would also not recognize the attribute
and would throw BadValue at you.

The API would be difficult to use in any case, since there's no way to
enumerate how many renderers the screen has. I'd be tempted to add that
by defining:

glXQueryRendererIntegerMESA(dpy, screen,
/* renderer = */ -1,
0, );

to return the number of renderers, but a new entrypoint might be
cleaner. Still, better to not specify it at all than to lie about it.

Signed-off-by: Adam Jackson 
---
 docs/specs/MESA_query_renderer.spec | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/docs/specs/MESA_query_renderer.spec 
b/docs/specs/MESA_query_renderer.spec
index 3b4a445cf88..0209efa1148 100644
--- a/docs/specs/MESA_query_renderer.spec
+++ b/docs/specs/MESA_query_renderer.spec
@@ -92,11 +92,6 @@ New Tokens
 GLX_RENDERER_VENDOR_ID_MESA
 GLX_RENDERER_DEVICE_ID_MESA
 
-Accepted as an attribute name in <*attrib_list> in
-glXCreateContextAttribsARB:
-
-GLX_RENDERER_ID_MESA 0x818E
-
 Additions to the OpenGL / WGL Specifications
 
 None. This specification is written for GLX.
@@ -203,20 +198,6 @@ Additions to the GLX 1.4 Specification
 format as the string that would be returned by glGetString of GL_RENDERER.
 It may, however, have a different value.
 
-
-[Add to section section 3.3.7 "Rendering Contexts"]
-
-The attribute name GLX_RENDERER_ID_MESA specified the index of the render
-against which the context should be created.  The default value of
-GLX_RENDERER_ID_MESA is 0.
-
-
-[Add to list of errors for glXCreateContextAttribsARB in section section
-3.3.7 "Rendering Contexts"]
-
-  * If the value of GLX_RENDERER_ID_MESA specifies a non-existent
-renderer, BadMatch is generated.
-
 Issues
 
 1) How should the difference between on-card and GART memory be exposed?
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH EGL/MESA] EGL/mesa: Initial writeup for MESA_query_renderer

[Adam Jackson]

On Thu, 2018-11-08 at 02:42 +0530, Veluri Mithun wrote:
> Hi all,
> Thanks Adam for your interest in this.
> 
> > > +New Tokens
> > > +
> > > +Accepted as an  in EGLQueryRendererIntegerMESA and
> > > +EGLQueryCurrentRendererIntegerMESA:
> > > +
> > > +EGL_RENDERER_VENDOR_ID_MESA  0x
> > > +EGL_RENDERER_DEVICE_ID_MESA  0x
> 
>  
> except the above 2 tokens we aren't using any tokens in adriconf(
> https://github.com/jlHertel/adriconf/blob/master/DRIQuery.cpp#L46) If
> we don't need all the below ones, I'll remove them.

adriconf is not the only user of GLX_MESA_query_renderer. glxinfo uses
it and prints everything it can query, eglinfo would probably want to
do likewise.

> > The corresponding eglQueryCurrentRendererIntegerMESA is not documented.
> > I'm not entirely sure it should even exist, to be honest; I'd prefer if
> > these attributes were instead newly legal values to pass to
> > eglQueryContext. Too late to make that change for GLX I suppose.
>  
> What is the difference between EGLContext and EGLSurface?

Surfaces are window-system objects you can draw to. Contexts are
objects that describe how you'll draw (shader pipeline, blend modes,
etc.) The "current renderer" is the renderer associated with the
current context. Which means a call like:

eglQueryCurrentRendererIntegerMESA(EGL_RENDERER_VERSION_MESA,
   );

Would be equivalent to:

eglQueryContext(eglGetCurrentDisplay(),
eglGetCurrentContext(),
EGL_RENDERER_VERSION_MESA,
);

Which is why I said QueryCurrentRendererInteger is redundant. The other
three are not redundant.

> If you look at the usage of query fun in adriocnf(
> https://github.com/jlHertel/adriconf/blob/master/DRIQuery.cpp#L43).
> we are iterating with all the available screens. In Wayland do we
> need to iterate through contexts??

No; the question doesn't really make sense. GLX has screens only
because X11 has screens, they're sub-objects of the display. An
EGLDisplay corresponds to an X11 display+screen combination, so there's
nothing to iterate over.

Contexts aren't pre-existing objects like screens, they're things the
application explicitly creates. Notice that adriconf does not create a
context at all. This is sort of the point of GLX_MESA_query_renderer:
most of the information it supplies _could_ be discovered by querying
an existing context, but you'd rather know what kind of context you
_can_ create before you do it.
 
> @Jean Hertel In the above provided link, why are we passing 3rd
> argument(renderer) as 0 for all the screens?

As I said in my previous email: the GLX extension spec claims to allow
multiple renderers for a given display (and even to force a binding to
a particular one at creation time), but Mesa does not in fact implement
that, and it would be a difficult feature to use in any case because
there's no way to query how many renderers a display+screen actually
has.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH EGL/MESA] EGL/mesa: Initial write up for EGL_MESA_query_driver

[Adam Jackson]

On Mon, 2018-11-05 at 23:33 +0530, Veluri Mithun wrote:

> +New Procedures and Functions
> +
> +const char* EGLGetDriverConfig(const char *driverName);

This is difficult to implement in a GLVND environment. The frontend
would need a way to distinguish responses from the vendor library for
"I don't know of a driver by that name" and "I know that driver, but it
has no configuration".

Assuming we get EGL_EXT_device_base merged into Mesa it'd be cleaner to
have the first parameter here be an EGLDeviceEXT.

> +const char* EGLGetScreenDriver(EGLDisplay * dpy, int scrNum)

As with EGL_MESA_query_renderer: EGL doesn't have screens, and these
entrypoint names should start with 'egl' not 'EGL'.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH EGL/MESA] EGL/mesa: Initial writeup for MESA_query_renderer

[Adam Jackson]

On Mon, 2018-11-05 at 10:04 +0530, Veluri Mithun wrote:

> Signed-off-by: Veluri Mithun 

Thanks for looking into this! Many of these comments apply equally to
the GLX extension I think; if you wanted to write a patch for the
equivalent text for that extension too, that'd be awesome.

> +EGL 1.4 is required.

I'm not sure this is true, from the EGL types you're (currently) using
it looks like even an EGL 1.0 implementation could support this.
Probably better to say "EGL 1.0 is required; this extension is written
against the text of the EGL 1.4 specification."

> +EGL_ARB_create_context and EGL_ARB_create_context_profile are required.
> +
> +This extension interacts with EGL_EXT_create_context_es2_profile and
> +EGL_EXT_create_context_es_profile.

There are GLX extensions with almost these names, but not EGL:

https://www.khronos.org/registry/EGL/

These references should all be deleted.

> +New Procedures and Functions

EGL functions start with 'egl', lowercase.
> +Bool EGLQueryRendererIntegerMESA(EGLDisplay *dpy, int screen,
> + int renderer, int attribute,
> + unsigned int *value);

EGL displays don't have screens, that's an X11-ism. The screen
parameter should be deleted.

> +const char *EGLQueryRendererStringMESA(EGLDisplay *dpy, int screen,
> +   int renderer, int attribute);

Same comment about 'screen' here.

> +New Tokens
> +
> +Accepted as an  in EGLQueryRendererIntegerMESA and
> +EGLQueryCurrentRendererIntegerMESA:
> +
> +EGL_RENDERER_VENDOR_ID_MESA  0x
> +EGL_RENDERER_DEVICE_ID_MESA  0x
> +EGL_RENDERER_VERSION_MESA0x
> +EGL_RENDERER_ACCELERATED_MESA0x
> +EGL_RENDERER_VIDEO_MEMORY_MESA   0x
> +EGL_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_MESA0x
> +EGL_RENDERER_PREFERRED_PROFILE_MESA  0x
> +EGL_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA0x
> +EGL_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA0x
> +EGL_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA  0x
> +EGL_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA 0x
> + 
> +Accepted as an  in EGLQueryRendererStringMESA and
> +EGLQueryCurrentRendererStringMESA:
> +
> +EGL_RENDERER_VENDOR_ID_MESA
> +EGL_RENDERER_DEVICE_ID_MESA
> +
> +Accepted as an attribute name in <*attrib_list> in
> +EGLCreateContextAttribsARB:
> +
> +EGL_RENDERER_ID_MESA 0x

Normally these are reserved by creating a request against the EGL
registry on github. However we happen to have a block of 16 enum values
already reserved:

>  comment="Reserved for John Kre Alsaker (Public bug 757)">
> 
> 

That "public bug 757" is for the abandoned EGL_MESA_image_sRGB
extension:

https://www.khronos.org/bugzilla/show_bug.cgi?id=757

So I think it's safe to use enums from that range, and we'll still have
two free.

> +Additions to the EGL 1.4 Specification
> +
> +[Add the following to Section X.Y.Z of the EGL Specification]

Should be Section 3.3 "EGL Versioning". If this were against the EGL
1.5 text it'd be the more-obviously-correct Section 3.3 "EGL Queries".

> +To obtain information about the available renderers for a particular
> +display and screen,
> +
> +Bool EGLQueryRendererIntegerMESA(EGLDisplay *dpy, int screen, int 
> renderer,
> + int attribute, unsigned int *value);

The corresponding eglQueryCurrentRendererIntegerMESA is not documented.
I'm not entirely sure it should even exist, to be honest; I'd prefer if
these attributes were instead newly legal values to pass to
eglQueryContext. Too late to make that change for GLX I suppose.

> +String versions of some attributes may also be queried using
> +
> +const char *EGLQueryRendererStringMESA(EGLDisplay *dpy, int screen,
> +   int renderer, int attribute);

Likewise eglQueryCurrentRendererStringMESA is not documented. This
could not be queried with eglQueryContext since that can only return
integers not pointers.

> +[Add to section section 3.3.7 "Rendering Contexts"]
> +
> +The attribute name EGL_RENDERER_ID_MESA specified the index of the render
> +against which the context should be created.  The default value of
> +EGL_RENDERER_ID_MESA is 0.

This startled me to read, I didn't think GLX_MESA_query_renderer had
this. Turns out it does have this text in the extension spec, but the
functionality is not actually implemented. Worse, there's no way to
enumerate how many renderers a display (or display/screen in GLX) has.

To address this, I would:

1) Remove this text from both GLX and EGL extension specs
   (Both here and above 

Re: [Mesa-dev] [PATCH RFC] egl: Add a 565 pbuffer-only EGL config under X11.

[Adam Jackson]

On Tue, 2018-10-30 at 16:38 -0700, Eric Anholt wrote:
> Eric Anholt  writes:
> 
> > The CTS requires a 565-no-depth-no-stencil config for ES 3.0, but at depth
> > 24 of X11 we wouldn't do so.  We can satisfy that bad requirement using a
> > pbuffer-only visual with whatever other buffers the driver happens to have
> > given us.
> 
> Anyone?  Still concerned about getting Mesa to pass the current
> conformance suite.

I'm not thrilled with the CTS requiring R5G6B5 tbh. Do we know if
there's some rationale for that? Maybe something along the lines of,
"GLES target devices are likely to only support low depths, so even a
workstation GLES needs to implement low depths because otherwise how do
you know it works". Not that I'd endorse such reasoning.

To the patch itself:

> +   /* Add a 565 pbuffer-only config.  If X11 is depth 24, we wouldn't have 
> 565
> +* avialable, which the CTS demands.
   ^^
Typo.

> +*/
> +   for (int j = 0; dri2_dpy->driver_configs[j]; j++) {
> +  const __DRIconfig *config = dri2_dpy->driver_configs[j];
> +  const EGLint config_attrs[] = {
> + EGL_NATIVE_VISUAL_ID,0,
> + EGL_NATIVE_VISUAL_TYPE,  EGL_NONE,
> + EGL_NONE
> +  };

The commit message says you need no-depth and no-stencil, but you don't
enforce that here. Are we sure we don't need to?

> +  EGLint surface_type = EGL_PBUFFER_BIT;
> +  unsigned int rgba_masks[4] = {
> + 0x1f << 11,
> + 0x3f << 5,
> + 0x1f << 0,
> + 0,
> +  };
> +  if (dri2_add_config(disp, config, config_count + 1, surface_type,
> +  config_attrs, rgba_masks)) {
> + config_count++;
> + break;
> +  }
> +   }

This seems like it introduces a subtle dependency on how driver_configs
is ordered. I'm not sure you'd want your lone 565 pbuffer config to be
sRGB or multisampled. In fact in the latter case you'd end up with an
EGLConfig with zero bits set for EGL_SURFACE_TYPE, which is a bug in
dri2_add_config() I suppose.

That's probably not how driver_configs is sorted in reality, and
passing CTS is a valid thing to want, so with the above addressed:

Reviewed-by: Adam Jackson 

But if CTS can be fixed, let's do that too.

- ajax

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] meson: Add some presets for s390 and ppc

[Adam Jackson]

s390 doesn't have working llvm, so llvmpipe isn't an option. softpipe
might be more featureful but classic swrast is faster. s390x has working
llvm so we can build llvmpipe there.

ppc doesn't have working llvm either (so give it classic swrast too),
but at least it has a PCI bus you could maybe plug things into. Build
gallium nouveau and r300 there, they might not work very well but at
least PowerPC Macs had cards of that vintage. For ppc64 and ppc64le,
build the gallium drivers corresponding to PCIE cards, and llvmpipe.

For all of the above, don't build Vulkan drivers yet. radv should in
principle Just Work on ppc64le, but that's true of aarch64 too, and
we're not building radv by default there yet either.

Signed-off-by: Adam Jackson 
---
 meson.build | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/meson.build b/meson.build
index 97693b91ecf..71a19110d17 100644
--- a/meson.build
+++ b/meson.build
@@ -96,10 +96,11 @@ system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 
'dragonfly', 'linux'].cont
 _drivers = get_option('dri-drivers')
 if _drivers.contains('auto')
   if system_has_kms_drm
-# TODO: PPC, Sparc
 if ['x86', 'x86_64'].contains(host_machine.cpu_family())
   _drivers = ['i915', 'i965', 'r100', 'r200', 'nouveau']
-elif ['arm', 'aarch64'].contains(host_machine.cpu_family())
+elif ['s390', 'ppc'].contains(host_machine.cpu_family())
+  _drivers = ['swrast']
+elif ['arm', 'aarch64', 's390x', 'ppc64', 
'ppc64le'].contains(host_machine.cpu_family())
   _drivers = []
 else
   error('Unknown architecture @0@. Please pass -Ddri-drivers to set driver 
options. Patches gladly accepted to fix this.'.format(
@@ -126,7 +127,6 @@ with_dri = _drivers.length() != 0 and _drivers != ['']
 _drivers = get_option('gallium-drivers')
 if _drivers.contains('auto')
   if system_has_kms_drm
-# TODO: PPC, Sparc
 if ['x86', 'x86_64'].contains(host_machine.cpu_family())
   _drivers = [
 'r300', 'r600', 'radeonsi', 'nouveau', 'virgl', 'svga', 'swrast'
@@ -136,6 +136,20 @@ if _drivers.contains('auto')
 'pl111', 'v3d', 'vc4', 'freedreno', 'etnaviv', 'imx', 'nouveau',
 'tegra', 'virgl', 'swrast',
   ]
+elif ['ppc'].contains(host_machine.cpu_family())
+  _drivers = [
+'nouveau', 'r300',
+  ]
+elif ['ppc64', 'ppc64le'].contains(host_machine.cpu_family())
+  _drivers = [
+'r600', 'radeonsi', 'nouveau', 'swrast'
+  ]
+elif ['s390'].contains(host_machine.cpu_family())
+  _drivers = []
+elif ['s390x'].contains(host_machine.cpu_family())
+  _drivers = [
+'swrast'
+  ]
 else
   error('Unknown architecture @0@. Please pass -Dgallium-drivers to set 
driver options. Patches gladly accepted to fix this.'.format(
 host_machine.cpu_family()))
@@ -179,7 +193,7 @@ if _vulkan_drivers.contains('auto')
   if system_has_kms_drm
 if host_machine.cpu_family().startswith('x86')
   _vulkan_drivers = ['amd', 'intel']
-elif ['arm', 'aarch64'].contains(host_machine.cpu_family())
+elif ['arm', 'aarch64', 'ppc', 'ppc64', 'ppc64le', 's390', 
's390x'].contains(host_machine.cpu_family())
   _vulkan_drivers = []
 else
   error('Unknown architecture @0@. Please pass -Dvulkan-drivers to set 
driver options. Patches gladly accepted to fix this.'.format(
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs: Update FAQ with respect to s3tc support

[Adam Jackson]

On Wed, 2018-09-19 at 18:28 +1000, Stuart Young wrote:

> -4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa?
> +4.3 The GL_EXT_texture_compression_s3tc feature and Mesa?

This isn't really a question, so probably shouldn't end with a question
mark. I would leave the original question in place and...

>  
> -The  href="http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt;>specification
>  for the extension
> -indicates that there are intellectual property (IP) and/or patent issues
> -to be dealt with.
> +Prior to 2nd October 2017, the Mesa project did not include s3tc support due
> +to intellectual property (IP) and/or patent issues around the s3tc algorithm.
>  

... phrase it positively here, as in: "Oh, but it is! Prior to..."

With that:

Reviewed-by: Adam Jackson 

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Adam Jackson]

On Tue, 2018-09-18 at 13:50 -0700, Dylan Baker wrote:

> > It would be nice if meson would act like autotools in that regard by
> > creating the drivers and libraries in specific directories (also as a
> > configure option if there is concern about compilation speed). 
> 
> This is impossible by design. Meson is very specific that its internal 
> directory
> layout is an implementation detail. On top of that, there are two different
> backends, a VS and ninja backend, which have slightly different layouts.

I'm not entirely sure that's true? mesa/build-lib/meson.build could
have all the final link targets, and their results would show up in
mesa/${builddir}/build-lib. It'd mean mirroring all the "do I build
this target or not" logic in that meson.build, and you'd descend into
that directory last from the top-level mesa/meson.build, but...

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Why are pbuffers backed by a pixmaps (Was Re: [PATCH] egl: Fix leak of X11 pixmaps backing pbuffers in DRI3.)

[Adam Jackson]

On Mon, 2018-08-13 at 16:32 -0700, Kristian Høgsberg wrote:
> On Mon, Aug 13, 2018 at 3:53 AM Emil Velikov  wrote:
> > 
> > So if I understood you correctly [and the spec] there is no
> > requirement (nor ban) on rendering to pbuffers from X11.
> > It's an implementation decision to allow it.
> 
> You can't render to the underlying pixmaps, since the drawable ID is
> internal to the GLX implementation.

This might be a desirable property, but it's not what xserver
implements. req->pbuffer is the last argument (glxDrawableId) to
DoCreatePbuffer, which has:

/* Assign the pixmap the same id as the pbuffer and add it as a
 * resource so it and the DRI2 drawable will be reclaimed when the
 * pbuffer is destroyed. */
pPixmap->drawable.id = glxDrawableId;
if (!AddResource(pPixmap->drawable.id, RT_PIXMAP, pPixmap))
return BadAlloc;

See obviously bogus demo (attached), which succeeds instead of throwing
BadPixmap.

- ajax#include 
#include 

int main(void) {
Display *dpy;
GLXFBConfig *cfg;
GLXPbuffer pb;
int junk;
const int cfg_attr[] = {
GLX_DRAWABLE_TYPE, GLX_PBUFFER_BIT,
None,
};
const int pb_attr[] = {
GLX_PBUFFER_WIDTH, 32,
GLX_PBUFFER_HEIGHT, 32,
None,
};

dpy = XOpenDisplay(NULL);
cfg = glXChooseFBConfig(dpy, 0, cfg_attr, );
pb = glXCreatePbuffer(dpy, *cfg, pb_attr);

XFreePixmap(dpy, pb);
XSync(dpy, 0);

XCloseDisplay(dpy);
return 0;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Why are pbuffers backed by a pixmaps (Was Re: [PATCH] egl: Fix leak of X11 pixmaps backing pbuffers in DRI3.)

[Adam Jackson]

On Thu, 2018-08-09 at 18:22 +0100, Emil Velikov wrote:

> In the GLX case, it's required due to server-side rendering. One needs
> a separate primitive for each pbuffer, thus the information can be
> passed long the wire.

I can't parse this. "Primitive"?

So, backstory time. GLX_SGIX_pbuffer was the genesis of pbuffers.
Here's what it has to say about how a pbuffer is unlike other GLX
drawables (some of which is a comment about how things happened to work
on IRIX):

"GLXPbuffers are equivalent to GLXPixmaps with the following
exceptions:

1.  There is no associated X pixmap. Also, since a GLXPbuffer is a GLX
resource, it may not be possible to render to it using X or an 
X extension other than GLX.

2.  The format of the color buffers and the type and size of any
associated ancillary buffers for a GLXPbuffer can only be
described with a GLXFBConfig -- an X Visual cannot be used.

3.  It is possible to create a GLXPbuffer whose contents may be 
asynchronously lost at any time.

4.  GLXPbuffers can be rendered to using either direct or indirect
rendering contexts.

5.  The allocation of a GLXPbuffer can fail if there are insufficient
resources (i.e., all the pbuffer memory has been allocated and 
the implementation does not virtualize pbuffer memory.)"

In contrast, a GLXPixmap _must_ be renderable by X11, cannot lose its
contents, and _may_ not be renderable by direct contexts. All of this
dates to like 1997, so we didn't have FBOs yet, and any rendering
surface would have been allocated by "the server" [1]. That extension
was merged into GLX 1.3 pretty much unchanged, and GLX 1.3 was 1998. 

Xorg didn't get GLX 1.3 working until like 2007 [2]. As an
implementation choice, Xorg _does_ back pbuffers with pixmaps, both in
that it calls ->CreatePixmap internally to make them and that it tracks
them as actual pixmaps [3]. We never clobber pbuffers, we have no
problem rendering to pbuffers from X11, and we have no problem
rendering to GLXPixmaps from direct contexts. Effectively, other than
the resource type, the difference between a pbuffer and a glxpixmap is
that the latter takes two XIDs and two resource creation calls.

EGL dates to 2003, which means it predates even EXT_framebuffer_object,
so the pbuffer bit of GLX was kept in the new API. The EGL spec says a
pbuffer has no associated native window or native window type - no
kidding, it's not a window - but it does not require that a pbuffer
have no native object backing it at all.

Now, direct rendering in GLX is underspecified; the implementation is
free to use whatever subset of GLX, and whatever private protocol, it
wants. In principle the client could allocate the pbuffer's storage
from the "server" (the drm, here), and pass that handle and its new XID
name to the X server to bind them together so indirect contexts can
name it as well.

An EGL implementation could take even more liberties. Even on an X11
window system there's no intrinsic reason that an EGL pbuffer need to
exist as a native winsys object; all that's required is that pbuffers
work with any API that takes an EGLSurface parameter. You might choose
to mirror EGL surfaces as GLX objects, or not, whatever your
implementation finds convenient. In practice, we back pbuffers with
pixmaps because we also back pixmaps with pixmaps, and there's no
reason to make those paths diverge more than they have to.

[1] - Even in this old IRIXy context, "the server" doesn't necessarily
mean the X server, it means the rendering services provided by the OS;
but as pbuffers have an XID, the X server is where this allocation
happens from the GLX app's perspective, regardless of what OS services
xserver (or libGL) invokes to make that happen.

[2] - Some of that was embarassment, as GLX_EXT_texture_from_pixmap
technically requires 1.3, and we were cheating. Some of it was that the
GLX code at this point was under SGI FreeB 1.1, and we were all
pretending that was okay to distribute, but were hesitant to make
changes due to the license terms being unpleasant.

[3] - XDestroyPixmap(glXCreatePbuffer()) ought to throw GLXBadDrawable,
not succeed, so this latter behavior is a bug and probably a spec
violation.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Fix leak of X11 pixmaps backing pbuffers in DRI3.

[Adam Jackson]

On Thu, 2018-08-09 at 17:20 +0100, Emil Velikov wrote:

> If you have a moment, I'd be interested to know why we're creating a X
> primitive for pbuffer surface.
> IIRC pbuffers are used of off-screen rendering, thus having zero
> knowledge/dependency on the underlying platform.

pbuffers might be offscreen, but they're still window-system objects.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: GLX_MESA_multithread_makecurrent is direct-only

[Adam Jackson]

On Thu, 2018-08-09 at 15:54 +0300, Andres Gomez wrote:
> Adam, which is the status of this patch? Is this effectively dropped?

It's still valid, and still not very important. I'd just forgotten it.
Merged now, thanks for the reminder:

remote: remote: I: patch #191858 updated using rev 
63a6b719d98fb1ad58ae93c2de859e6d4bfa8b8b
remote: remote: I: 1 patch(es) updated to state Accepted.
remote: remote:   % Total% Received % Xferd  Average Speed   TimeTime   
  Time  Current
remote: remote:  Dload  Upload   Total   Spent  
  Left  Speed
remote: remote:   0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0
remote: To ssh://kemper.freedesktop.org/git/mesa/mesa
remote:fcf259ef97..63a6b719d9  63a6b719d98fb1ad58ae93c2de859e6d4bfa8b8b -> 
master
To gitlab.freedesktop.org:mesa/mesa.git
   fcf259ef97f..63a6b719d98  master -> master

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glx: Demand success from CreateContext requests (v2)

[Adam Jackson]

GLXCreate{,New}Context, like most X resource creation requests, does not
emit a reply and therefore is emitted into the X stream asynchronously.
However, unlike most resource creation requests, the GLXContext we
return is a handle to library state instead of an XID. So if context
creation fails for any reason - say, the server doesn't support indirect
contexts - then we will fail in strange places for strange reasons.

We could make every GLX entrypoint robust against half-created contexts,
or we could just verify that context creation worked. Reuse the
__glXIsDirect code to do this, as a cheap way of verifying that the
XID is real.

glXCreateContextAttribsARB solves this by using the _checked version of
the xcb command, so effectively this change makes the classic context
creation paths as robust as CreateContextAttribs.

v2: Better use of Bool, check that error != NULL first (Olivier Fourdan)

Signed-off-by: Adam Jackson 
---
 src/glx/glxcmds.c | 93 ---
 1 file changed, 55 insertions(+), 38 deletions(-)

diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 4db0228eaba..3ed960fbf3c 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -272,6 +272,44 @@ glx_context_init(struct glx_context *gc,
return True;
 }
 
+/**
+ * Determine if a context uses direct rendering.
+ *
+ * \param dpyDisplay where the context was created.
+ * \param contextID  ID of the context to be tested.
+ * \param error  Out parameter, set to True on error if not NULL
+ *
+ * \returns \c True if the context is direct rendering or not.
+ */
+static Bool
+__glXIsDirect(Display * dpy, GLXContextID contextID, Bool *error)
+{
+   CARD8 opcode;
+   xcb_connection_t *c;
+   xcb_generic_error_t *err;
+   xcb_glx_is_direct_reply_t *reply;
+   Bool is_direct;
+
+   opcode = __glXSetupForCommand(dpy);
+   if (!opcode) {
+  return False;
+   }
+
+   c = XGetXCBConnection(dpy);
+   reply = xcb_glx_is_direct_reply(c, xcb_glx_is_direct(c, contextID), );
+   is_direct = (reply != NULL && reply->is_direct) ? True : False;
+
+   if (err != NULL) {
+  if (error)
+ *error = True;
+  __glXSendErrorForXcb(dpy, err);
+  free(err);
+   }
+
+   free(reply);
+
+   return is_direct;
+}
 
 /**
  * Create a new context.
@@ -376,6 +414,21 @@ CreateContext(Display *dpy, int generic_id, struct 
glx_config *config,
gc->share_xid = shareList ? shareList->xid : None;
gc->imported = GL_FALSE;
 
+   /* Unlike most X resource creation requests, we're about to return a handle
+* with client-side state, not just an XID. To simplify error handling
+* elsewhere in libGL, force a round-trip here to ensure the CreateContext
+* request above succeeded.
+*/
+   {
+  Bool error = False;
+  int isDirect = __glXIsDirect(dpy, gc->xid, );
+
+  if (error != False || isDirect != gc->isDirect) {
+ gc->vtable->destroy(gc);
+ gc = NULL;
+  }
+   }
+
return (GLXContext) gc;
 }
 
@@ -612,42 +665,6 @@ glXCopyContext(Display * dpy, GLXContext source_user,
 }
 
 
-/**
- * Determine if a context uses direct rendering.
- *
- * \param dpyDisplay where the context was created.
- * \param contextID  ID of the context to be tested.
- *
- * \returns \c True if the context is direct rendering or not.
- */
-static Bool
-__glXIsDirect(Display * dpy, GLXContextID contextID)
-{
-   CARD8 opcode;
-   xcb_connection_t *c;
-   xcb_generic_error_t *err;
-   xcb_glx_is_direct_reply_t *reply;
-   Bool is_direct;
-
-   opcode = __glXSetupForCommand(dpy);
-   if (!opcode) {
-  return False;
-   }
-
-   c = XGetXCBConnection(dpy);
-   reply = xcb_glx_is_direct_reply(c, xcb_glx_is_direct(c, contextID), );
-   is_direct = (reply != NULL && reply->is_direct) ? True : False;
-
-   if (err != NULL) {
-  __glXSendErrorForXcb(dpy, err);
-  free(err);
-   }
-
-   free(reply);
-
-   return is_direct;
-}
-
 /**
  * \todo
  * Shouldn't this function \b always return \c False when
@@ -668,7 +685,7 @@ glXIsDirect(Display * dpy, GLXContext gc_user)
 #ifdef GLX_USE_APPLEGL  /* TODO: indirect on darwin */
return False;
 #else
-   return __glXIsDirect(dpy, gc->xid);
+   return __glXIsDirect(dpy, gc->xid, NULL);
 #endif
 }
 
@@ -1428,7 +1445,7 @@ glXImportContextEXT(Display *dpy, GLXContextID contextID)
   return NULL;
}
 
-   if (__glXIsDirect(dpy, contextID))
+   if (__glXIsDirect(dpy, contextID, NULL))
   return NULL;
 
opcode = __glXSetupForCommand(dpy);
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glx: Demand success from CreateContext requests

[Adam Jackson]

GLXCreate{,New}Context, like most X resource creation requests, does not
emit a reply and therefore is emitted into the X stream asynchronously.
However, unlike most resource creation requests, the GLXContext we
return is a handle to library state instead of an XID. So if context
creation fails for any reason - say, the server doesn't support indirect
contexts - then we will fail in strange places for strange reasons.

We could make every GLX entrypoint robust against half-created contexts,
or we could just verify that context creation worked. Reuse the
__glXIsDirect code to do this, as a cheap way of verifying that the
XID is real.

glXCreateContextAttribsARB solves this by using the _checked version of
the xcb command, so effectively this change makes the classic context
creation paths as robust as CreateContextAttribs.

Signed-off-by: Adam Jackson 
---
 src/glx/glxcmds.c | 92 +++
 1 file changed, 54 insertions(+), 38 deletions(-)

diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 4db0228eaba..3789f55d038 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -272,6 +272,43 @@ glx_context_init(struct glx_context *gc,
return True;
 }
 
+/**
+ * Determine if a context uses direct rendering.
+ *
+ * \param dpyDisplay where the context was created.
+ * \param contextID  ID of the context to be tested.
+ * \param error  Out parameter, set to True on error if not NULL
+ *
+ * \returns \c True if the context is direct rendering or not.
+ */
+static Bool
+__glXIsDirect(Display * dpy, GLXContextID contextID, int *error)
+{
+   CARD8 opcode;
+   xcb_connection_t *c;
+   xcb_generic_error_t *err;
+   xcb_glx_is_direct_reply_t *reply;
+   Bool is_direct;
+
+   opcode = __glXSetupForCommand(dpy);
+   if (!opcode) {
+  return False;
+   }
+
+   c = XGetXCBConnection(dpy);
+   reply = xcb_glx_is_direct_reply(c, xcb_glx_is_direct(c, contextID), );
+   is_direct = (reply != NULL && reply->is_direct) ? True : False;
+
+   if (err != NULL) {
+  *error = True;
+  __glXSendErrorForXcb(dpy, err);
+  free(err);
+   }
+
+   free(reply);
+
+   return is_direct;
+}
 
 /**
  * Create a new context.
@@ -376,6 +413,21 @@ CreateContext(Display *dpy, int generic_id, struct 
glx_config *config,
gc->share_xid = shareList ? shareList->xid : None;
gc->imported = GL_FALSE;
 
+   /* Unlike most X resource creation requests, we're about to return a handle
+* with client-side state, not just an XID. To simplify error handling
+* elsewhere in libGL, force a round-trip here to ensure the CreateContext
+* request above succeeded.
+*/
+   {
+  int error = None;
+  int isDirect = __glXIsDirect(dpy, gc->xid, );
+
+  if (error != None || isDirect != gc->isDirect) {
+ gc->vtable->destroy(gc);
+ gc = NULL;
+  }
+   }
+
return (GLXContext) gc;
 }
 
@@ -612,42 +664,6 @@ glXCopyContext(Display * dpy, GLXContext source_user,
 }
 
 
-/**
- * Determine if a context uses direct rendering.
- *
- * \param dpyDisplay where the context was created.
- * \param contextID  ID of the context to be tested.
- *
- * \returns \c True if the context is direct rendering or not.
- */
-static Bool
-__glXIsDirect(Display * dpy, GLXContextID contextID)
-{
-   CARD8 opcode;
-   xcb_connection_t *c;
-   xcb_generic_error_t *err;
-   xcb_glx_is_direct_reply_t *reply;
-   Bool is_direct;
-
-   opcode = __glXSetupForCommand(dpy);
-   if (!opcode) {
-  return False;
-   }
-
-   c = XGetXCBConnection(dpy);
-   reply = xcb_glx_is_direct_reply(c, xcb_glx_is_direct(c, contextID), );
-   is_direct = (reply != NULL && reply->is_direct) ? True : False;
-
-   if (err != NULL) {
-  __glXSendErrorForXcb(dpy, err);
-  free(err);
-   }
-
-   free(reply);
-
-   return is_direct;
-}
-
 /**
  * \todo
  * Shouldn't this function \b always return \c False when
@@ -668,7 +684,7 @@ glXIsDirect(Display * dpy, GLXContext gc_user)
 #ifdef GLX_USE_APPLEGL  /* TODO: indirect on darwin */
return False;
 #else
-   return __glXIsDirect(dpy, gc->xid);
+   return __glXIsDirect(dpy, gc->xid, NULL);
 #endif
 }
 
@@ -1428,7 +1444,7 @@ glXImportContextEXT(Display *dpy, GLXContextID contextID)
   return NULL;
}
 
-   if (__glXIsDirect(dpy, contextID))
+   if (__glXIsDirect(dpy, contextID, NULL))
   return NULL;
 
opcode = __glXSetupForCommand(dpy);
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: Add checks for context being direct before calling GetGLXDRIDrawable

[Adam Jackson]

On Wed, 2018-08-01 at 17:15 +0300, Danylo Piliaiev wrote:
> If indirect context is explicitly created by application and not
> with LIBGL_ALWAYS_INDIRECT=1 then dri may be initialized in
> __glXInitialize which allows Mesa to take invalid code paths
> due to GetGLXDRIDrawable returning non-null value.

This doesn't make any sense. Initializing DRI doesn't add any GLX
drawables to the hash, unless something deeply insane is going on.

> In most such places there are already checks for context being
> direct before calling GetGLXDRIDrawable. This patch adds checks
> where they were missed.

These checks are pretty much all wrong. Whether a drawable has direct
context state is orthogonal to whether the current context is direct,
you could have two contexts with different directness.

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42699
> 
> Signed-off-by: Danylo Piliaiev 
> ---
>  src/glx/glx_pbuffer.c | 12 ++--
>  src/glx/glxcmds.c |  3 +++
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
> index fd3327f120..6ee2ed58d2 100644
> --- a/src/glx/glx_pbuffer.c
> +++ b/src/glx/glx_pbuffer.c
> @@ -133,6 +133,10 @@ ChangeDrawableAttribute(Display * dpy, GLXDrawable 
> drawable,
> SyncHandle();
>  
>  #ifdef GLX_DIRECT_RENDERING
> +   struct glx_context *gc = __glXGetCurrentContext();
> +   if (!gc->isDirect)
> +  return;
> +

This is saying "if the current context is direct, then refuse to tell
the server that we want to change this drawable", which can't be right.

> @@ -316,7 +320,11 @@ __glXGetDrawableAttribute(Display * dpy, GLXDrawable 
> drawable,
>return 0;
>  
>  #if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)
> -   pdraw = GetGLXDRIDrawable(dpy, drawable);
> +   struct glx_context *gc = __glXGetCurrentContext();
> +
> +   if (gc->isDirect) {
> +  pdraw = GetGLXDRIDrawable(dpy, drawable);
> +   }

Again, whether the drawable has DRI state attached to it is not a
property of the current context.

I don't see how the existing code would be wrong to begin with. Even if
__glXInitialize does set up DRI state on the screen, it's not going to
add any drawables to the hash table, so this should still hit the pdraw
== NULL case below it safely.

> if (attribute == GLX_BACK_BUFFER_AGE_EXT) {
>struct glx_context *gc = __glXGetCurrentContext();
> diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
> index 4db0228eab..3eb86b02a9 100644
> --- a/src/glx/glxcmds.c
> +++ b/src/glx/glxcmds.c
> @@ -799,6 +799,8 @@ glXDestroyGLXPixmap(Display * dpy, GLXPixmap glxpixmap)
> DestroyGLXDrawable(dpy, glxpixmap);
>  
>  #if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)
> +   struct glx_context *gc = __glXGetCurrentContext();
> +   if (gc->isDirect)
> {
>struct glx_display *const priv = __glXInitialize(dpy);
>__GLXDRIdrawable *pdraw = GetGLXDRIDrawable(dpy, glxpixmap);

I believe this would introduce a leak case. If your current context is
indirect, and you glXDestroyGLXPixmap() on a pixmap with DRI state,
you'll never free that DRI state.

> @@ -831,6 +833,7 @@ glXSwapBuffers(Display * dpy, GLXDrawable drawable)
> gc = __glXGetCurrentContext();
>  
>  #if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)
> +   if (gc->isDirect)
> {
>__GLXDRIdrawable *pdraw = GetGLXDRIDrawable(dpy, drawable);
>  

The real problem here, I think, is that we need to store what kind of
DRI a given DRI drawable is, and look up its SwapBuffer method based on
that. Instead we just have one method for the whole screen, so if the
screen happens to support DRI3 and DRISW...

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] add a config file for dri loader to choose a different dri driver

[Adam Jackson]

On Tue, 2018-07-31 at 08:03 +, Yu, Qiang wrote:
> Seems the mesa driconf infrastructure is just what I need:
> https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/
> 
> So I can reference the loader_get_dri_config_device_id implementation
> for adding loader driver override functionality in /etc/drirc:
> 
>   
> 
>   
> 
> 
> Thoughts?

If you're going to go down this route, please also teach Mesa to look
for drirc (or drirc.d) under /usr/share first, then /etc. /etc really
is for per-machine configuration, Mesa and driver defaults properly
belong in /usr/share.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Make glXChooseFBConfig handle unspecified sRGB correctly

[Adam Jackson]

On Mon, 2018-07-30 at 12:14 -0700, Eric Anholt wrote:
> Jon Turney  writes:
> 
> > Make glXChooseFBConfig properly handle the case where the only matching
> > configs have the sRGB flag set, but no sRGB attribute is specified.
> > 
> > Since 6e06e281, the sRGBcapable flag is now actually compared, using
> > MATCH_DONT_CARE.
> > 
> > 7b0f912e added defaulting of sRGBcapable to GL_FALSE in
> > __glXInitializeVisualConfigFromTags(), to handle servers which don't report
> > it, but this function is also used by glXChooseFBConfig(), so sRGBcapable is
> > implicitly false when not explicitly specified.
> > 
> > (This can cause e.g. glxinfo to fail to find anything matching the simple
> > config it looks for if all the candidates have the sRGB flag set to true.
> > I'm assuming this doesn't happen 'normally' as candidate configs with and
> > without sRGB true are available)
> > 
> > Move this defaulting to createConfigsFromProperties(), and set the default
> > for glXChooseFBConfig() in init_fbconfig_for_chooser() to GLX_DONT_CARE.
> 
> Reviewed-by: Eric Anholt 

This change looks sane, but I note that the extension doesn't actually
specify how we're supposed to handle this attribute. I've filed a spec
bug, in the vague hope that that'll be addressed someday:

https://github.com/KhronosGroup/OpenGL-Registry/issues/199

Regardless, patch merged, thanks:

To gitlab.freedesktop.org:mesa/mesa.git
   03a61b977e1..faa29c0e244  master -> master

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] dri3: For 1.2, use root window instead of pixmap drawable

[Adam Jackson]

On Fri, 2018-07-27 at 16:16 +0200, Olivier Fourdan wrote:
> Hi,
> 
> On Thu, 26 Jul 2018 at 19:53, Eric Anholt  wrote:
> > 
> > Olivier Fourdan  writes:
> > 
> > > get_supported_modifiers() and pixmap_from_buffers() requests both
> > > expect a window as drawable, passing a pixmap will fail as the Xserver
> > > will fail to match the given drawable to a window.
> > > 
> > > That leads to dri3_alloc_render_buffer() to return NULL and breaks
> > > rendering when using GLX_DOUBLEBUFFER on pixmaps.
> > > 
> > > Query the root window of the pixmap on first init, and use the root
> > > window instead of the pixmap drawable for get_supported_modifiers()
> > > and pixmap_from_buffers().
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107117
> > > Fixes: 069fdd5 ("egl/x11: Support DRI3 v1.1")
> > > Signed-off-by: Olivier Fourdan 
> > 
> > Looks great!
> > 
> > Reviewed-by: Eric Anholt 
> 
> Thanks both Daniel and Eric for the reviews!
> 
> If I may, could someone push that fix for me, I don't think I have
> commit rights in Mesa...
> 
> (It's a regression affecting Mesa 18.1 with Xserver 1.20, would be
> great to have it fixed)

Merged, thanks:

To gitlab.freedesktop.org:mesa/mesa.git
   16b5e15e918..03a61b977e1  master -> master

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] swrast: Fix eglMakeCurrent(dpy, NULL, NULL, ctx) (v2)

[Adam Jackson]

Fixes 14 piglits, mostly in egl_khr_create_context.

v2: Also short-circuit the same-context-no-drawables case (Eric Anholt)

Fixes: https://github.com/anholt/libepoxy/issues/177
Signed-off-by: Adam Jackson 
---
 src/mesa/drivers/dri/swrast/swrast.c | 37 ++--
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/src/mesa/drivers/dri/swrast/swrast.c 
b/src/mesa/drivers/dri/swrast/swrast.c
index ae5874f5927..a88ece97f3b 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/swrast.c
@@ -675,6 +675,9 @@ swrast_check_and_update_window_size( struct gl_context 
*ctx, struct gl_framebuff
 {
 GLsizei width, height;
 
+if (!fb)
+return;
+
 get_window_size(fb, , );
 if (fb->Width != width || fb->Height != height) {
_mesa_resize_framebuffer(ctx, fb, width, height);
@@ -857,30 +860,26 @@ dri_make_current(__DRIcontext * cPriv,
 __DRIdrawable * driReadPriv)
 {
 struct gl_context *mesaCtx;
-struct gl_framebuffer *mesaDraw;
-struct gl_framebuffer *mesaRead;
+struct gl_framebuffer *mesaDraw = NULL;
+struct gl_framebuffer *mesaRead = NULL;
 TRACE;
 
 if (cPriv) {
-   struct dri_context *ctx = dri_context(cPriv);
-   struct dri_drawable *draw;
-   struct dri_drawable *read;
+mesaCtx = _context(cPriv)->Base;
 
-   if (!driDrawPriv || !driReadPriv)
-   return GL_FALSE;
+   if (driDrawPriv && driReadPriv) {
+   struct dri_drawable *draw = dri_drawable(driDrawPriv);
+   struct dri_drawable *read = dri_drawable(driReadPriv);
+   mesaDraw = >Base;
+   mesaRead = >Base;
+}
 
-   draw = dri_drawable(driDrawPriv);
-   read = dri_drawable(driReadPriv);
-   mesaCtx = >Base;
-   mesaDraw = >Base;
-   mesaRead = >Base;
-
-   /* check for same context and buffer */
-   if (mesaCtx == _mesa_get_current_context()
-   && mesaCtx->DrawBuffer == mesaDraw
-   && mesaCtx->ReadBuffer == mesaRead) {
-   return GL_TRUE;
-   }
+/* check for same context and buffer */
+if (mesaCtx == _mesa_get_current_context()
+&& mesaCtx->DrawBuffer == mesaDraw
+&& mesaCtx->ReadBuffer == mesaRead) {
+return GL_TRUE;
+}
 
_glapi_check_multithread();
 
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glx: Don't allow glXMakeContextCurrent() with only one valid drawable

[Adam Jackson]

Drawable and readable need to either both be None or both be non-None.

Cc: 
Signed-off-by: Adam Jackson 
---
 src/glx/glxcurrent.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/glx/glxcurrent.c b/src/glx/glxcurrent.c
index fd04929b89f..2b9c708c3ee 100644
--- a/src/glx/glxcurrent.c
+++ b/src/glx/glxcurrent.c
@@ -194,6 +194,13 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
   return True;
}
 
+   /* can't have only one be 0 */
+   if (!!draw != !!read) {
+  __glXUnlock();
+  __glXSendError(dpy, BadMatch, None, X_GLXMakeContextCurrent, True);
+  return False;
+   }
+
if (oldGC != ) {
   if (--oldGC->thread_refcount == 0) {
 oldGC->vtable->unbind(oldGC, gc);
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swrast: Fix eglMakeCurrent(dpy, NULL, NULL, ctx)

[Adam Jackson]

On Fri, 2018-07-06 at 10:29 +0100, Emil Velikov wrote:

> Skimming through the egl_khr_create_context text, this relaxes some
> parts which are meant to be an error.
> For example
> 
>   * If either of  or  is a valid surface and the other
> is EGL_NO_SURFACE, an EGL_BAD_MATCH error is generated.

That seems like an invariant EGL promises for the driver, not something
the driver validates. eglMakeCurrent already says:

  if ((!draw_surf && draw != EGL_NO_SURFACE) ||
  (!read_surf && read != EGL_NO_SURFACE))
 RETURN_EGL_ERROR(disp, EGL_BAD_SURFACE, EGL_FALSE);

glXMakeCurrent doesn't seem to have code to generate an error in that
case, anymore. The server would throw an error for the GLXMakeCurrent
request, but we don't always emit those for... bad reasons. Regardless
I'd say that check belongs in MakeContextCurrent, not the driver.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] swrast: Fix eglMakeCurrent(dpy, NULL, NULL, ctx)

[Adam Jackson]

Fixes 14 piglits, mostly in egl_khr_create_context.

Fixes: https://github.com/anholt/libepoxy/issues/177
Signed-off-by: Adam Jackson 
---
 src/mesa/drivers/dri/swrast/swrast.c | 34 +++-
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/swrast/swrast.c 
b/src/mesa/drivers/dri/swrast/swrast.c
index ae5874f5927..7f08107c24f 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/swrast.c
@@ -675,6 +675,9 @@ swrast_check_and_update_window_size( struct gl_context 
*ctx, struct gl_framebuff
 {
 GLsizei width, height;
 
+if (!fb)
+return;
+
 get_window_size(fb, , );
 if (fb->Width != width || fb->Height != height) {
_mesa_resize_framebuffer(ctx, fb, width, height);
@@ -857,30 +860,29 @@ dri_make_current(__DRIcontext * cPriv,
 __DRIdrawable * driReadPriv)
 {
 struct gl_context *mesaCtx;
-struct gl_framebuffer *mesaDraw;
-struct gl_framebuffer *mesaRead;
+struct gl_framebuffer *mesaDraw = NULL;
+struct gl_framebuffer *mesaRead = NULL;
 TRACE;
 
 if (cPriv) {
-   struct dri_context *ctx = dri_context(cPriv);
struct dri_drawable *draw;
struct dri_drawable *read;
 
-   if (!driDrawPriv || !driReadPriv)
-   return GL_FALSE;
+mesaCtx = _context(cPriv)->Base;
 
-   draw = dri_drawable(driDrawPriv);
-   read = dri_drawable(driReadPriv);
-   mesaCtx = >Base;
-   mesaDraw = >Base;
-   mesaRead = >Base;
+   if (driDrawPriv && driReadPriv) {
+   draw = dri_drawable(driDrawPriv);
+   read = dri_drawable(driReadPriv);
+   mesaDraw = >Base;
+   mesaRead = >Base;
 
-   /* check for same context and buffer */
-   if (mesaCtx == _mesa_get_current_context()
-   && mesaCtx->DrawBuffer == mesaDraw
-   && mesaCtx->ReadBuffer == mesaRead) {
-   return GL_TRUE;
-   }
+   /* check for same context and buffer */
+   if (mesaCtx == _mesa_get_current_context()
+   && mesaCtx->DrawBuffer == mesaDraw
+   && mesaCtx->ReadBuffer == mesaRead) {
+   return GL_TRUE;
+   }
+}
 
_glapi_check_multithread();
 
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Adam Jackson]

On Fri, 2018-06-15 at 11:23 -0600, Kyle Brenneman wrote:

> The Khronos repository basically is a package for the headers. The 
> challenge is that the pkg-config file has to specify an include path and 
> a library path. The include path depends on where you put the header 
> files (which are in the Khronos repository), but library path depends on 
> how you configure libglvnd.
> 
> The libglvnd tree probably does make the most sense: That's where the 
> libraries are from, and so it should be the only thing you need to build 
> and link an OpenGL application. It also has a copy of the GL header 
> files that it uses to build. It could install those copies, but the 
> challenge then is keeping libglvnd's copy of the header files up to date.

To be honest, that's something that needs better automation anyway.
Epoxy and Mesa want to track the xml updates closely too. I've set up
cron jobs in travis to check daily whether the xml has been changed, so
I'll at least get notifications:

https://travis-ci.org/nwnk/OpenGL-Registry
https://travis-ci.org/nwnk/EGL-Registry

It would be good to close the loop there and automate the process of
importing the XML, rebuilding, checking for ABI breaks...

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] add project README

[Adam Jackson]

On Fri, 2018-06-08 at 16:57 +0100, Eric Engestrom wrote:

> +Build & install
> +---
> +
> +You can find more information in our documentation (`docs/install.html
> +`_), but the recommdended way is to use

'recommended'

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GitLab migration update

[Adam Jackson]

On Thu, 2018-06-07 at 08:25 +0100, Daniel Stone wrote:

> The following dormant repos were _not_ migrated, but can be migrated
> (perhaps to an archive/ section?) if they are still useful:
>   clover glw libwsbm linux-agp-compat r600_demo rbug-gui

Eek. glw has a bugfix in it from me I don't even remember writing, and
then never followed with a release. I have at least one OS shipping
with it so I should probably make sure it continues to have a home.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GitLab personal repos

[Adam Jackson]

On Sat, 2018-06-02 at 13:10 -0400, Rob Clark wrote:
> On Sat, Jun 2, 2018 at 12:07 PM, Jason Ekstrand  wrote:
> >  1) Forks share objects behind the user's back so it should use
> > significantly less space on the GitLab server if everyone's personal mesa
> > repo is an actual GitLab fork and not a bare repo that they pushed.

It'd be cool if gitlab could figure out object sharing without this,
but I totally understand why that's hard.

> kinda on the topic, but not directly related to mesa.. at least a few
> of us have private kernel trees on p.fd.o, and kernel git trees are
> *much* bigger.  Will there be (or is there already) a gitlab kernel
> tree that we could recreate our private kernel trees from, to share
> objects?
> 
> I guess since it is mostly stuff that feeds into drm-next, maybe
> Dave's drm-next tree should move to gitlab, and then others fork off
> of that?

A fresh clone's linux/.git is about 2.3G at the moment. That's probably
not a huge burden in terms of just storage, but might be bad in terms
of I/O (since identical data competing for page cache is silly), so
having a standard kernel tree mirror does sound wise.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: Fix number of property values to read in glXImportContextEXT

[Adam Jackson]

On Fri, 2018-06-01 at 19:01 +0200, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> We were trying to read twice as many as the X server sent us, which
> upset XCB:
> 
> [xcb] Too much data requested from _XRead
> [xcb] This is most likely caused by a broken X extension library
> [xcb] Aborting, sorry about that.
> glx-free-context: ../../src/xcb_io.c:732: _XRead: Assertion 
> `!xcb_xlib_too_much_data_requested' failed.
> 
> Fixing this takes 3 GLX piglit tests from crash to pass.
> 
> Fixes: 085216295033 "glx: Be more tolerant in glXImportContext (v2)"
> Signed-off-by: Michel Dänzer 

Ugh. Truly embarrassing.

Reviewed-by: Adam Jackson 

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] drisw Xshm support

[Adam Jackson]

On Tue, 2018-05-29 at 13:08 +1000, Dave Airlie wrote:
> This is a rebased version of Marc-Andre's patches, I'll put my
> r-b on them but I thought it would be nice to have others have a look.
> 
> The only difference are I added a patch on the end, and the interface
> version is now 4 instead of 3.
> 
> I've also tested it works against an cirrus fbdev packed 24bpp X server.

Thanks for dusting these off. Series is:

Reviewed-by: Adam Jackson 

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Adam Jackson]

On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote:
> Quoting Adam Jackson (2018-05-29 06:50:46)
> > GL_LIB expands to GLX_mesa, but applications should not link against
> > that. -lGL is never wrong, just hardcode it.
> 
> Actually There is this really stupid option in the autotools build called
> --gl-lib-name. We should remove that.
> 
> Emil and I had also discussed that glvnd should provide the gl.pc file when 
> used
> instead of mesa. It appears he never got around to that, but it seems like a
> useful thing to do.

https://github.com/NVIDIA/libglvnd/pull/86

Branch is a bit stale but better than reinventing everything.

Part of the reason I didn't get much further on that is the question of
distributing the _headers_. It would be a bit awkward if glvnd provided
the library you link to but not the headers defining its interface -
though, I guess no more awkward than the current situation. At any rate
glvnd doesn't install any, and there's no way to generate 
from the Khronos scripts at the moment (it's assumed to be a platform
implementation detail, and the version in Mesa is just handcoded
history).

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Adam Jackson]

On Tue, 2018-05-29 at 18:35 +0100, Emil Velikov wrote:
> On 29 May 2018 at 15:29, Daniel Stone  wrote:
> > On 29 May 2018 at 15:17, Eric Engestrom  wrote:
> > > On Tuesday, 2018-05-29 09:50:46 -0400, Adam Jackson wrote:
> > > > GL_LIB expands to GLX_mesa, but applications should not link against
> > > > that. -lGL is never wrong, just hardcode it.
> > > 
> > > Agreed, and Archlinux has had this patch since basically forever:
> > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-glvnd-fix-gl.pc.patch?h=packages/mesa
> > 
> > Ugh. There's also this patch from February doing a similar thing:
> > https://patchwork.freedesktop.org/patch/206547/
> > 
> 
> Almost s/similar/better/ ;-)
> 
> Unless I've missed something handful of the patches are still
> unreviewed and applicable as-is.
> Would have pushed the lot (with the cosmetics spotted by Dylan) yet
> last time last few times there were plenty of unhappy people.

I put my name down as maintainer for src/glx/ and yet I don't get cc'd
on things...

That series has my:

Reviewed-by: Adam Jackson 

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Adam Jackson]

GL_LIB expands to GLX_mesa, but applications should not link against
that. -lGL is never wrong, just hardcode it.

Signed-off-by: Adam Jackson 
---
 src/mesa/gl.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/gl.pc.in b/src/mesa/gl.pc.in
index 181724b97b..8c7b7da8d7 100644
--- a/src/mesa/gl.pc.in
+++ b/src/mesa/gl.pc.in
@@ -7,7 +7,7 @@ Name: gl
 Description: Mesa OpenGL library
 Requires.private: @GL_PC_REQ_PRIV@
 Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -l@GL_LIB@
+Libs: -L${libdir} -lGL
 Libs.private: @GL_PC_LIB_PRIV@
 Cflags: -I${includedir} @GL_PC_CFLAGS@
 glx_tls: @GLX_TLS@
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx/dri: Take an extra reference on our own GLX drawables

[Adam Jackson]

On Wed, 2018-05-09 at 18:17 +0200, Michel Dänzer wrote:
> On 2018-05-08 09:47 PM, Adam Jackson wrote:
> > dri*_bind_context, when switching current drawables, will drop the
> > reference on the old one; since that refcount has probably now gone to
> > zero that means we lose all the state we applied to that drawable
> > before, like when swaps are expected to complete.
> > 
> > Dropping this reference might make some sense for drawables that aren't
> > _ours_, since we don't get events for destroyed resources and need to
> > rely on the server throwing errors when we name a no-longer-valid
> > drawable. But if the resource is one that this client created, we can be
> > reasonably sure that it will be explicitly destroyed by the same client
> 
> Is there any mechanism in place for this to result in
> loader_dri3_drawable_fini actually getting called when destroying a
> window without using glXDestroyWindow?

No; there's not a way to hook XDestroyWindow, and we can't ourselves
listen for DestroyNotifys. In fact even closing the display wouldn't be
 enough, though I think that's true with or without this patch.

> > @@ -449,6 +450,8 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable 
> > glxDrawable)
> >return NULL;
> > }
> > pdraw->refcount = 1;
> > +   if ((glxDrawable & dpy->resource_mask) == dpy->resource_base)
> 
> Should this be
> 
>if ((glxDrawable & ~dpy->resource_mask) == dpy->resource_base)
> 
> (Negated dpy->resource_mask)? Otherwise this fails to take effect for me
> here with glxgears:

Argh, yes. Too used to being on the server side where you have
clientAsMask.

> How about the idea I described before, saving the loader_dri3_drawable
> values in a hash table in dri3_screen? Maybe we could simply save a
> pointer to the whole struct, after only freeing the renderbuffers.

That would also leak, less in absolute terms but the same big-O, for
the same reasons.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

[Adam Jackson]

On Tue, 2018-05-08 at 11:42 +0200, Michel Dänzer wrote:

> Idle notify events shouldn't need special treatment, since the pixmap
> XIDs of the buffers will be different between loader_dri3_drawable
> incarnations, aren't they?

We're destroying loader_dri3_drawable structs at MakeCurrent time, but
not destroying actual drawables, so I don't think the XIDs will change.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] Fix attempt for Mesa + X-Server 1.20 + modesetting-ddx hangs on KDE5.

[Adam Jackson]

On Fri, 2018-05-04 at 15:45 +0200, Mario Kleiner wrote:

> The real problem, if i understand it correctly, is the way the life-time
> of dri3_drawables and loader_dri3_drawables is managed atm. by Mesa's
> bindContext() functions. Whenever glXMakeCurrent() etc. are called to
> assign new/different GLXDrawables to the same context (ie. one context
> reused for drawing into many different drawables, as opposed to using
> one dedicated context for each drawable), we destroy the underlying
> DRIDrawables/dri3_drawables_loader_dri3_drawables and they lose all
> state wrt. pending bufferswaps, msc, sbc, ust.

That's utterly, utterly, utterly broken.

> Therefore one of these patches is either a good enough fix for the KDE
> hang problems atm. or a diagnosis of the problem as a starting point for
> brighter people to deal with the root cause ;-)

I'll see what I can come up with. I'm not sure there's a great fix for
this that doesn't involve a few more roundtrips at MakeCurrent time,
since we can lose drawables asynchronously, but such is life.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glx/dri: Take an extra reference on our own GLX drawables

[Adam Jackson]

dri*_bind_context, when switching current drawables, will drop the
reference on the old one; since that refcount has probably now gone to
zero that means we lose all the state we applied to that drawable
before, like when swaps are expected to complete.

Dropping this reference might make some sense for drawables that aren't
_ours_, since we don't get events for destroyed resources and need to
rely on the server throwing errors when we name a no-longer-valid
drawable. But if the resource is one that this client created, we can be
reasonably sure that it will be explicitly destroyed by the same client
- and if not, the client is likely to exit anyway, so the memory leak
doesn't matter.

So, bump the refcnt if the XID of the drawable indicates that it's one
of ours. This is, admittedly, a hack. The proper solution would involve
rather more surgery to the MakeCurrent path than I can type quickly, let
alone test promptly against a wide enough range of servers and DRIs to
have any confidence in. I'll work on the real solution, but in the
meantime this is effectively not a memory leak for any real scenario,
and fixes a real bug.

Signed-off-by: Adam Jackson <a...@redhat.com>
Cc: Michel Dänzer <michel.daen...@amd.com>
Cc: Mike Lothian <m...@fireburn.co.uk>
Cc: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106351
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106372
---
 src/glx/dri_common.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index ab5d6c5bc0..d42ca71124 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -411,7 +411,8 @@ driInferDrawableConfig(struct glx_screen *psc, GLXDrawable 
draw)
 _X_HIDDEN __GLXDRIdrawable *
 driFetchDrawable(struct glx_context *gc, GLXDrawable glxDrawable)
 {
-   struct glx_display *const priv = __glXInitialize(gc->psc->dpy);
+   Display *dpy = gc->psc->dpy;
+   struct glx_display *const priv = __glXInitialize(dpy);
__GLXDRIdrawable *pdraw;
struct glx_screen *psc;
struct glx_config *config = gc->config;
@@ -449,6 +450,8 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable 
glxDrawable)
   return NULL;
}
pdraw->refcount = 1;
+   if ((glxDrawable & dpy->resource_mask) == dpy->resource_base)
+  pdraw->refcount ++;
 
return pdraw;
 }
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dri2: Sync i965_pci_ids.h from Mesa.

[Adam Jackson]

On Wed, 2018-03-07 at 07:46 -0800, Rodrigo Vivi wrote:
> Copied from Mesa with no modifications.
> 
> Gives us Geminilake and Kaby Lake platform names updates and
> sync on Coffee Lake PCI IDs.
> 
> Cc: Timo Aaltonen 
> Signed-off-by: Rodrigo Vivi 

Merged, thanks:

remote: I: patch #208689 updated using rev 
90e0cdd42dfda2accfadffa5c550712696902e14.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   43576b901..90e0cdd42  master -> master

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/6] Remove stubbed GLX_SGIX_swap_{barrier, group}

[Adam Jackson]

On Mon, 2018-03-05 at 11:08 -0800, Ian Romanick wrote:
> On 03/05/2018 10:48 AM, Emil Velikov wrote:
> > 
> > Brian, Ian,
> > 
> > Do you have any recollection about these experimental SGI extensions?
> 
> Ajax and I had talked about implementing swap_group a few times, but
> there were some technical challenges that we were too lazy to tackle.  I
> think that's about as far as any of it ever got.

SGI Prism had this working with fglrx, I suspect InfiniteReality had it
too. We got part of the server-side support merged to Xorg but I don't
think the client side ever saw the light of day. At any rate the empty
stubs can't possibly be helping anything.

Series is:

Reviewed-by: Adam Jackson <a...@redhat.com>

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC][PATCH xserver] Multi-buffered flips on subsurfaces seg fault in Mesa

[Adam Jackson]

On Mon, 2018-01-29 at 17:54 +0100, Roman Gilg wrote:
> The above patch series only allows flips on a child window with the same
> dimensions as its parent xwl_window. For flips on child windows (for example
> the video view port of a video player in windowed mode, see here:
> http://www.subdiff.de/assets/images/2017-07-28-a-new-beginning.jpg) I wanted
> to use Wayland subsurfaces as in the attached patch.
> 
> The flipping itself works well on Weston and on KWin. But when shutting down
> KWin in the end I get always a segmentation fault in Mesa when cleaning up EGL
> via eglTerminate(EGLDisplay) through libepoxy.
> 
> I pinpointed the seg fault to be a missing destroyImage function pointer here:
> https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/egl_dri2.c#n2685

Pretty sure that can't be the problem. Every DRI driver implements that
function, as far as I can tell. Possibly what's really happening is by
the time you get to that crash the dri2_egl_display has already been
torn down, ie that dri2_dpy is NULL, not the destroyImage hook.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH shaderdb 2/3] run: fallback to 3.1 core context

[Adam Jackson]

On Mon, 2018-01-29 at 15:08 -0500, Rob Clark wrote:

> Hmm, does that mean there is no way to create a 3.1 core profile if a
> driver supports 3.1 compat?

This is where the "forward-compatible" bit matters, iirc. If you ask
for 3.1FC you shouldn't get ARB_compatibility.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] egl: keep extension list sorted, per comment at the top

[Adam Jackson]

On Thu, 2018-01-25 at 10:14 +, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>

Reviewed-by: Adam Jackson <a...@redhat.com>

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] meson: Fix configuring dri glx with only gallium drivers

[Adam Jackson]

On Mon, 2018-01-15 at 20:01 +, Jon Turney wrote:
> On 12/01/2018 17:25, Dylan Baker wrote:
> > meson considers classic swrast to be a dri driver, I know it's not exactly
> > accurate, but, at least for me, it made the build system easier to reason 
> > about.
> 
> I think maybe the point here is that '-Ddri-drivers= -Dgallium-drivers= 
> -Dglx=dri' (or at least, it's autotools equivalent) is a valid 
> configuration, and gets you a libGL that falls back to indirect, since 
> no swrast or real DRI driver can be loaded[*]. (Maybe it's even the only 
> way to get that?)

I mean, it'd be valid to build libGL with -DGLX_DIRECT_RENDERING and
just not build any drivers, it'd be able to load the ones you've
already built or that came with your OS. But that's probably an even
less common thing to attempt than indirect-only.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] meson: Fix configuring dri glx with only gallium drivers

[Adam Jackson]

On Fri, 2018-01-12 at 13:18 +, Jon Turney wrote:
> 'meson -Ddri-drivers= -Dgallium-drivers=swrast -Dglx=dri' fails with 'dri
> based GLX requires at least one DRI driver'
> 
> Signed-off-by: Jon Turney 
> ---
>  meson.build | 2 +-
>  src/glx/meson.build | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 77e4e894b23..dd8e6145edb 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -323,7 +323,7 @@ if with_glx != 'disabled'
>  if with_dri
>error('xlib conflicts with any dri driver')
>  endif
> -  elif with_glx == 'dri' and not with_dri
> +  elif with_glx == 'dri' and not (with_dri or with_gallium)
>  error('dri based GLX requires at least one DRI driver')

We should just remove this check. libGL doesn't actually require a DRI
driver, and at least on OSX there's no DRI driver you could possibly
build.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] link mesautil with pthreads

[Adam Jackson]

On Mon, 2018-01-01 at 22:49 +0100, Igor Gnatenko wrote:
> ../../src/util/.libs/libmesautil.a(libmesautil_la-u_queue.o): In function 
> `u_thread_setname':
> /builddir/build/BUILD/mesa-17.3.1/src/util/../../src/util/u_thread.h:66: 
> undefined reference to `pthread_setname_np'
> ../../src/util/.libs/libmesautil.a(libmesautil_la-u_queue.o): In function 
> `thrd_join':
> /builddir/build/BUILD/mesa-17.3.1/src/util/../../include/c11/threads_posix.h:336:
>  undefined reference to `pthread_join'
> ../../src/util/.libs/libmesautil.a(libmesautil_la-u_queue.o): In function 
> `u_thread_create':
> /builddir/build/BUILD/mesa-17.3.1/src/util/../../src/util/u_thread.h:48: 
> undefined reference to `pthread_sigmask'
> ../../src/util/.libs/libmesautil.a(libmesautil_la-u_queue.o): In function 
> `thrd_create':
> /builddir/build/BUILD/mesa-17.3.1/src/util/../../include/c11/threads_posix.h:296:
>  undefined reference to `pthread_create'
> ../../src/util/.libs/libmesautil.a(libmesautil_la-u_queue.o): In function 
> `u_thread_create':
> /builddir/build/BUILD/mesa-17.3.1/src/util/../../src/util/u_thread.h:50: 
> undefined reference to `pthread_sigmask'
> /builddir/build/BUILD/mesa-17.3.1/src/util/../../src/util/u_thread.h:50: 
> undefined reference to `pthread_sigmask'
> ../../src/util/.libs/libmesautil.a(libmesautil_la-u_queue.o): In function 
> `call_once':
> /builddir/build/BUILD/mesa-17.3.1/src/util/../../include/c11/threads_posix.h:96:
>  undefined reference to `pthread_once'
> ../../src/util/.libs/libmesautil.a(libmesautil_la-u_queue.o): In function 
> `u_thread_get_time_nano':
> /builddir/build/BUILD/mesa-17.3.1/src/util/../../src/util/u_thread.h:84: 
> undefined reference to `pthread_getcpuclockid'
> collect2: error: ld returned 1 exit status
> 
> Signed-off-by: Igor Gnatenko 

Yep, just hit this in rawhide myself. Merged, thanks.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: GLX_MESA_multithread_makecurrent is direct-only

[Adam Jackson]

On Wed, 2017-12-06 at 15:01 -0500, Ian Romanick wrote:
> On 12/06/2017 10:32 AM, Emil Velikov wrote:
> > On 5 December 2017 at 16:10, Adam Jackson <a...@redhat.com> wrote:
> > > This extension is not defined for indirect contexts. Marking it as
> > > "client only", as the old code did here, would make the extension
> > > available in indirect contexts, even though the server would certainly
> > > not have it in its extension list.
> > > 
> > > Cc: <mesa-sta...@lists.freedesktop.org>
> > > Signed-off-by: Adam Jackson <a...@redhat.com>
> > 
> > Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
> > 
> > Unrelated: reportedly only cairo is using the extension, so could we
> > consider the extension obsolete?
> 
> It's not too surprising that only Cairo is using it.  IIRC, Eric
> specifically made this extension for Cairo, and it was a pretty big perf
> win at the time.

I think at this point most of the effect could be achieved with no-
flush contexts, but yeah.

> I had wanted to test this patch, but... does LIBGL_ALWAYS_INDIRECT=y
> just not work any more?  With the distro Mesa I get:

It works, that's the server telling you it doesn't support indirect
rendering. We turned that off by default a few releases ago as being
slow and underfeatured and CVE-prone. Start your server with +iglx or
with this in xorg.conf:

Section "ServerFlags"
Option "IndirectGLX" "true"
EndSection

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] glx: Lift sending the MakeCurrent request to top-level code (v2)

[Adam Jackson]

On Wed, 2017-12-06 at 15:14 +, Emil Velikov wrote:

> > -  if (gc->vtable->bind(gc, oldGC, draw, read) != Success) {
> > +  if (gc->vtable->bind(gc, gc, draw, read) != Success) {
> >   __glXSetCurrentContextNull();
> 
> This line seems inconsistent/wrong.
> 
> The glXMakeCurrent manpage says "If False is returned, the previously
> current rendering context and drawable (if any) remain unchanged."

Ugh. That's not really possible to get perfectly right, there are
unrecoverable states (think MakeCurrent away from a context that's been
deleted, or whose current drawable is a destroyed window). Still, I
suppose we should try at least a little.

- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev