Re: [ANNOUNCE] mesa-demos 9.0.0
My apologies, I should have added a short text to explain the release in the initial mail. While I intended to do so, I struggled a bit with some incorrectly wrtapped lines, and forgot to add this after I fixed that. Here it comes after-the-fact: Since Mesa the 8.5 release, there's been a few noteworthy changes to the code: - We've removed the Autotools and CMake build systems, meaning that Meson is the only build-system in use - We've also added our first Vulkan demo, vkgears! - There's also been a bunch of code removed, mostly code that either has found another home (some in form of piglit tests), or simply wasn't possible to build on modern systems any more (like old 3DFX Glide support code). - We've now using libdecor on Wayland, so we get decorations for eglut and the new vkgears demo. - We're also not following in Mesa's footsteps and only releasing .tar.xz files. All of this seems to warrant a new major release, so here we are. There's also a bunch of bugs fixed, many related to the still-quite-new Meson build system. So this seems like a good time to upgrade! On Wed, 2023-03-22 at 16:12 +0100, Erik Faye-Lund wrote: > Alexandros Frantzis (1): > egl: Add texture from pixmap example for GLES2. > > Anders Kaseorg (1): > meson: Fix DEMOS_DATA_DIR when with-system-data-files is > enabled > > Ben Brown (1): > meson: Add missing build dependencies on glu > > Bram Stolk (1): > Take out non-sensical test: array is always not-null. > > Erik Faye-Lund (97): > meson: disable annoying msvc-warnings > meson: suppress a few msvc warnings > meson: suppress more annoying warnings > wglutil.c: clean up size-wrangling > glinfo_common.c: add int-casts > glinfo_common.c: do not shadow variable i > readtex.c: use float literals > readtex.c: add explicit cast > wglcontext.c: cast size_t to int > wglinfo.c: fixup indent > showbuffer.c: use float-literal > wglthreads.c: remove unused argument > sharedtex_mt.c: cast through uintptr_t > wincopy.c: do not copy potentially uninitialized member > README.rst: rename heading > README.rst: capitalize GLUT and FreeGLUT > README.rst: highlight folder names > README.rst: remove Distribution from heading > remove cmake and autotools support > gitlab-ci: clean up job-names > samples: remove unused variable > util: remove unused source-file > egl,util: factor out matrix-code from es2gears to util > use matrix util code instead of open-coding > glsl: use matrix utils > redbook: use matrix utils > install meson 0.59.4 from pip > meson: update meson_version to 0.59 > meson: fallback to glut-dependency > tests: remove unused variable > eglut_wayland: terminate mainloop on display-close > gitlab-ci: drop needless sys_root property > gitlab-ci: add package for mingw pkg-config > gitlab-ci: switch to pkg-config for glut on mingw > meson: deprecate with-glut option > meson: use a feature-option for glut > meson: pass dep_glut to freeglut-detection > util: rename mat4_frustum to mat4_frustum_gl > util: add vulkan frustrum util > vulkan: add vkgears demo > eglut_wayland: handle keyboard-input > eglut_wayland: refactor polling > eglut_wayland: properly handle key-repeats > remove geometry-shader demos > gitlab-ci: re-sort packages > vulkan: move wsi code into a wsi directory > vulkan: move wsi selection to common code > README.rst: mention vulkan demos > egl: correct typo in copyright statement > meson: add missing license-headers > vulkan: add missing license headers > meson: rework vulkan-detection > vulkan: install vkgears > add a mailmap-file > egl: add missing license texts > remove perf-tests > meson: add a wrap for libdecor > egl: install opengl-demos > ci: forward concurrent-flag from ci-templates > vkgears: fix non-gnu compilation > ci: build using clang > meson: build vkgears if either xcb or wayland is missing > ignore checked-out subprojects > update to glad 0.1.36 > vulkan/wsi: add missing space > vulkan/wsi: mark fini_display as static > vulkan/wsi: explicitly mark functions as void > xdemos: avoid needless fallthrough > meson: check argument syntax instead of compiler > meson: enable some warnings on gcc/clang > meson: allow falling back to alternative glu-detection > meson: do not search for glu on macos > util: do not require sincos() > meson: disable
[ANNOUNCE] mesa-demos 9.0.0
Alexandros Frantzis (1): egl: Add texture from pixmap example for GLES2. Anders Kaseorg (1): meson: Fix DEMOS_DATA_DIR when with-system-data-files is enabled Ben Brown (1): meson: Add missing build dependencies on glu Bram Stolk (1): Take out non-sensical test: array is always not-null. Erik Faye-Lund (97): meson: disable annoying msvc-warnings meson: suppress a few msvc warnings meson: suppress more annoying warnings wglutil.c: clean up size-wrangling glinfo_common.c: add int-casts glinfo_common.c: do not shadow variable i readtex.c: use float literals readtex.c: add explicit cast wglcontext.c: cast size_t to int wglinfo.c: fixup indent showbuffer.c: use float-literal wglthreads.c: remove unused argument sharedtex_mt.c: cast through uintptr_t wincopy.c: do not copy potentially uninitialized member README.rst: rename heading README.rst: capitalize GLUT and FreeGLUT README.rst: highlight folder names README.rst: remove Distribution from heading remove cmake and autotools support gitlab-ci: clean up job-names samples: remove unused variable util: remove unused source-file egl,util: factor out matrix-code from es2gears to util use matrix util code instead of open-coding glsl: use matrix utils redbook: use matrix utils install meson 0.59.4 from pip meson: update meson_version to 0.59 meson: fallback to glut-dependency tests: remove unused variable eglut_wayland: terminate mainloop on display-close gitlab-ci: drop needless sys_root property gitlab-ci: add package for mingw pkg-config gitlab-ci: switch to pkg-config for glut on mingw meson: deprecate with-glut option meson: use a feature-option for glut meson: pass dep_glut to freeglut-detection util: rename mat4_frustum to mat4_frustum_gl util: add vulkan frustrum util vulkan: add vkgears demo eglut_wayland: handle keyboard-input eglut_wayland: refactor polling eglut_wayland: properly handle key-repeats remove geometry-shader demos gitlab-ci: re-sort packages vulkan: move wsi code into a wsi directory vulkan: move wsi selection to common code README.rst: mention vulkan demos egl: correct typo in copyright statement meson: add missing license-headers vulkan: add missing license headers meson: rework vulkan-detection vulkan: install vkgears add a mailmap-file egl: add missing license texts remove perf-tests meson: add a wrap for libdecor egl: install opengl-demos ci: forward concurrent-flag from ci-templates vkgears: fix non-gnu compilation ci: build using clang meson: build vkgears if either xcb or wayland is missing ignore checked-out subprojects update to glad 0.1.36 vulkan/wsi: add missing space vulkan/wsi: mark fini_display as static vulkan/wsi: explicitly mark functions as void xdemos: avoid needless fallthrough meson: check argument syntax instead of compiler meson: enable some warnings on gcc/clang meson: allow falling back to alternative glu-detection meson: do not search for glu on macos util: do not require sincos() meson: disable some warnings on macos meson: explicitly check for glx dependency es2gears: do not define _GNU_SOURCE util: use gl2 program validation util: use gl2 program-parameters util: remove defective arb-shader fallback util: do not call gl2 through extra func-ptrs tests: use gl2-functions for logs meson: use win_subsystem instead of gui_app update some WIN32 vs _WIN32 checks meson: avoid building unix-source on windows demos/glinfo: make sure GL_SHADING_LANGUAGE_VERSION is defined tests/texobj: require gl 1.1 headers redbook: require gl 1.3 headers demos: require gl 2.0 headers xdemos: require gl 3.2 headers meson: correct spelling meson: disable some msvc warnings for c++ demos/vao_demo: pass literal pointers through uintptr_t tests/texdown: cast pointer to uintptr_t ci: enable mr-pipelines completely retire xmesa/fx code osdemos: link to dep_osmesa rather than dep_gl bump version to 9.0.0 for release Hoe Hao Cheng (37): eglinfo: fix whitespace eglinfo: hook up glinfo_common.h eglinfo: print OpenGL[ES] extensions eglinfo: add dep_gl to meson.build es2_info: turn it into a proper .c file glinfo_common: move gl_versions out into another header eglinfo: use the glad library eglinfo: refactor the platform display if-ladder eglinfo: add command line options eglinfo: support api selection eglinfo: fix interaction with pre-1.4 EGL eglinfo: add -B brief output support
Re: Beginner to driver dev, looking for advice
Hi, and welcome to the community! In case you're not already familiar, we have #dri-devel on OFTC, as mentioned here: https://docs.mesa3d.org/lists.html#irc This is where most day-to-day communication happens, as well as on our project on gitlab.fdo. There's also some technical docs on docs.mesa3d.org, both generic and hardware-specific. But as always, those docs can be improved. If there's anything in *particular* you think is under-documented, feel free to open a ticket about it, and maybe someone steps up to improve it. We have some articles specific to some of the subjects you bring up, as well as some generic ones: - https://docs.mesa3d.org/debugging.html - https://docs.mesa3d.org/drivers/anv.html - https://docs.mesa3d.org/isl/index.html - https://docs.mesa3d.org/drivers/v3d.html - https://docs.mesa3d.org/drivers/lima.html - https://docs.mesa3d.org/drivers/panfrost.html - https://docs.mesa3d.org/utilities.html - https://docs.mesa3d.org/helpwanted.html - https://docs.mesa3d.org/nir/index.html I know, it's a lot of links, and there's a lot more where that comes from. An yet it might not be quite what you're looking for ;) Anyway, feel free to reach out on #dri-devel if you have questions. My nick is kusma, and if I'm around I might be able to forward you to the right person depending on your question. If I'm not around, there's usually someone else who's helpful! On Fri, 2022-12-30 at 01:41 +0100, Nils Petter Skålerud wrote: > My name is Nils Petter Skålerud, my online handle is Didgy. I'm > currently trying to learn to write graphics drivers, with the intent > of > contributing to Mesa (Ideally Intel, RPi4, Arm Mali). I am currently > familiar with C/C++ and writing Vulkan applications. > > Currently I'm focusing on engaging with the IRC channels I can find > on > the subject, and reading the Linux subsystem documentation for GPU > driver devs. Also I am focusing on debugging some of the drivers and > learning what I can. > > I am facing a hard time finding good learning resources on the topic > and > would like any recommendations I can get. I'd very much appreciate > any > sort of guidance possible. > > I can be reached on my e-mail np_skale...@hotmail.com. Also I can be > reached on Discord "Didgy#5975". > > > Sincerely, Nils Petter Skålerud >
Re: Zink MR signoff tags
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... > I kinda like the s-o-b tags but those > don't require fiddly rebases, just -s in the right place.. > > On Tue, Oct 04, 2022 at 10:44:31PM -0500, Mike Blumenkrantz wrote: > > Hi, > > After some vigorous and robust discussion with Erik, we've > > decided that > > zink will no longer require any rb/ab/etb tags to be applied to > > patches in > > MRs. > > Following in Turnip's footsteps, any MR that receives sufficient > > reviewage > > in gitlab comments can be merged directly with no further action > > necessary. > > Mike -- Erik Faye-Lund Principal Engineer Collabora Ltd. Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, United Kingdom Registered in England & Wales, no. 5513718
Re: Converting mesa/demos to Meson
OK, and now with over a month and a half since the release of mesa- demos 8.5.0 which deprecated the other build systems, I think it might be about time to remove the cmake and autotools support. I've had up an MR for a while for this, so please direct any objections in this direction: https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/74 If I don't hear any objections in a few weeks, I plan on merging that change. On Fri, 2022-05-13 at 11:14 +0200, Erik Faye-Lund wrote: > OK, so I think enough time has passed. I have heard a few voices in > support, and no voices against, so my plan is to go ahead and merge > this early next week (probably Monday), if I don't hear anyone speak > up > soon. > > On Wed, 2022-05-04 at 18:38 +0200, Erik Faye-Lund wrote: > > Because we've landed on using Meson in the main Mesa repository, > > I've > > been working on converting the mesa/demos repo to Meson as well. > > > > I've posted an MR here: > > https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/60 > > > > This MR adds a new Meson build system to the repository, and marks > > the > > Autotools and CMake build systems as deprecated, similar to what we > > did > > for the Autotools and SCons build systems in Mesa when we > > transitioned. > > > > After this lands, I propose that we cut a new release (we really > > should > > cut a new release soon anyway), then wait for a while and fix up > > any > > problems found, and finally rip ot the old build systems. > > > > After removing the old build systems, we end up with this total > > code > > reduction: > > > > 112 files changed, 1642 insertions(+), 4744 deletions(-) > > > > The removal commit is here, BTW: > > https://gitlab.freedesktop.org/kusma/mesa-demos/-/commits/remove-old-buildsystems > > > > Thoughts? Objections? > > > -- Erik Faye-Lund Principal Engineer Collabora Ltd. Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, United Kingdom Registered in England & Wales, no. 5513718
[ANNOUNCE] mesa-demos 8.5.0
There's been over four years since the last release, so here's mesa-demos v8.5.0. The most significant change is the change from Autotools / CMake build systems to Meson. In addition, there a lot of other changes. See below for details. Erik. Adam Jackson (3): auxbuffer: Don't override $DISPLAY from the environment eglinfo: Add support for EGL_MESA_query_driver glxgears: Make the swap interval configurable Alan Coopersmith (1): Update URLs to reflect migration to gitlab Brian Paul (4): glxinfo/wglinfo: remove print_shader_limits() code glxinfo/wglinfo: fix VP/FP strings, indentation glxinfo/wglinfo: print (110) instead of empty line glxinfo/wglinfo: improve GL_ARB_imaging query code Christian GMEINER (1): fix -Wunused-variable compile warings Christian Gmeiner (1): fix -Wunused-const-variable compile warnings Dave Airlie (1): glad: regenerate glad files from glad upstream Eric Engestrom (1): gitlab-ci: add cmake & autotools builds Erik Faye-Lund (128): wglgears: do not include unistd.h on MSVC wglgears: change window-title wglgears: make usage and error-handling similar to glxgears wglgears: respect x and y arguments to make_window wglgears: add geometry option wglgears: mark application as dpi-aware wglgears: set whole process as dpi-aware wglgears: drop random printf in sRGB code-path wglgears: implement support for multi-sampling wglgears: fix rotation speed to 70 degrees per second wglgears: remove unused variable wglgears: match usage format more closely to glxgears wglgears: omit paranoid error-checking wglgears: exit with error-code on error wglgears: do not re-create window after re-creating context wglgears: error properly when no pixel-format is found wglgears: implement animate-state wglgears: implemenmt wgl-extension helper wglgears: check what the current vsync setting is wglgears: add support for -fullscreen switch Revert "wglgears: do not re-create window after re-creating context" wglgears: respect x and y positions wglgears: destroy old window when recreating glxgears: add sRGB mode support glxgears / wglgears: adjust colors for sRGB wglgears: match glxgears formatting wglgears: style-fixup wglgears: show stereo-option in usage wglgears: add srgb-mode to usage Revert "wglgears: show stereo-option in usage" egl: match geometry position of glxgears egl: match lighting of wglgears egl: use smooth normals for inner face egl: pack all strips per gear into a single draw eglut_wayland: only mark opaque region if no alpha egl: do not modulate alpha with light remove slang tests remove rbug-client include windows.h in gl_wrap.h cmake: do not force inclusion of windows.h remove openvg support gitlab-ci: make sure we have the packages we need gitlab-ci: switch to freedesktop/ci-templates gitlab-ci: move to debian bullseye cmake: make glut a soft dependency tests: remove getprocaddress test eglut_wayland: give error when wl-shell is not supported remove stale makefile cmake: move GLAPIENTRY definition to wrapper-headers eglut_wayland: set opaque region every frame cmake: fix out-of-tree build gitlab-ci: bump ci-tag glut_wrapper: fix macos glut/glad compatibility pbutil: dynamically load GLX extension functions progs/fp: avoid undefined result in scs-test cmake: set gl-preference to legacy cmake: bump minimum version wgl: remove stray semicolon es2tri.c: remove write-only variable bindtex.c: remove write-only variable xeglgears.c: remove write-only variable msaa.c: remove write-only variable pbuffer.c: remove write-only variable render_tex.c: remove write-only variable two_win.c: remove write-only variable yuvrect_client.c: fixup indent yuvrect_client.c: remove write-only variables blendeq.c: remove write-only variable shtest.c: remove write-only variable objview.c: remove write-only variable auxbuffer.c: remove write-only variable olympic.c: remove write-only variables dinoshade.c: cast glu tess callbacks tessdemo.c: fixup indent tessdemo.c: cast glu tess callbacks quadric.c: cast glu quadric callbacks surfpoints.c: cast glu nurbs callbacks tess.c: cast glu tess callbacks tesswind.c: cast glu tess callbacks trim.c: cast glu nurbs callbacks nurb.c: cast glu nurbs callbacks quad.c: cast glu quadric callbacks es1_info.c: remove excessive argument to printf opengles1/tri.c: remove unused variable sphere.c: remove unused function glslstateschange.c: fix constness of pointers es2tri.c
Re: Converting mesa/demos to Meson
OK, so I think enough time has passed. I have heard a few voices in support, and no voices against, so my plan is to go ahead and merge this early next week (probably Monday), if I don't hear anyone speak up soon. On Wed, 2022-05-04 at 18:38 +0200, Erik Faye-Lund wrote: > Because we've landed on using Meson in the main Mesa repository, I've > been working on converting the mesa/demos repo to Meson as well. > > I've posted an MR here: > https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/60 > > This MR adds a new Meson build system to the repository, and marks > the > Autotools and CMake build systems as deprecated, similar to what we > did > for the Autotools and SCons build systems in Mesa when we > transitioned. > > After this lands, I propose that we cut a new release (we really > should > cut a new release soon anyway), then wait for a while and fix up any > problems found, and finally rip ot the old build systems. > > After removing the old build systems, we end up with this total code > reduction: > > 112 files changed, 1642 insertions(+), 4744 deletions(-) > > The removal commit is here, BTW: > https://gitlab.freedesktop.org/kusma/mesa-demos/-/commits/remove-old-buildsystems > > Thoughts? Objections? > -- Erik Faye-Lund Principal Engineer Collabora Ltd. Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, United Kingdom Registered in England & Wales, no. 5513718
Converting mesa/demos to Meson
Because we've landed on using Meson in the main Mesa repository, I've been working on converting the mesa/demos repo to Meson as well. I've posted an MR here: https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/60 This MR adds a new Meson build system to the repository, and marks the Autotools and CMake build systems as deprecated, similar to what we did for the Autotools and SCons build systems in Mesa when we transitioned. After this lands, I propose that we cut a new release (we really should cut a new release soon anyway), then wait for a while and fix up any problems found, and finally rip ot the old build systems. After removing the old build systems, we end up with this total code reduction: 112 files changed, 1642 insertions(+), 4744 deletions(-) The removal commit is here, BTW: https://gitlab.freedesktop.org/kusma/mesa-demos/-/commits/remove-old-buildsystems Thoughts? Objections? -- Erik Faye-Lund Principal Engineer Collabora Ltd. Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, United Kingdom Registered in England & Wales, no. 5513718
Re: Question
On Wed, 2022-03-16 at 19:04 -0700, Immortal Tassadar wrote: > Hello. I would like to know if you are still working in the windows > port of Zink? I can only really answer this in fairly vague terms, because I don't know what everyone else is working on, but: 1. There's currently basic Windows support in Zink upstream. I believe we're lacking proper winsys integration, so anyone wanting good performance on Windows would probably have to work on that. 2. We do compile-test the Zink on Windows, but we do not run tests as far as I'm aware. 3. There's been a recent windows-specicif MR submitted: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15504 4. I'm not personally working on Windows support in Zink at the moment. So, I *think* you could say the answer is "yes", but I wouldn't expect anyone else to scratch your windows-specific itch at the moment. Windows support in Zink is happening slowly, driven by those who need it. -- Erik Faye-Lund Principal Engineer Collabora Ltd. Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, United Kingdom Registered in England & Wales, no. 5513718
Re: [Mesa-dev] docs: consistent language
On Fri, 2021-03-26 at 18:22 +0100, Erik Faye-Lund wrote: > On Mon, 2021-03-15 at 13:44 +0100, Erik Faye-Lund wrote: > > TLDR; I'm proposing to standardize on US English in our public- > > facing > > documentation. > > > > I proposed an MR a while back that changed the only occurrence of > > the > > UK English spelling "optimisation" for the US English spelling > > "optimization", which is already used 34 times in the docs. I've > > done > > similar changes in the past. > > > > But this time Ian brought up the good point that picking a > > preferred > > language should probably be done using group consensus on the > > mailing > > list than just picking what's currently most popular. > > > > So, I hereby propose to pick US English as our default language for > > user-facing documentation. > > > > I'm not proposing to force anyone to use a particular English > > variant > > for things like comments, commit messages or variable names. I > > don't > > think there's much value in enforcing that, and I think it'd be > > perfectly fine if any particular driver wanted to pick a particular > > variant of English. > > > > The main reason I want to standardize on an English variant is that > > I'm > > trying create a word-list for domain-specific/technical language to > > detect spelling mistakes in the docs more easily. And not having to > > add > > both US and UK English words makes this list easier to maintain. > > I'm > > not planning on going 100% systematically though the dictionary to > > detect UK English words that might be in my system dictionary, just > > to > > fix the words that currently cause me (a tiny amount of) pain ;) > > > > The main reason why I'm proposing US English over for instance UK > > English is that this seems to be the dominant variant currently in > > the > > documentation. So it seems like the pragmatic choice to me. > > > > Thoughts? Any objections to sticking to US English in the docs? > > OK, so almost two weeks has passed, and I've only gotten a single > objection to the proposal, but a handfull of variations of voices in > favor of the proposal. > > I suspect this is as close to a consensus we're going to reach. Since > it's not 100% consensus, I think maybe the best option is to take > Kenneth Grauke's suggestion of making this a recommendation rather > than > a rule. > > So my plan is to write up a patch for the docs that explains that we > recommend writing docs in US English. That should IMO make it clear > that we don't require people to spell-check to make sure that they're > using the "right" variation of English. At the same time, it's clear > enough that we're happy about patches moving towards US English. I've had the MR up here for a few weeks, but it hasn't gotten any r-b or a-b tags yet: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9912 Anyone interested in reviewing it? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] docs: consistent language
On Mon, 2021-03-15 at 13:44 +0100, Erik Faye-Lund wrote: > TLDR; I'm proposing to standardize on US English in our public-facing > documentation. > > I proposed an MR a while back that changed the only occurrence of the > UK English spelling "optimisation" for the US English spelling > "optimization", which is already used 34 times in the docs. I've done > similar changes in the past. > > But this time Ian brought up the good point that picking a preferred > language should probably be done using group consensus on the mailing > list than just picking what's currently most popular. > > So, I hereby propose to pick US English as our default language for > user-facing documentation. > > I'm not proposing to force anyone to use a particular English variant > for things like comments, commit messages or variable names. I don't > think there's much value in enforcing that, and I think it'd be > perfectly fine if any particular driver wanted to pick a particular > variant of English. > > The main reason I want to standardize on an English variant is that > I'm > trying create a word-list for domain-specific/technical language to > detect spelling mistakes in the docs more easily. And not having to > add > both US and UK English words makes this list easier to maintain. I'm > not planning on going 100% systematically though the dictionary to > detect UK English words that might be in my system dictionary, just > to > fix the words that currently cause me (a tiny amount of) pain ;) > > The main reason why I'm proposing US English over for instance UK > English is that this seems to be the dominant variant currently in > the > documentation. So it seems like the pragmatic choice to me. > > Thoughts? Any objections to sticking to US English in the docs? OK, so almost two weeks has passed, and I've only gotten a single objection to the proposal, but a handfull of variations of voices in favor of the proposal. I suspect this is as close to a consensus we're going to reach. Since it's not 100% consensus, I think maybe the best option is to take Kenneth Grauke's suggestion of making this a recommendation rather than a rule. So my plan is to write up a patch for the docs that explains that we recommend writing docs in US English. That should IMO make it clear that we don't require people to spell-check to make sure that they're using the "right" variation of English. At the same time, it's clear enough that we're happy about patches moving towards US English. It seems we're missing docs on how to write docs anyway (I guess that's meta-docs?), so I guess this is a good time to add this. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] docs: consistent language
On Mon, 2021-03-15 at 10:54 -0700, Ian Romanick wrote: > > If anyone doesn't feel comfortable speaking out publicly about this, > please feel free to contact Erik or me privately. Just thought I'd mention; I've gotten a vote against the proposal through other channels. Because I haven't gotten explicit permission to name the person, I'm not doing so here. The person said it's not a hill they're willing to die on, though. But it's worth mentioning. My understanding is that the vote against is a vote to effectively leave the english variant undefined, similar to what Wikipedia does. So not really a vote for some other specific variant of English. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] docs: consistent language
Just one detail to fill in: I just got a question on #dri-devel if this suggestion would place an additional burden on most developers to additionally look up every word of new documentation to see if it's US or UK English. I'm not proposing to place any additional burden on people writing docs. I think it's fine if people do a best-effort (which arguably can be low; this isn't a very important detail), and then we'll either catch things during reviews or fix it up afterwards. It's not like the Mesa docs are perfect in terms of spelling or grammar anyway, I just want to resolve which of the forks in the road we follow trying to clean things up ;) On Mon, 2021-03-15 at 13:44 +0100, Erik Faye-Lund wrote: > TLDR; I'm proposing to standardize on US English in our public-facing > documentation. > > I proposed an MR a while back that changed the only occurrence of the > UK English spelling "optimisation" for the US English spelling > "optimization", which is already used 34 times in the docs. I've done > similar changes in the past. > > But this time Ian brought up the good point that picking a preferred > language should probably be done using group consensus on the mailing > list than just picking what's currently most popular. > > So, I hereby propose to pick US English as our default language for > user-facing documentation. > > I'm not proposing to force anyone to use a particular English variant > for things like comments, commit messages or variable names. I don't > think there's much value in enforcing that, and I think it'd be > perfectly fine if any particular driver wanted to pick a particular > variant of English. > > The main reason I want to standardize on an English variant is that > I'm > trying create a word-list for domain-specific/technical language to > detect spelling mistakes in the docs more easily. And not having to > add > both US and UK English words makes this list easier to maintain. I'm > not planning on going 100% systematically though the dictionary to > detect UK English words that might be in my system dictionary, just > to > fix the words that currently cause me (a tiny amount of) pain ;) > > The main reason why I'm proposing US English over for instance UK > English is that this seems to be the dominant variant currently in > the > documentation. So it seems like the pragmatic choice to me. > > Thoughts? Any objections to sticking to US English in the docs? > > The MR in question: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8572 > > Ian's response: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8572#note_808593 > > Previous changes: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6864 > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6894 > > > ___ > 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
Re: [Mesa-dev] docs: consistent language
On Tue, 2021-03-16 at 10:06 +, Daniel Stone wrote: > On Mon, 15 Mar 2021 at 20:54, Jason Ekstrand > wrote: > > Three comments: > > > > 1. +1 > > 2. Khronos has generally standardized on American English in their > > specs so I guess that provides some sort of prior art or something. > > 3. I'd generally be a fan of encouraging American spellings in > > common > > code as well. As someone who doesn't use auto-complete, having to > > remember which variable is named "color" and which is "colour" > > would > > get painful. Fortunately, we don't have a whole lot of variation > > here > > but it'd be good to keep consistency. > > > > 4. UK English is unarguably correct and better. Actually, strike all of the above, and let's write all docs in Norwegian Bokmål instead. Or even better, Esperanto! > 5. That doesn't change point #3 in particular; just like coding > style, one 'bad' choice is better than no choice at all. Yeah, so I don't oppose consistent language in code and comments either, but I suspect that's a bit harder to change or get agreement on. For instance, it seems both Panfrost and Nouveau use quite a bit of UK English, whereas AFAICT most other drivers use mostly US English (mostly based on grepping for "color" vs "colour", so a very flawed metric indeed, but whatever). I simply don't want to hold back a decision about the docs due to something that might be harder to agree about. Color me self-serving here, I guess ;) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] docs: consistent language
TLDR; I'm proposing to standardize on US English in our public-facing documentation. I proposed an MR a while back that changed the only occurrence of the UK English spelling "optimisation" for the US English spelling "optimization", which is already used 34 times in the docs. I've done similar changes in the past. But this time Ian brought up the good point that picking a preferred language should probably be done using group consensus on the mailing list than just picking what's currently most popular. So, I hereby propose to pick US English as our default language for user-facing documentation. I'm not proposing to force anyone to use a particular English variant for things like comments, commit messages or variable names. I don't think there's much value in enforcing that, and I think it'd be perfectly fine if any particular driver wanted to pick a particular variant of English. The main reason I want to standardize on an English variant is that I'm trying create a word-list for domain-specific/technical language to detect spelling mistakes in the docs more easily. And not having to add both US and UK English words makes this list easier to maintain. I'm not planning on going 100% systematically though the dictionary to detect UK English words that might be in my system dictionary, just to fix the words that currently cause me (a tiny amount of) pain ;) The main reason why I'm proposing US English over for instance UK English is that this seems to be the dominant variant currently in the documentation. So it seems like the pragmatic choice to me. Thoughts? Any objections to sticking to US English in the docs? The MR in question: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8572 Ian's response: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8572#note_808593 Previous changes: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6864 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6894 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
AFAIK, anisitropic filtering is almost uselessly underspecified, so pretty much anything should pass the CTS tests. But visual quality does affect applications, so we should probably aim for something reasonable. On Thu, 2021-01-07 at 19:41 +1000, Dave Airlie wrote: > On Thu, 7 Jan 2021 at 18:49, Andreas Fänger > wrote: > > > > Hi Dave, > > > > > > > > don’t know why the current softpipe/swrast implementation shouldn’t > > be conformant. > > Interesting I hadn't known we had a correct impl in mesa, the > features.txt has said > "softpipe and llvmpipe advertise 16x anisotropy but simply ignore the > setting" > > so I never dug any deeper. I'll consider a port of this to llvmpipe > at > some point, making it efficient might be tricky. > > Dave. > ___ > 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
Re: [Mesa-dev] [ANNOUNCE] mesa 20.3.0-rc2
On Thu, 2020-11-19 at 10:36 -0800, Dylan Baker wrote: > > Erik Faye-Lund (3): > softpipe: correct signature of get_compiler_options > mesa/main: add missing include in glformats.h > zink: more accurately track supported blits > I just want to point out that we *might* want to revert this last commit, due to this regression: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3843 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rename "master" branch to "main"?
On Mon, 2020-08-03 at 12:48 -0500, Jason Ekstrand wrote: > On Mon, Aug 3, 2020 at 12:42 PM Erik Faye-Lund > wrote: > > On Mon, 2020-08-03 at 10:30 -0500, Jason Ekstrand wrote: > > > All, > > > > > > I'm sure by now you've all seen the articles, LKML mails, and > > > other > > > chatter around inclusive language in software. While mesa > > > doesn't > > > provide a whole lot of documentation (hah!), we do have a > > > website, a > > > code-base, and a git repo and this is something that we, as a > > > project > > > should consider. > > > > > > What I'm proposing today is simply re-naming the primary Git > > > branch > > > from "master" to "main". Why "main"? Because that's what GitHub > > > has > > > chosen "main" as their new default branch name and so it sounds > > > to me > > > like the most likely new default. > > > > > > As far as impact on the project goes, if and when we rename the > > > primary branch, the old "master" branch will be locked (no > > > pushing/merging allowed) and all MRs will have to be re-targeted > > > against the new branch. Fortunately, that's very easy to > > > do. You > > > just edit the MR and there's a little drop-down box at the top > > > for > > > which branch it targets. I just tested this with one of mine and > > > it > > > seems to work ok. > > > > > > As far as other bits of language in the code-base, I'm happy to > > > see > > > those cleaned up as people have opportunity. I'm not aware of > > > any > > > particularly egregious offenders. However, changing the name of > > > the > > > primary branch is something which will cause a brief hiccup in > > > people's development process and so warrants broader discussion. > > > > > > Thoughts? > > > > > > > I'm all for renaming it, but I'm a bit worried about doing it in a > > way > > where we don't break all merge-requests... > > > > As far as I know, GitLab doesn't allow changing the target-branch > > of a > > merge-request, so all pending merge-requests would all of a sudden > > point to the wrong branch. > > No and yes. It doesn't have any way to mass-edit merge requests to > re-target them. (It does have a mass-edit tool but it doesn't > support > that). However, it does support re-targetting individual merge > requests. I even gave instructions for doing so in my first e-mail. > :-) > Thanks for pointing that out, I feel kinda stupid now. I was looking for that feature in the past, and couldn't find it, but surely there it is! I guess I should have read more carefully. Updating every merge request manually should be a totally OK compromise IMO. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rename "master" branch to "main"?
On Mon, 2020-08-03 at 10:30 -0500, Jason Ekstrand wrote: > All, > > I'm sure by now you've all seen the articles, LKML mails, and other > chatter around inclusive language in software. While mesa doesn't > provide a whole lot of documentation (hah!), we do have a website, a > code-base, and a git repo and this is something that we, as a project > should consider. > > What I'm proposing today is simply re-naming the primary Git branch > from "master" to "main". Why "main"? Because that's what GitHub has > chosen "main" as their new default branch name and so it sounds to me > like the most likely new default. > > As far as impact on the project goes, if and when we rename the > primary branch, the old "master" branch will be locked (no > pushing/merging allowed) and all MRs will have to be re-targeted > against the new branch. Fortunately, that's very easy to do. You > just edit the MR and there's a little drop-down box at the top for > which branch it targets. I just tested this with one of mine and it > seems to work ok. > > As far as other bits of language in the code-base, I'm happy to see > those cleaned up as people have opportunity. I'm not aware of any > particularly egregious offenders. However, changing the name of the > primary branch is something which will cause a brief hiccup in > people's development process and so warrants broader discussion. > > Thoughts? > I'm all for renaming it, but I'm a bit worried about doing it in a way where we don't break all merge-requests... As far as I know, GitLab doesn't allow changing the target-branch of a merge-request, so all pending merge-requests would all of a sudden point to the wrong branch. Unless we have a a plan for somehow making sure both branches are updated in lock-step in a grace-period or something like that... I dunno. Does anyone have any great ideas for avoiding this problem? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] piglit/mesa marge access
I second the request :-) Jul 31, 2020 16:15:05 Mike Blumenkrantz : > Hi, > > I'd like to request marge access for the piglit and mesa gitlab projects. > I've been contributing a number of patches here (primarily to zink/gallium), > and this would be useful in my continued work. > > Regards, > > Mike (zmike) > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Mon, 2020-06-15 at 06:19 +0300, Mihai wrote: > Hello, > Looks much better than the old one. > But quick question: > Why does 'More information' links from 'supported drivers- > >radeonsi/RADV' point to amdgpu-pro installation instructions? > > Perhaps it should point to this one instead: > https://www.x.org/wiki/RadeonFeature/ ? Yeah, perhaps that would be better. Pathces welcome! :) > On Sun, Jun 14, 2020, 7:56 PM Timur Kristóf > wrote: > > Hey Everyone, > > > > I've noticed a weird change on the new website, specifically on the > > release notes page, such as this one: > > https://docs.mesa3d.org/relnotes/20.1.0.html > > > > On the old site, the commits were grouped by authors. On the new > > site, > > there is no mention of the people who contributed to a release, > > only > > the list of commits is presented. > > > > Is this intentional? > > Could we change it back? > > > > I really liked how the old site gave a mention to everyone > > involved. > > > > Best regards, > > Timur > > > > > > On Sun, 2020-06-14 at 18:22 +0200, Dieter Nützel wrote: > > > GREAT work! > > > > > > Now, it's working with Konqueror (20.04.1 / Frameworks 5.70.0) - > > even > > > if > > > without 'hovered animation'... ;-) > > > > > > Greetings, > > > Dieter > > > > > > Am 14.06.2020 17:25, schrieb Daniel Stone: > > > > Hi, > > > > > > > > On Fri, 29 May 2020 at 10:08, Erik Faye-Lund > > > > wrote: > > > > > In the light of the explanation above, do you still have > > > > > objections to > > > > > this split? > > > > > > > > > > Obviously, we haven't moved forward yet ;-) > > > > > > > > Well, we have now after getting some agreement. Please enjoy > > your > > > > shiny new https://www.mesa3d.org and https://docs.mesa3d.org > > > > experience. > > > > > > > > Brian, could you please change the DNS for mesa3d.org and > > > > www.mesa3d.org to point to 35.227.58.183? No need to change > > > > archive.mesa3d.org, that should still point to the old site. > > > > > > > > Cheers, > > > > 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 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
Re: [Mesa-dev] New Mesa3D.org website proposal
On Sun, 2020-06-14 at 18:56 +0200, Timur Kristóf wrote: > Hey Everyone, > > I've noticed a weird change on the new website, specifically on the > release notes page, such as this one: > https://docs.mesa3d.org/relnotes/20.1.0.html > > On the old site, the commits were grouped by authors. On the new > site, > there is no mention of the people who contributed to a release, only > the list of commits is presented. > > Is this intentional? > Could we change it back? > > I really liked how the old site gave a mention to everyone involved. > Ouch, that's a mistake, indeed. Thanks for pointing it out. It seems the problem is that the way this was done was invalid HTML in the first place, throwing the conversion tool (pandoc) off. It seems like it's not legal to have -elements as childen on the -tag. I'll see if I can code up something to fix this. > Best regards, > Timur > > > On Sun, 2020-06-14 at 18:22 +0200, Dieter Nützel wrote: > > GREAT work! > > > > Now, it's working with Konqueror (20.04.1 / Frameworks 5.70.0) - > > even > > if > > without 'hovered animation'... ;-) > > > > Greetings, > > Dieter > > > > Am 14.06.2020 17:25, schrieb Daniel Stone: > > > Hi, > > > > > > On Fri, 29 May 2020 at 10:08, Erik Faye-Lund > > > wrote: > > > > In the light of the explanation above, do you still have > > > > objections to > > > > this split? > > > > > > > > Obviously, we haven't moved forward yet ;-) > > > > > > Well, we have now after getting some agreement. Please enjoy your > > > shiny new https://www.mesa3d.org and https://docs.mesa3d.org > > > experience. > > > > > > Brian, could you please change the DNS for mesa3d.org and > > > www.mesa3d.org to point to 35.227.58.183? No need to change > > > archive.mesa3d.org, that should still point to the old site. > > > > > > Cheers, > > > 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 mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Wed, 2020-05-13 at 15:00 +0200, Erik Faye-Lund wrote: > On Wed, 2020-05-13 at 06:43 -0600, Brian Paul wrote: > > On 05/13/2020 03:13 AM, Erik Faye-Lund wrote: > > > On Tue, 2020-05-12 at 12:17 +0200, Erik Faye-Lund wrote: > > > > On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote: > > > > > On 05/07/2020 04:33 AM, Erik Faye-Lund wrote: > > > > > > Hey Brian > > > > > > > > > > > > TLDR; are you OK with me moving forward with the rework of > > > > > > mesa3d.org? > > > > > > > > > > Yes... > > > > > > > > > > > > > Cool! We've now set up a repo here: > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa3d.orgdata=02%7C01%7Cbrianp%40vmware.com%7Cb8ff6d838d46414812f208d7f71df219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249580306260765sdata=CLd07g8WPm7mbsa3033pnhycK25xPD5%2Bi00V0MJ6TIY%3Dreserved=0 > > > > > > > > I pushed the bare minimum (ish) there so far, and sent a MR for > > > > the > > > > importing of the news and article-redirects. This is now being > > > > served > > > > here: > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmesa.pages.freedesktop.org%2Fmesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cb8ff6d838d46414812f208d7f71df219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249580306260765sdata=GmaivI1wH4HR6osRoP%2FINlJm%2FgZ6tgb8HsE1ElVhZNE%3Dreserved=0 > > > > > > > > > > A few updates: > > > > > > 1. You can now preview the repo with the pending MRs merged here, > > > if > > > you're interested: > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkusma.pages.freedesktop.org%2Fmesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cb8ff6d838d46414812f208d7f71df219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249580306260765sdata=U7cC71x9ql%2FCNXpdNxO2%2But3NAVzDo6S91%2BmevJjMsc%3Dreserved=0 > > > > > > 2. Some people have been asking me why the website is set up as a > > > separate repo rather than a subdirectory inside the main mesa > > > repo. > > > > > > The quick answer to that is that it seemed more logical that way > > > to > > > me. > > > The website isn't really tied to the mesa release-schedule, apart > > > from > > > linking to new releases. It's really its own thing. We might for > > > instance want to post updates when other projects in the mesa- > > > group > > > cuts a release. So this seems to give us some more freedom. > > > > > > If someone has good arguments against this, I'm open to changing > > > it. > > > But this seems like the best option to me. > > > > I'd really like to keep the Mesa content as part of the main Mesa > > repo. > > I didn't realize you did that. The website is part of the project > > and > > it's more convenient to have it all in one place. > > I agree that for a lot of the content, that's the case. But this is > kind of the point here: Some stuff doesn't relate to the code, and > those are the things that I've proposed to move out. > > Right now, the website only contains this: > 1. A brief introduction of APIs and drivers > 2. News > 3. Instructions on how update the website > > Only 1 is somewhat related to the code, but at a very shallow level, > and the information changes on a very slow rate. Keeping this up-to > date doesn't seem like a big burden to me. > > News relate to releases, but not to the state of the code itself. > > Instructions on how to update the website is website-metainfo, and > doesn't relate to the code. > > Everything else is still in the repo, which will be hosted at > docs.mesa3d.org. And I think this is the content that is convenient > to > update together with the code. > > So, I don't think there's any real inconvenience introduced here. We > should thread carefully in what content we migrate out of the main > repository. > > Having content in the main repository also leads to some issues, like > finding the right content for the right release. It can be > frustrating > to read content that is more up-to-date than the version you're > using. > > This work doesn't solve that right now, but it's taking a step in > that > direction: We can start versioning the technical documentation, while > still allowing people to see up-to-date news. This could easily be > finished off by moving docs.mesa3d.org to be hosted at > readthedocs.org, > which supports multiple versions. I already did a test-intgration of > that, and it was trivial, but I didn't like the added ads, so I'm > holding off on it for now. > > But I would very much like to see versioned docs as a future step. > Brian, In the light of the explanation above, do you still have objections to this split? Obviously, we haven't moved forward yet ;-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Wed, 2020-05-13 at 06:43 -0600, Brian Paul wrote: > On 05/13/2020 03:13 AM, Erik Faye-Lund wrote: > > On Tue, 2020-05-12 at 12:17 +0200, Erik Faye-Lund wrote: > > > On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote: > > > > On 05/07/2020 04:33 AM, Erik Faye-Lund wrote: > > > > > Hey Brian > > > > > > > > > > TLDR; are you OK with me moving forward with the rework of > > > > > mesa3d.org? > > > > > > > > Yes... > > > > > > > > > > Cool! We've now set up a repo here: > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa3d.orgdata=02%7C01%7Cbrianp%40vmware.com%7Cb8ff6d838d46414812f208d7f71df219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249580306260765sdata=CLd07g8WPm7mbsa3033pnhycK25xPD5%2Bi00V0MJ6TIY%3Dreserved=0 > > > > > > I pushed the bare minimum (ish) there so far, and sent a MR for > > > the > > > importing of the news and article-redirects. This is now being > > > served > > > here: > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmesa.pages.freedesktop.org%2Fmesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cb8ff6d838d46414812f208d7f71df219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249580306260765sdata=GmaivI1wH4HR6osRoP%2FINlJm%2FgZ6tgb8HsE1ElVhZNE%3Dreserved=0 > > > > > > > A few updates: > > > > 1. You can now preview the repo with the pending MRs merged here, > > if > > you're interested: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkusma.pages.freedesktop.org%2Fmesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cb8ff6d838d46414812f208d7f71df219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249580306260765sdata=U7cC71x9ql%2FCNXpdNxO2%2But3NAVzDo6S91%2BmevJjMsc%3Dreserved=0 > > > > 2. Some people have been asking me why the website is set up as a > > separate repo rather than a subdirectory inside the main mesa repo. > > > > The quick answer to that is that it seemed more logical that way to > > me. > > The website isn't really tied to the mesa release-schedule, apart > > from > > linking to new releases. It's really its own thing. We might for > > instance want to post updates when other projects in the mesa-group > > cuts a release. So this seems to give us some more freedom. > > > > If someone has good arguments against this, I'm open to changing > > it. > > But this seems like the best option to me. > > I'd really like to keep the Mesa content as part of the main Mesa > repo. > I didn't realize you did that. The website is part of the project > and > it's more convenient to have it all in one place. I agree that for a lot of the content, that's the case. But this is kind of the point here: Some stuff doesn't relate to the code, and those are the things that I've proposed to move out. Right now, the website only contains this: 1. A brief introduction of APIs and drivers 2. News 3. Instructions on how update the website Only 1 is somewhat related to the code, but at a very shallow level, and the information changes on a very slow rate. Keeping this up-to date doesn't seem like a big burden to me. News relate to releases, but not to the state of the code itself. Instructions on how to update the website is website-metainfo, and doesn't relate to the code. Everything else is still in the repo, which will be hosted at docs.mesa3d.org. And I think this is the content that is convenient to update together with the code. So, I don't think there's any real inconvenience introduced here. We should thread carefully in what content we migrate out of the main repository. Having content in the main repository also leads to some issues, like finding the right content for the right release. It can be frustrating to read content that is more up-to-date than the version you're using. This work doesn't solve that right now, but it's taking a step in that direction: We can start versioning the technical documentation, while still allowing people to see up-to-date news. This could easily be finished off by moving docs.mesa3d.org to be hosted at readthedocs.org, which supports multiple versions. I already did a test-intgration of that, and it was trivial, but I didn't like the added ads, so I'm holding off on it for now. But I would very much like to see versioned docs as a future step. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Tue, 2020-05-12 at 12:17 +0200, Erik Faye-Lund wrote: > On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote: > > On 05/07/2020 04:33 AM, Erik Faye-Lund wrote: > > > Hey Brian > > > > > > TLDR; are you OK with me moving forward with the rework of > > > mesa3d.org? > > > > Yes... > > > > Cool! We've now set up a repo here: > > https://gitlab.freedesktop.org/mesa/mesa3d.org > > I pushed the bare minimum (ish) there so far, and sent a MR for the > importing of the news and article-redirects. This is now being served > here: > > https://mesa.pages.freedesktop.org/mesa3d.org/ > A few updates: 1. You can now preview the repo with the pending MRs merged here, if you're interested: https://kusma.pages.freedesktop.org/mesa3d.org/ 2. Some people have been asking me why the website is set up as a separate repo rather than a subdirectory inside the main mesa repo. The quick answer to that is that it seemed more logical that way to me. The website isn't really tied to the mesa release-schedule, apart from linking to new releases. It's really its own thing. We might for instance want to post updates when other projects in the mesa-group cuts a release. So this seems to give us some more freedom. If someone has good arguments against this, I'm open to changing it. But this seems like the best option to me. 3. Last but not least, I've been discussing deployment timeline with a few stakeholders, and want to hijack this thread for bringing all of these in the loop. As far as I know, what's left to do is: - Set up NGINX redirects for mesa3d.org/archive/* -> archive.mesa3d.org/* - Wait for the go-signal from Mesa release-managers (read below) - Update and merge https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4630 - Update and merge https://gitlab.freedesktop.org/mesa/mesa3d.org/-/merge_requests/5 - Switch over the DNS to point to the GitLab pages host Eric told me that Thursdays would generally be the best option for doing the switch-over, right after cutting a release. This would give us the most time to correct any fallouts until the next release cycle. So, how do people feel about making the switch-over tomorrow? Is that too early? Maybe we should wait at least one more week? Is there anything else I'm missing? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Tue, 2020-05-12 at 15:11 +0200, Erik Faye-Lund wrote: > On Tue, 2020-05-12 at 06:42 -0600, Brian Paul wrote: > > On 05/12/2020 04:17 AM, Erik Faye-Lund wrote: > > > On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote: > > > > On 05/07/2020 04:33 AM, Erik Faye-Lund wrote: > > > > > Hey Brian > > > > > > > > > > TLDR; are you OK with me moving forward with the rework of > > > > > mesa3d.org? > > > > > > > > Yes... > > > > > > > > > > Cool! We've now set up a repo here: > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa3d.orgdata=02%7C01%7Cbrianp%40vmware.com%7Cbec2daa6980541c021b808d7f65dc01e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637248754836107148sdata=jJhAo5v%2F28EhqaFiu6HiElJMYO1amsLeIqMf5F%2B8kpQ%3Dreserved=0 > > > > > > I pushed the bare minimum (ish) there so far, and sent a MR for > > > the > > > importing of the news and article-redirects. This is now being > > > served > > > here: > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmesa.pages.freedesktop.org%2Fmesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cbec2daa6980541c021b808d7f65dc01e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637248754836107148sdata=vchFG3oWUyBzi9lo2TH1keLAyNNn75Hsa226ggB2Mws%3Dreserved=0 > > > > The formatting of the text under "Featured APIs" is > > inconsistent. For > > example, the size of "OpenGL", "Vulkan", "EGL", etc. is much > > smaller > > than for "OpenCL". > > That's because we're seeing the "alt"-text instead of the logos. This > will be fixed when we're no longer hosted from a subdir, or > https://gitlab.freedesktop.org/mesa/mesa3d.org/-/merge_requests/2 > lands. > > > Maybe under "Supported Drivers" the drivers which are "no longer > > actively developed" should go to the bottom of the list under a > > sub-heading. It seems a bit pessimistic to start the list with > > unsupported hardware. :) > > Sure, sounds like a good idea. But which drivers exactly do you want > me > to move out to a legacy-list? Never mind, I just realized we spell that out in the description. So yeah, here you go: https://gitlab.freedesktop.org/mesa/mesa3d.org/-/merge_requests/3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote: > On 05/07/2020 04:33 AM, Erik Faye-Lund wrote: > > Hey Brian > > > > TLDR; are you OK with me moving forward with the rework of > > mesa3d.org? > > Yes... > Cool! We've now set up a repo here: https://gitlab.freedesktop.org/mesa/mesa3d.org I pushed the bare minimum (ish) there so far, and sent a MR for the importing of the news and article-redirects. This is now being served here: https://mesa.pages.freedesktop.org/mesa3d.org/ (there's a problem with some URLs, due to me not setting --baseURL, sent an MR for that as well) I have a work-in-progress version of a rewritten webmaster.html (turned into a more of an "about mesa3d.org"-page), describing how the site is (well, will be once we're done) structured, and how to send changes. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote: > On 05/07/2020 04:33 AM, Erik Faye-Lund wrote: > > Hey Brian > > > > TLDR; are you OK with me moving forward with the rework of > > mesa3d.org? > > Yes... Awesome, thanks! > > As you hopefully are aware of, I've been working on a new website > > for > > mesa3d.org, split into a "marketing"-frontpage and a documentation > > page. > > > > You can read more about the structure and details here if you > > haven't > > already: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F4630data=02%7C01%7Cbrianp%40vmware.com%7C6998774738b349bcb79108d7f2720ca6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63723970864799sdata=1Z%2B3KKoVjNLHRvIf2VbK7KHSM4kh10fZQ1zdfPsguA0%3Dreserved=0 > > > > That MR only deals with the marketing website, so I think it's time > > to > > talk more about the main website. What I currently have is located > > here: > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fkusma%2Fkusma.pages.freedesktop.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7C6998774738b349bcb79108d7f2720ca6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63723970864799sdata=ttMgZuWT%2Bgg19H9qx1XmUQgl%2FO%2FlFF3vZuGkKxQGC9g%3Dreserved=0 > > > > This builds on CI and currently gets served here: > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkusma.pages.freedesktop.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7C6998774738b349bcb79108d7f2720ca6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63723970864799sdata=258fUaF1DrIioGS1VTROkJznMNjI3xhxmbdl9RWyJZU%3Dreserved=0 > > It seems like only the front page is served at the moment. Is it > possible to get a look at the rest? The front page looks nice. > Yeah, we need to set up docs.mesa3d.org first. I haven't bothered setting up the temporary URLs yet, but my current preview is hosted here: https://kusma.pages.freedesktop.org/mesa/ It's a plain readthedocs-themed Sphinx site, which is a reasonably popular way of serving docs. This is all cooking here right now: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4630 > > > > Since last time I published any details about this, I've: > > 1. Switched the static-site-generator from Jekyll to Hugo. This > > lead to > > a build-time decrease from about two minutes to about 200ms on my > > machine. This makes iteration times a lot more bearable. > > 2. Back-paddled on moving some pages. I think we can hold off on > > moving > > pages to the website until the initial work lands. > > 3. Gotten approval from the Khronos marketing team about the usage > > of > > their logos / trademarks. They had some minor requests for changes, > > which has been taken into account. > > > > The news articles and redirects for URL compatibility is converted > > from > > a branch in my Mesa fork, here: > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fkusma%2Fmesa%2F-%2Ftree%2Fdocs-convert-news-hugodata=02%7C01%7Cbrianp%40vmware.com%7C6998774738b349bcb79108d7f2720ca6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63723970864799sdata=rmXuKgyMFAZqJD4ij%2F8mR1EvA4HvFYwnR5Gd%2BCdgJFM%3Dreserved=0 > > > > So, after a long introduction (sorry if a lot of this is stuff you > > already know), what I really want is for you Brian, as the project > > originator and listed webmaster, to say how you feel about all of > > this. > > Please remove me as the webmaster. I still occasionally get emails > from > that. Let readers know how to submit changes/edits. > OK, will do! > > If you're happy to move forward with this, I will start the > > technical > > discussions with the FDO admins and other people who might need to > > be > > involved in setting this up for production. > > Yeah, go ahead. Sorry for not monitoring this work. I basically > have > zero time for Mesa nowadays. That's fine, and thank you for your blessing! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Thu, 2020-05-07 at 16:49 +0200, Eric Engestrom wrote: > On Thursday, 2020-05-07 16:26:19 +0200, Erik Faye-Lund wrote: > > On Thu, 2020-05-07 at 16:18 +0200, Eric Engestrom wrote: > > > On Thursday, 2020-05-07 16:07:00 +0200, Erik Faye-Lund wrote: > > > > On Thu, 2020-05-07 at 09:05 -0500, Jason Ekstrand wrote: > > > > > Looks shiny but > > > > > > > > > > We need to be very careful here. One of the big no-nos with > > > > > Khronos > > > > > trademark rules is using logos for things where > > > > > implementations > > > > > aren't > > > > > conformant. Mesa has been living in a mirky in-between land > > > > > for > > > > > a > > > > > while and everything has been mostly fine. We've been very > > > > > careful > > > > > to > > > > > *not* say that Mesa is an implementation of any Khronos APIs. > > > > > Instead, we say that Mesa is an open-source software project > > > > > that > > > > > contains implementations and that some of those > > > > > implementations > > > > > are > > > > > conformant. That page full of logos makes me concerned that > > > > > we're > > > > > going to risk getting into trouble. Khronos marketing cares > > > > > A > > > > > LOT > > > > > about logos. > > > > > > > > As I wrote in the e-mail, I've already clarified the logo-usage > > > > with > > > > Khronos. They are happy with it as-is. > > > > > > Could you post their concerns/guidelines here, so that we can all > > > know > > > what can and cannot be on the website and make sure we never > > > cross > > > the > > > line with future changes? > > > > You can find their logo guidelines here: > > https://www.khronos.org/legal/trademarks/ > > > > But because Mesa is in a special eternal conformant/non-conformant > > limbo, I sent an email to clarify. I've posted the response I got > > here: > > > > https://gitlab.freedesktop.org/snippets/996 > > > > I think the first link is going to be what most people care about, > > though. > > OK, so basically > - make sure we use the up-to-date, unmodified logos from Khronos > - make sure we are clearly stating that the project is not conformant > as a whole, > but as you said only some "combinations of drivers and APIs" are. > > I think that should be easy enough to not mess up :) Yeah, I think it's pretty easy to conform to :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Thu, 2020-05-07 at 16:18 +0200, Eric Engestrom wrote: > On Thursday, 2020-05-07 16:07:00 +0200, Erik Faye-Lund wrote: > > On Thu, 2020-05-07 at 09:05 -0500, Jason Ekstrand wrote: > > > Looks shiny but > > > > > > We need to be very careful here. One of the big no-nos with > > > Khronos > > > trademark rules is using logos for things where implementations > > > aren't > > > conformant. Mesa has been living in a mirky in-between land for > > > a > > > while and everything has been mostly fine. We've been very > > > careful > > > to > > > *not* say that Mesa is an implementation of any Khronos APIs. > > > Instead, we say that Mesa is an open-source software project that > > > contains implementations and that some of those implementations > > > are > > > conformant. That page full of logos makes me concerned that > > > we're > > > going to risk getting into trouble. Khronos marketing cares A > > > LOT > > > about logos. > > > > As I wrote in the e-mail, I've already clarified the logo-usage > > with > > Khronos. They are happy with it as-is. > > Could you post their concerns/guidelines here, so that we can all > know > what can and cannot be on the website and make sure we never cross > the > line with future changes? You can find their logo guidelines here: https://www.khronos.org/legal/trademarks/ But because Mesa is in a special eternal conformant/non-conformant limbo, I sent an email to clarify. I've posted the response I got here: https://gitlab.freedesktop.org/snippets/996 I think the first link is going to be what most people care about, though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Thu, 2020-05-07 at 09:05 -0500, Jason Ekstrand wrote: > Looks shiny but > > We need to be very careful here. One of the big no-nos with Khronos > trademark rules is using logos for things where implementations > aren't > conformant. Mesa has been living in a mirky in-between land for a > while and everything has been mostly fine. We've been very careful > to > *not* say that Mesa is an implementation of any Khronos APIs. > Instead, we say that Mesa is an open-source software project that > contains implementations and that some of those implementations are > conformant. That page full of logos makes me concerned that we're > going to risk getting into trouble. Khronos marketing cares A LOT > about logos. As I wrote in the e-mail, I've already clarified the logo-usage with Khronos. They are happy with it as-is. > On Thu, May 7, 2020 at 5:33 AM Erik Faye-Lund > wrote: > > Hey Brian > > > > TLDR; are you OK with me moving forward with the rework of > > mesa3d.org? > > > > As you hopefully are aware of, I've been working on a new website > > for > > mesa3d.org, split into a "marketing"-frontpage and a documentation > > page. > > > > You can read more about the structure and details here if you > > haven't > > already: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4630 > > > > That MR only deals with the marketing website, so I think it's time > > to > > talk more about the main website. What I currently have is located > > here: > > > > https://gitlab.freedesktop.org/kusma/kusma.pages.freedesktop.org/ > > > > This builds on CI and currently gets served here: > > > > https://kusma.pages.freedesktop.org/ > > > > > > Since last time I published any details about this, I've: > > 1. Switched the static-site-generator from Jekyll to Hugo. This > > lead to > > a build-time decrease from about two minutes to about 200ms on my > > machine. This makes iteration times a lot more bearable. > > 2. Back-paddled on moving some pages. I think we can hold off on > > moving > > pages to the website until the initial work lands. > > 3. Gotten approval from the Khronos marketing team about the usage > > of > > their logos / trademarks. They had some minor requests for changes, > > which has been taken into account. > > > > The news articles and redirects for URL compatibility is converted > > from > > a branch in my Mesa fork, here: > > > > https://gitlab.freedesktop.org/kusma/mesa/-/tree/docs-convert-news-hugo > > > > So, after a long introduction (sorry if a lot of this is stuff you > > already know), what I really want is for you Brian, as the project > > originator and listed webmaster, to say how you feel about all of > > this. > > > > If you're happy to move forward with this, I will start the > > technical > > discussions with the FDO admins and other people who might need to > > be > > involved in setting this up for production. > > > > > > ___ > > 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] New Mesa3D.org website proposal
Hey Brian TLDR; are you OK with me moving forward with the rework of mesa3d.org? As you hopefully are aware of, I've been working on a new website for mesa3d.org, split into a "marketing"-frontpage and a documentation page. You can read more about the structure and details here if you haven't already: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4630 That MR only deals with the marketing website, so I think it's time to talk more about the main website. What I currently have is located here: https://gitlab.freedesktop.org/kusma/kusma.pages.freedesktop.org/ This builds on CI and currently gets served here: https://kusma.pages.freedesktop.org/ Since last time I published any details about this, I've: 1. Switched the static-site-generator from Jekyll to Hugo. This lead to a build-time decrease from about two minutes to about 200ms on my machine. This makes iteration times a lot more bearable. 2. Back-paddled on moving some pages. I think we can hold off on moving pages to the website until the initial work lands. 3. Gotten approval from the Khronos marketing team about the usage of their logos / trademarks. They had some minor requests for changes, which has been taken into account. The news articles and redirects for URL compatibility is converted from a branch in my Mesa fork, here: https://gitlab.freedesktop.org/kusma/mesa/-/tree/docs-convert-news-hugo So, after a long introduction (sorry if a lot of this is stuff you already know), what I really want is for you Brian, as the project originator and listed webmaster, to say how you feel about all of this. If you're happy to move forward with this, I will start the technical discussions with the FDO admins and other people who might need to be involved in setting this up for production. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] nir: find_msb vs clz
While working on the NIR to DXIL conversion code for D3D12, I've noticed that we're not exactly doing the best we could here. First some background: NIR currently has a few instructions that does kinda the same: 1. nir_op_ufind_msb: Finds the index of the most significant bit, counting from the least significant bit. It returns -1 on zero-input. 2. nir_op_ifind_msb: A signed version of ufind_msb; looks for the first non sign-bit. It's not terribly interesting in this context, as it can be trivially lowered if missing, and it doesn't seem like any hardware supports this natively. I'm just mentioning it for completeness. 3. nir_op_uclz: Counts the amount of leading zeroes, counding from the most significant bit. It returns 32 on zero-input, and only exist in an unsigned 32-bit variation. ufind_msb is kinda the O.G here, uclz was recently added, and is as far as I can see only used in an intel-specific SPIR-V instruction. Additionally, there's the OpenCLstd_Clz SPIR-V instruction, which we lower to ufind_msb using nir_clz_u(), regardless if the backend supports nir_op_uclz or not. It seems only the nouveau's NV50 backend actually wants ufind_msb, everything else seems to convert ufind_msb to some clz-variant while emitting code. Some have to special-case on zero-input, and some not... All of this is not really awesome in my eyes. So, while adding support for DXIL, I need to figure out how to map these (well, ufind_msb at least) onto the DXIL intrinsics. DXIL doesn't have a ufind_msb, but it has a firstbit_hi that is identical to nir_op_uclz... except that it returns -1 on zero-input :( For now, I'm lowering ufind_msb to something ufind_msb while emitting code, like everyone else. But this feels a bit dirty, *especially* since we have a clz-instruction that *almost* fits. And since we're targetting OpenCL, which use clz as it's primitive, we end up doing 32 - (32 - x), and since that inner isub happens while emitting, we can't easily optimize it away without introducing an optimizing backend... The solution seems obvious; use nir_op_uclz instead. But that's also a bit annoying, for a few reasons: 1. Only *one* backend actually implements support for it. So this either means a lot of work, or making it an opt-in feature somehow. 2. We would probably have to support lowering in either direction to support what all hardware prefers. 3. That zero-case still needs special treatment in several backends, it seems. We could alternatively declare that nir_op_uclz is undefined for zero-input, and handle this when lowering...? 4. It seems some (Intel?) hardware only supports 32-bit clz, so we would have to lower to something else for other bit-sizes. That's not too hard, though. So yeah... I guess the first step would be to add a switch to use nir_uclz() instead of nir_clz_u() when handling OpenCLstd_Clz in vtn. Next, I guess I would add a lower_ufind_msb flag to nir_shader_compiler_options, and make nir_opt_algebraic.py lower ufind_msb to uclz. Finally, we can start implementing support for this in more drivers, and flip on some switches. I'm still not really sold on what to do about the special-case for zero... By making it undefined, I think we're just punishing all backends, just in the name of making the compiler backends a bit simpler, so that doesn't seem too good of an idea either. Does anyone have a better idea? I would kinda love to optimize away the zero-case if it's obvious that it's impossible, e.g cases like "clz(x | 1)"... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 19.3.5
On Mon, 2020-03-09 at 23:55 +0100, Eric Engestrom wrote: > I'd like to announce the release of Mesa 19.3.5, final release of the > 19.3.x series. > You are encouraged to migrate to 20.0.1, released a few days ago, in > order to obtain future fixes. > > Most fixes in this release are for Intel, followed by AMD, and a few > scattered fixes here and there. > > Cheers, > Eric > > --- > > Andrii Simiklit (1): > Revert "glx: convert glx_config_create_list to one big calloc" > > Arcady Goldmints-Orlov (1): > spirv: Remove outdated SPIR-V decoration warnings > > Caio Marcelo de Oliveira Filho (1): > intel/gen12: Take into account opcode when decoding SWSB > > Danylo Piliaiev (1): > i965: Do not generate D16 B5G6R5_UNORM configs on gen < 8 > > Dave Airlie (1): > gallivm/tgsi: fix stream id regression > > Dylan Baker (7): > docs: Add SHA256 sum for 19.3.4 > .pick_status.json: Update to > 2a98cf3b2ecea43cea148df7f77d2abadfd1c9db > .pick_status.json: Update to > 946eacbafb47c8b94d47e7c9d2a8b02fff5a22fa > .pick_status.json: Update to > bee5c9b0dc13dbae0ccf124124eaccebf7f2a435 > .pick_status.json: Update to > 8291d728dc997e87b4d2e4e451692643a1dba881 > .pick_status.json: Update to > e4baff90812d799d586296fcad992ddcc553c359 > .pick_status.json: Update to > 01496e3d1ea0370af03e6645dbd2b864c2ace94c > > Eric Engestrom (12): > .pick_status.json: Update to > 74e4cda64b9d114321216eefe536f80644b0f0fd > .pick_status.json: Mark > dba71de5c63617677fe44558f995d35fad643413 as denominated > .pick_status.json: Mark > 5ea23ba659adc05ff75ca7a4c9d1bd01db889ddd as denominated > .pick_status.json: Mark > 34fd894e42ae1ec9d35bf9c4f05364b03dd4a223 as denominated > .pick_status.json: Mark > ddd767387f336ed1578f171a2af4ca33c564d7f3 as denominated > .pick_status.json: Mark > b9773631d3e79e2310ed0eb274b4dd9426205066 as denominated > .pick_status.json: Mark > 9fea90ad5170dd64376d22a14ac88c392813c96c as denominated > bin/gen_release_notes.py: fix commit list command > .pick_status.json: Update to > 0103f02acb10dcdea23461ba214307a6827a7772 > gitlab-ci: update template to fix container build issues > docs: add release notes for 19.3.5 > VERSION: bump version to 19.3.5 > > Erik Faye-Lund (2): > util: promote u_debug_memory.c to src/util > .pick_status.json: Update to > 74e4cda64b9d114321216eefe536f80644b0f0fd Uhm, what? :-P ___ 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
On Fri, 2020-02-28 at 10:43 +, Daniel Stone wrote: > On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund > wrote: > > On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote: > > > Yeah, changes on vulkan drivers or backend compilers should be > > > fairly > > > sandboxed. > > > > > > We also have tools that only work for intel stuff, that should > > > never > > > trigger anything on other people's HW. > > > > > > Could something be worked out using the tags? > > > > I think so! We have the pre-defined environment variable > > CI_MERGE_REQUEST_LABELS, and we can do variable conditions: > > > > https://docs.gitlab.com/ee/ci/yaml/#onlyvariablesexceptvariables > > > > That sounds like a pretty neat middle-ground to me. I just hope > > that > > new pipelines are triggered if new labels are added, because not > > everyone is allowed to set labels, and sometimes people forget... > > There's also this which is somewhat more robust: > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569 > > I'm not sure it's more robust, but yeah that a useful tool too. The reason I'm skeptical about the robustness is that we'll miss testing if this misses a path. That can of course be fixed by testing everything once things are in master, and fixing up that list when something breaks on master. The person who wrote a change knows more about the intricacies of the changes than a computer will ever do. But humans are also good at making mistakes, so I'm not sure which one is better. Maybe the union of both? As long as we have both rigorous testing after something landed in master (doesn't nessecarily need to happen right after, but for now that's probably fine), as well as a reasonable heuristic for what testing is needed pre-merge, I think we're good. ___ 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
On Fri, 2020-02-28 at 10:47 +0100, Daniel Vetter wrote: > On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund > wrote: > > On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote: > > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter < > > > daniel.vet...@ffwll.ch> > > > wrote: > > > > Hi all, > > > > > > > > You might have read the short take in the X.org board meeting > > > > minutes > > > > already, here's the long version. > > > > > > > > The good news: gitlab.fd.o has become very popular with our > > > > communities, and is used extensively. This especially includes > > > > all > > > > the > > > > CI integration. Modern development process and tooling, yay! > > > > > > > > The bad news: The cost in growth has also been tremendous, and > > > > it's > > > > breaking our bank account. With reasonable estimates for > > > > continued > > > > growth we're expecting hosting expenses totalling 75k USD this > > > > year, > > > > and 90k USD next year. With the current sponsors we've set up > > > > we > > > > can't > > > > sustain that. We estimate that hosting expenses for gitlab.fd.o > > > > without any of the CI features enabled would total 30k USD, > > > > which > > > > is > > > > within X.org's ability to support through various sponsorships, > > > > mostly > > > > through XDC. > > > > > > > > Note that X.org does no longer sponsor any CI runners > > > > themselves, > > > > we've stopped that. The huge additional expenses are all just > > > > in > > > > storing and serving build artifacts and images to outside CI > > > > runners > > > > sponsored by various companies. A related topic is that with > > > > the > > > > growth in fd.o it's becoming infeasible to maintain it all on > > > > volunteer admin time. X.org is therefore also looking for admin > > > > sponsorship, at least medium term. > > > > > > > > Assuming that we want cash flow reserves for one year of > > > > gitlab.fd.o > > > > (without CI support) and a trimmed XDC and assuming no sponsor > > > > payment > > > > meanwhile, we'd have to cut CI services somewhere between May > > > > and > > > > June > > > > this year. The board is of course working on acquiring > > > > sponsors, > > > > but > > > > filling a shortfall of this magnitude is neither easy nor quick > > > > work, > > > > and we therefore decided to give an early warning as soon as > > > > possible. > > > > Any help in finding sponsors for fd.o is very much appreciated. > > > > > > a) Ouch. > > > > > > b) we probably need to take a large step back here. > > > > > > > I kinda agree, but maybe the step doesn't have to be *too* large? > > > > I wonder if we could solve this by restructuring the project a bit. > > I'm > > talking purely from a Mesa point of view here, so it might not > > solve > > the full problem, but: > > > > 1. It feels silly that we need to test changes to e.g the i965 > > driver > > on dragonboards. We only have a big "do not run CI at all" escape- > > hatch. > > > > 2. A lot of us are working for a company that can probably pay for > > their own needs in terms of CI. Perhaps moving some costs "up > > front" to > > the company that needs it can make the future of CI for those who > > can't > > do this > > > > 3. I think we need a much more detailed break-down of the cost to > > make > > educated changes. For instance, how expensive is Docker image > > uploads/downloads (e.g intermediary artifacts) compared to build > > logs > > and final test-results? What kind of artifacts? > > We have logs somewhere, but no one yet got around to analyzing that. > Which will be quite a bit of work to do since the cloud storage is > totally disconnected from the gitlab front-end, making the connection > to which project or CI job caused something is going to require > scripting. Volunteers definitely very much welcome I think. > Fair enough, but just keep in mind that the same thing as optimizing software applies here; working blindly reduces the impact. So if we want to fix the current situation, this is going to have to be a p
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote: > On 28/02/2020 11:28, Erik Faye-Lund wrote: > > On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote: > > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter < > > > daniel.vet...@ffwll.ch> > > > wrote: > > > > Hi all, > > > > > > > > You might have read the short take in the X.org board meeting > > > > minutes > > > > already, here's the long version. > > > > > > > > The good news: gitlab.fd.o has become very popular with our > > > > communities, and is used extensively. This especially includes > > > > all > > > > the > > > > CI integration. Modern development process and tooling, yay! > > > > > > > > The bad news: The cost in growth has also been tremendous, and > > > > it's > > > > breaking our bank account. With reasonable estimates for > > > > continued > > > > growth we're expecting hosting expenses totalling 75k USD this > > > > year, > > > > and 90k USD next year. With the current sponsors we've set up > > > > we > > > > can't > > > > sustain that. We estimate that hosting expenses for gitlab.fd.o > > > > without any of the CI features enabled would total 30k USD, > > > > which > > > > is > > > > within X.org's ability to support through various sponsorships, > > > > mostly > > > > through XDC. > > > > > > > > Note that X.org does no longer sponsor any CI runners > > > > themselves, > > > > we've stopped that. The huge additional expenses are all just > > > > in > > > > storing and serving build artifacts and images to outside CI > > > > runners > > > > sponsored by various companies. A related topic is that with > > > > the > > > > growth in fd.o it's becoming infeasible to maintain it all on > > > > volunteer admin time. X.org is therefore also looking for admin > > > > sponsorship, at least medium term. > > > > > > > > Assuming that we want cash flow reserves for one year of > > > > gitlab.fd.o > > > > (without CI support) and a trimmed XDC and assuming no sponsor > > > > payment > > > > meanwhile, we'd have to cut CI services somewhere between May > > > > and > > > > June > > > > this year. The board is of course working on acquiring > > > > sponsors, > > > > but > > > > filling a shortfall of this magnitude is neither easy nor quick > > > > work, > > > > and we therefore decided to give an early warning as soon as > > > > possible. > > > > Any help in finding sponsors for fd.o is very much appreciated. > > > a) Ouch. > > > > > > b) we probably need to take a large step back here. > > > > > I kinda agree, but maybe the step doesn't have to be *too* large? > > > > I wonder if we could solve this by restructuring the project a bit. > > I'm > > talking purely from a Mesa point of view here, so it might not > > solve > > the full problem, but: > > > > 1. It feels silly that we need to test changes to e.g the i965 > > driver > > on dragonboards. We only have a big "do not run CI at all" escape- > > hatch. > > Yeah, changes on vulkan drivers or backend compilers should be > fairly > sandboxed. > > We also have tools that only work for intel stuff, that should never > trigger anything on other people's HW. > > Could something be worked out using the tags? > I think so! We have the pre-defined environment variable CI_MERGE_REQUEST_LABELS, and we can do variable conditions: https://docs.gitlab.com/ee/ci/yaml/#onlyvariablesexceptvariables That sounds like a pretty neat middle-ground to me. I just hope that new pipelines are triggered if new labels are added, because not everyone is allowed to set labels, and sometimes people forget... ___ 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
On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote: > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter > wrote: > > Hi all, > > > > You might have read the short take in the X.org board meeting > > minutes > > already, here's the long version. > > > > The good news: gitlab.fd.o has become very popular with our > > communities, and is used extensively. This especially includes all > > the > > CI integration. Modern development process and tooling, yay! > > > > The bad news: The cost in growth has also been tremendous, and it's > > breaking our bank account. With reasonable estimates for continued > > growth we're expecting hosting expenses totalling 75k USD this > > year, > > and 90k USD next year. With the current sponsors we've set up we > > can't > > sustain that. We estimate that hosting expenses for gitlab.fd.o > > without any of the CI features enabled would total 30k USD, which > > is > > within X.org's ability to support through various sponsorships, > > mostly > > through XDC. > > > > Note that X.org does no longer sponsor any CI runners themselves, > > we've stopped that. The huge additional expenses are all just in > > storing and serving build artifacts and images to outside CI > > runners > > sponsored by various companies. A related topic is that with the > > growth in fd.o it's becoming infeasible to maintain it all on > > volunteer admin time. X.org is therefore also looking for admin > > sponsorship, at least medium term. > > > > Assuming that we want cash flow reserves for one year of > > gitlab.fd.o > > (without CI support) and a trimmed XDC and assuming no sponsor > > payment > > meanwhile, we'd have to cut CI services somewhere between May and > > June > > this year. The board is of course working on acquiring sponsors, > > but > > filling a shortfall of this magnitude is neither easy nor quick > > work, > > and we therefore decided to give an early warning as soon as > > possible. > > Any help in finding sponsors for fd.o is very much appreciated. > > a) Ouch. > > b) we probably need to take a large step back here. > I kinda agree, but maybe the step doesn't have to be *too* large? I wonder if we could solve this by restructuring the project a bit. I'm talking purely from a Mesa point of view here, so it might not solve the full problem, but: 1. It feels silly that we need to test changes to e.g the i965 driver on dragonboards. We only have a big "do not run CI at all" escape- hatch. 2. A lot of us are working for a company that can probably pay for their own needs in terms of CI. Perhaps moving some costs "up front" to the company that needs it can make the future of CI for those who can't do this 3. I think we need a much more detailed break-down of the cost to make educated changes. For instance, how expensive is Docker image uploads/downloads (e.g intermediary artifacts) compared to build logs and final test-results? What kind of artifacts? One suggestion would be to do something more similar to what the kernel does, and separate into different repos for different subsystems. This could allow us to have separate testing-pipelines for these repos, which would mean that for instance a change to RADV didn't trigger a full Panfrost test-run. This would probably require us to accept using a more branch-heavy work-flow. I don't personally think that would be a bad thing. But this is all kinda based on an assumption that running hardware- testing is the expensive part. I think that's quite possibly the case, but some more numbers would be helpful. I mean, it might turn out that just throwing up a Docker cache inside the organizations that host runners might be sufficient for all I know... We could also do stuff like reducing the amount of tests we run on each commit, and punt some testing to a per-weekend test-run or someting like that. We don't *need* to know about every problem up front, just the stuff that's about to be released, really. The other stuff is just nice to have. If it's too expensive, I would say drop it. I would really hope that we can consider approaches like this before we throw out the baby with the bathwater... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: Add format modifier aux plane query
Seems like you missed zink
On February 5, 2020 9:36:26 PM GMT+01:00, James Jones
wrote:
>Rather than hard-code a list of all the format
>modifiers supported by any gallium driver in
>the dri state tracker, add a screen proc that
>queries the number of auxiliary planes required
>for a given modifier+format pair.
>
>Since the only format modifier that requires
>auxiliary planes currently is the iris driver's
>I915_FORMAT_MOD_Y_TILED_CCS, provide a generic
>implementation of this screen proc as a utility
>function, and use that in every driver besides
>the iris driver, which requires a trivial
>customization on top of it.
>
>Signed-off-by: James Jones
>---
> src/gallium/auxiliary/util/u_screen.c | 35 ++
> src/gallium/auxiliary/util/u_screen.h | 7
> src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
> .../drivers/freedreno/freedreno_screen.c | 1 +
> src/gallium/drivers/iris/iris_resource.c | 17 +
> src/gallium/drivers/lima/lima_screen.c| 1 +
> .../drivers/nouveau/nvc0/nvc0_resource.c | 2 ++
> src/gallium/drivers/tegra/tegra_screen.c | 12 +++
> src/gallium/drivers/v3d/v3d_screen.c | 1 +
> src/gallium/drivers/vc4/vc4_screen.c | 1 +
> src/gallium/include/pipe/p_screen.h | 15
> src/gallium/state_trackers/dri/dri2.c | 36 ---
> 12 files changed, 107 insertions(+), 22 deletions(-)
>
>diff --git a/src/gallium/auxiliary/util/u_screen.c
>b/src/gallium/auxiliary/util/u_screen.c
>index 785d1bd3e24..0697d483372 100644
>--- a/src/gallium/auxiliary/util/u_screen.c
>+++ b/src/gallium/auxiliary/util/u_screen.c
>@@ -412,3 +412,38 @@ u_pipe_screen_get_param_defaults(struct
>pipe_screen *pscreen,
> unreachable("bad PIPE_CAP_*");
>}
> }
>+
>+bool
>+u_pipe_screen_get_modifier_aux_planes(struct pipe_screen *pscreen,
>+ uint64_t modifier,
>+ enum pipe_format format,
>+ unsigned *num_aux_planes)
>+{
>+ int num_mods, i;
>+ uint64_t *supported_mods;
>+
>+ pscreen->query_dmabuf_modifiers(pscreen, format, 0, NULL, NULL,
>+ _mods);
>+
>+ if (!num_mods)
>+ return false;
>+
>+ supported_mods = malloc(num_mods * sizeof(supported_mods[0]));
>+
>+ if (!supported_mods)
>+ return false;
>+
>+ pscreen->query_dmabuf_modifiers(pscreen, format, num_mods,
>supported_mods,
>+ NULL, _mods);
>+
>+ for (i = 0; i < num_mods && supported_mods[i] != modifier; i++);
>+
>+ free(supported_mods);
>+
>+ if (i == num_mods)
>+ return false;
>+
>+ *num_aux_planes = 0;
>+
>+ return true;
>+}
>diff --git a/src/gallium/auxiliary/util/u_screen.h
>b/src/gallium/auxiliary/util/u_screen.h
>index 3952a11f2ca..0abcfd282b1 100644
>--- a/src/gallium/auxiliary/util/u_screen.h
>+++ b/src/gallium/auxiliary/util/u_screen.h
>@@ -23,6 +23,7 @@
>
> struct pipe_screen;
> enum pipe_cap;
>+enum pipe_format;
>
> #ifdef __cplusplus
> extern "C" {
>@@ -32,6 +33,12 @@ int
> u_pipe_screen_get_param_defaults(struct pipe_screen *pscreen,
> enum pipe_cap param);
>
>+bool
>+u_pipe_screen_get_modifier_aux_planes(struct pipe_screen *pscreen,
>+ uint64_t modifier,
>+ enum pipe_format format,
>+ unsigned *num_aux_planes);
>+
> #ifdef __cplusplus
> };
> #endif
>diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c
>b/src/gallium/drivers/etnaviv/etnaviv_screen.c
>index dcceddc4729..32909a4e5ea 100644
>--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
>+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
>@@ -1019,6 +1019,7 @@ etna_screen_create(struct etna_device *dev,
>struct etna_gpu *gpu,
>pscreen->context_create = etna_context_create;
>pscreen->is_format_supported = etna_screen_is_format_supported;
> pscreen->query_dmabuf_modifiers = etna_screen_query_dmabuf_modifiers;
>+ pscreen->get_modifier_aux_planes =
>u_pipe_screen_get_modifier_aux_planes;
>
>etna_fence_screen_init(pscreen);
>etna_query_screen_init(pscreen);
>diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
>b/src/gallium/drivers/freedreno/freedreno_screen.c
>index 3c0ed69a9cb..5d25df02ebf 100644
>--- a/src/gallium/drivers/freedreno/freedreno_screen.c
>+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
>@@ -984,6 +984,7 @@ fd_screen_create(struct fd_device *dev, struct
>renderonly *ro)
> pscreen->fence_get_fd = fd_fence_get_fd;
>
> pscreen->query_dmabuf_modifiers = fd_screen_query_dmabuf_modifiers;
>+ pscreen->get_modifier_aux_planes =
>u_pipe_screen_get_modifier_aux_planes;
>
> if (!screen->supported_modifiers) {
> static const uint64_t supported_modifiers[] = {
>diff --git a/src/gallium/drivers/iris/iris_resource.c
Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
On Wed, 2019-12-04 at 01:48 -0500, Marek Olšák wrote: > On Wed., Dec. 4, 2019, 01:20 Tapani Pälli, > wrote: > > Hi; > > > > On 12/4/19 2:39 AM, Marek Olšák wrote: > > > Hi, > > > > > > Here are 2 proposals to simplify and better optimize the GL- > > >Gallium > > > translation. > > > > > > 1) Move classic drivers to a fork of Mesa, and remove them from > > master. > > > Classic drivers won't share any code with master. glvnd will load > > them, > > > but glvnd is not ready for this yet. > > > > > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only > > > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to > > be > > > forked and mesa/state_tracker moved. src/gallium/state- > > trackers/gl/ can > > > be the target location. > > > > > > Option 2 is more acceptable to people who want to keep classic > > drivers > > > in the tree and it can be done right now. > > > > > > Opinions? > > > > > > > I'm still quite newbie with gallium side of things and I'd like to > > know > > more about the possible simplifications and optimizations that > > could be > > done if this happened. Is this more about 'cleaning up the tree' or > > are > > there also some performance opportunities we are missing right now > > with > > current state? > > It's possible to reduce CPU overhead even more by moving state > translation from st_validate_state to GL functions. This is possible > already, but at the cost of effectively adding dead code to classic > drivers. In theory we could do slightly better without classic > drivers, but we don't know for sure. > > If we had nir_to_tgsi, we could remove TGSI support from st/mesa. > Option 1 would leave st/mesa as the only consumer of Mesa IR and GLSL > IR, so both IRs could be eliminated in favor of NIR more easily. Implementing nir_to_tgsi is something I've considered several times while working on VirGL; there's a lot of useful lowering-code in NIR that sometimes has to be re-implemented in TGSI, and writing new lowering code targetting NIR is just so much nicer than when targetting TGSI. For both SVGA and VirGL, TGSI can't be completely eliminated without breaking compatibility, because TGSI is part of their protocols. And I believe in both cases, it's a slightly divergent variation of TGSI. So yeah, just wanted to say: +1 on this part :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] spirv: s/{}/{0}/ initializer to fix MSVC build
There's already this one:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2695
On Mon, 2019-11-11 at 16:46 -0700, Brian Paul wrote:
> Trivial.
> ---
> src/compiler/spirv/vtn_variables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/spirv/vtn_variables.c
> b/src/compiler/spirv/vtn_variables.c
> index 944d1f0..37ad4f2 100644
> --- a/src/compiler/spirv/vtn_variables.c
> +++ b/src/compiler/spirv/vtn_variables.c
> @@ -50,7 +50,7 @@ static struct vtn_pointer*
> vtn_decorate_pointer(struct vtn_builder *b, struct vtn_value *val,
> struct vtn_pointer *ptr)
> {
> - struct vtn_pointer dummy = { };
> + struct vtn_pointer dummy = {0};
> vtn_foreach_decoration(b, val, ptr_decoration_cb, );
>
> /* If we're adding access flags, make a copy of the pointer. We
> could
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl: Mention if swrast is being forced
On Mon, 2019-11-11 at 10:44 +0200, Martin Peres wrote:
> On 31/10/2019 09:35, Chris Wilson wrote:
> > The system can be disabling HW acceleration unbeknowst to the user,
> > leading to a long debug session trying to work out which component
> > is
> > failing. A quick mention that it is the environment override would
> > be
> > very useful.
> > ---
> > src/egl/main/egldriver.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/src/egl/main/egldriver.c b/src/egl/main/egldriver.c
> > index 0d8919aa0e1..132b12ab4cb 100644
> > --- a/src/egl/main/egldriver.c
> > +++ b/src/egl/main/egldriver.c
> > @@ -92,6 +92,8 @@ _eglMatchDriver(_EGLDisplay *disp)
> > /* set options */
> > disp->Options.ForceSoftware =
> >env_var_as_boolean("LIBGL_ALWAYS_SOFTWARE", false);
> > + if (disp->Options.ForceSoftware)
> > + _eglLog(_EGL_DEBUG, "Found 'LIBGL_ALWAYS_SOFTWARE' set,
> > forcing swrast");
>
> Maybe we want to remain generic rather than just saying swrast, but
> not
> sure if LIBGL_ALWAYS_SOFTWARE would enable llvmpipe if available
> rather
> than swrast. Maybe we can say "will use a CPU renderer".
>
Yes, it will pick up llvmpipe usually. Or SWR. It can even pick up Zink
exposed as an software-rasterizer, if enabled. But Zink IIRC is the
last resort.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Fri, 2019-10-18 at 18:23 -0400, Marek Olšák wrote: > Oh BTW, drivers that want to implement pipe_screen::finalize_nir to > improve cached shader compilation can't use any of those lowering > passes, because then things blow up. Two questions: 1. What is pipe_screen::finalize_nir? I can't see that in master... Is it something that's currently cooking in a branch / MR? 2. How will these things blow up? > The only _optional_ lowering you can do in st/mesa is clamp_color and > force_persample_in_shader, which covers iris at least (radeonsi > doesn't need any). If you need more, you either need to invest a > significant amount of time to make driver-specific NIR work with the > lowering passes, or give up on good shader cache efficiency. I would love to hear something about why this is the case... > On Fri, Oct 18, 2019 at 4:17 PM Marek Olšák wrote: > > Note that none of the lowering passes work if I enable them on > > radeonsi. So if you think about enabling them for your driver, I > > guess you have some work to do in the driver as well. > > > > On the other hand, having multiple shader variants in st/mesa is a > > performance disadvantage. The lowering should be done at the > > machine-level assembly code, so that you don't have to completely > > recompile from a higher-level IR. > > > > Marek > > > > On Fri, Oct 18, 2019 at 4:08 PM Marek Olšák > > wrote: > > > On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin > > > wrote: > > > > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund > > > > wrote: > > > > > > > > > > On Fri, 2019-10-18 at 08:57 -0400, Ilia Mirkin wrote: > > > > > > On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund > > > > > > wrote: > > > > > > > On Thu, 2019-10-17 at 22:24 -0400, Ilia Mirkin wrote: > > > > > > > > In the meanwhile (unless you plan on taking up Jason's > > > > > > > > suggestion), > > > > > > > > might I recommend some assert's for the unhandled cases > > > > so that > > > > > > > > there > > > > > > > > are no surprises? > > > > > > > > > > > > > > Good idea. I sent a MR for it here: > > > > > > > > > > > > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2380 > > > > > > > > > > > > Not sure that approach works, esp with SSO. > > > > > > > > > > If so, wouldn't that already be a problem with the existing > > > > > lower_depth_clamp-stuff, then? I mean, I just lifted the > > > > logic from > > > > > there... > > > > > > > > Yeah, that looks bogus. I'm moderately sure that checking > > > > "st->vp/gp/tep" at LinkShader time is wrong. Marek can probably > > > > confirm. > > > > > > Don't read any context states at link time. It's wrong. > > > > > > Marek > > ___ > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Fri, 2019-10-18 at 16:17 -0400, Marek Olšák wrote: > Note that none of the lowering passes work if I enable them on > radeonsi. So if you think about enabling them for your driver, I > guess you have some work to do in the driver as well. Hmm, that's not the intention. The idea is that these produce the same code as if you just wrote the relevant glsl-code... Any pointers to what goes wrong would be great if anyone can spot it. > On the other hand, having multiple shader variants in st/mesa is a > performance disadvantage. The lowering should be done at the machine- > level assembly code, so that you don't have to completely recompile > from a higher-level IR. That depends on how often or if at all the variants gets compiled. In fact, we might be able to generate faster shader-code by doing this before optimizing. I guess looking at real-world benchmarks would tell us what the best solution is. ...But for Zink, there isn't really much of an option do this on a low- level; the lowest level we have is SPIR-V, and we're going pretty directly from NIR to SPIR-V; we don't have a low-level IR. We leave that up to the Vulkan driver. > Marek > > On Fri, Oct 18, 2019 at 4:08 PM Marek Olšák wrote: > > On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin > > wrote: > > > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund > > > wrote: > > > > > > > > On Fri, 2019-10-18 at 08:57 -0400, Ilia Mirkin wrote: > > > > > On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund > > > > > wrote: > > > > > > On Thu, 2019-10-17 at 22:24 -0400, Ilia Mirkin wrote: > > > > > > > In the meanwhile (unless you plan on taking up Jason's > > > > > > > suggestion), > > > > > > > might I recommend some assert's for the unhandled cases > > > so that > > > > > > > there > > > > > > > are no surprises? > > > > > > > > > > > > Good idea. I sent a MR for it here: > > > > > > > > > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2380 > > > > > > > > > > Not sure that approach works, esp with SSO. > > > > > > > > If so, wouldn't that already be a problem with the existing > > > > lower_depth_clamp-stuff, then? I mean, I just lifted the logic > > > from > > > > there... > > > > > > Yeah, that looks bogus. I'm moderately sure that checking > > > "st->vp/gp/tep" at LinkShader time is wrong. Marek can probably > > > confirm. > > > > Don't read any context states at link time. It's wrong. > > > > Marek > > ___ > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Fri, 2019-10-18 at 08:57 -0400, Ilia Mirkin wrote: > On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund > wrote: > > On Thu, 2019-10-17 at 22:24 -0400, Ilia Mirkin wrote: > > > In the meanwhile (unless you plan on taking up Jason's > > > suggestion), > > > might I recommend some assert's for the unhandled cases so that > > > there > > > are no surprises? > > > > Good idea. I sent a MR for it here: > > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2380 > > Not sure that approach works, esp with SSO. If so, wouldn't that already be a problem with the existing lower_depth_clamp-stuff, then? I mean, I just lifted the logic from there... > I was thinking just like > somewhere in st_extensions where it's checking these things -- if > GS/tess are supported, make sure caps a/b/c aren't enabled. Right. I guess that could also be done... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Thu, 2019-10-17 at 20:55 -0500, Jason Ekstrand wrote: > On Thu, Oct 17, 2019 at 10:39 AM Erik Faye-Lund < > erik.faye-l...@collabora.com> wrote: > > This is discussed in the merge request thread. Zink currently only > > support vertex and fragment shaders, so it's the only place this > > can occur. If someone wants to enable this for drivers that > > supports geometry or tesselation shaders, they would need to extend > > this code first. Unless I beat them to it, of course. I don't want > > to implement this blindly, which is why I left this out for now. > > > > If you hook the pass up and get it working on iris, you wouldn't be > implementing it blind. :-P > Not the worst idea. I gave it a quick stab, but coulnt't even get the vertex-shader only path working on Iris. I'm probably breaking some expectations in the way the lowering-pass is called or something, but I couldn't figure it out quickly, and kinda lost my motivation. Here's what I did so far: https://gitlab.freedesktop.org/kusma/mesa/tree/iris-ucp-lowering I noticed that if I also call nir_shader_gather_info after the lowering (like the current iris code does), everything seems to get clipped instead... And if I do both nir_lower_global_vars_to_local and nir_lower_vars_to_ssa, I trigger this assert: nir_lower_var_copies.c:89: emit_deref_copy_load_store: Assertion `glsl_type_is_vector_or_scalar(dst_deref->type)' failed. So... I dunno. There's probably something wrong here somewhere ;) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Thu, 2019-10-17 at 22:24 -0400, Ilia Mirkin wrote: > In the meanwhile (unless you plan on taking up Jason's suggestion), > might I recommend some assert's for the unhandled cases so that there > are no surprises? Good idea. I sent a MR for it here: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2380 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
This is discussed in the merge request thread. Zink currently only support vertex and fragment shaders, so it's the only place this can occur. If someone wants to enable this for drivers that supports geometry or tesselation shaders, they would need to extend this code first. Unless I beat them to it, of course. I don't want to implement this blindly, which is why I left this out for now. On October 17, 2019 5:09:36 PM GMT+02:00, Ilia Mirkin wrote: >Hey Erik, > >Just saw your change >https://cgit.freedesktop.org/mesa/mesa/commit/?id=3298aedd6e9f12cefd5aa7414eeebf69ce7538d1 >. It looks like you assume that the UCPs will apply in the vertex >stage, but given that we support GL compat profiles for GL 4.0+ in >st/mesa, the UCPs actually apply to the same stage that clip distances >are processed in -- might be TES or GS, depending on the pipeline. > >Perhaps there's some reason why this works anyways that I'm not >seeing... > >Cheers, > > -ilia -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Set meta data for textures from handle.
On Wed, 2019-07-17 at 10:02 -0700, Lepton Wu wrote:
> The set of meta data was removed by commit 8083464. It broke lots of
> dEQP tests when running with pbuffer surface type.
>
> Fixes: 80834640137 ("virgl: remove dead code")
> Signed-off-by: Lepton Wu
> ---
> src/gallium/drivers/virgl/virgl_resource.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/virgl/virgl_resource.c
> b/src/gallium/drivers/virgl/virgl_resource.c
> index c22a78a4731..909deb774c7 100644
> --- a/src/gallium/drivers/virgl/virgl_resource.c
> +++ b/src/gallium/drivers/virgl/virgl_resource.c
> @@ -515,6 +515,7 @@ static struct pipe_resource
> *virgl_resource_from_handle(struct pipe_screen *scre
> res->u.b = *templ;
> res->u.b.screen = >base;
> pipe_reference_init(>u.b.reference, 1);
> + virgl_resource_layout(>u.b, >metadata);
>
> res->hw_res = vs->vws->resource_create_from_handle(vs->vws,
> whandle);
> if (!res->hw_res) {
Whoops! Good catch, sorry for the mess!
Reviewed-by: Erik Faye-Lund
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/11] panfrost/midgard: Flush undefineds to zero
On Wed, 2019-07-10 at 06:24 -0700, Alyssa Rosenzweig wrote: > Fixes a buggy dEQP test. > Maybe you could share which test this fixes, so someone can fix it? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/11] panfrost/midgard: Flush undefineds to zero
On Wed, 2019-07-10 at 06:24 -0700, Alyssa Rosenzweig wrote:
> Fixes a buggy dEQP test.
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> .../drivers/panfrost/ci/expected-failures.txt | 6 --
> src/gallium/drivers/panfrost/meson.build | 1 +
> .../drivers/panfrost/midgard/compiler.h | 6 ++
> .../panfrost/midgard/midgard_compile.c| 4 +
> .../panfrost/midgard/nir_undef_to_zero.c | 89
> +++
> 5 files changed, 100 insertions(+), 6 deletions(-)
> create mode 100644
> src/gallium/drivers/panfrost/midgard/nir_undef_to_zero.c
>
> diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt
> b/src/gallium/drivers/panfrost/ci/expected-failures.txt
> index 33059118b49..6f52773cc73 100644
> --- a/src/gallium/drivers/panfrost/ci/expected-failures.txt
> +++ b/src/gallium/drivers/panfrost/ci/expected-failures.txt
> @@ -256,12 +256,6 @@ dEQP-
> GLES2.functional.rasterization.limits.points
> dEQP-GLES2.functional.shaders.builtin_variable.fragcoord_w
> dEQP-
> GLES2.functional.shaders.preprocessor.predefined_macros.line_2_fragme
> nt
> dEQP-
> GLES2.functional.shaders.preprocessor.predefined_macros.line_2_vertex
> -dEQP-GLES2.functional.shaders.random.all_features.fragment.0
> -dEQP-GLES2.functional.shaders.random.all_features.fragment.16
> -dEQP-GLES2.functional.shaders.random.all_features.fragment.5
> -dEQP-GLES2.functional.shaders.random.all_features.fragment.6
> -dEQP-GLES2.functional.shaders.random.all_features.vertex.0
> -dEQP-GLES2.functional.shaders.random.all_features.vertex.17
> dEQP-
> GLES2.functional.shaders.scoping.valid.local_variable_hides_function_
> parameter_fragment
> dEQP-
> GLES2.functional.shaders.scoping.valid.local_variable_hides_function_
> parameter_vertex
> dEQP-
> GLES2.functional.shaders.struct.local.dynamic_loop_assignment_fragmen
> t
> diff --git a/src/gallium/drivers/panfrost/meson.build
> b/src/gallium/drivers/panfrost/meson.build
> index 6b907f155ae..e1faa104f6b 100644
> --- a/src/gallium/drivers/panfrost/meson.build
> +++ b/src/gallium/drivers/panfrost/meson.build
> @@ -36,6 +36,7 @@ files_panfrost = files(
>'midgard/midgard_liveness.c',
>'midgard/midgard_ops.c',
>
> + 'midgard/nir_undef_to_zero.c',
>'midgard/nir_lower_blend.c',
>'midgard/nir_lower_framebuffer.c',
>'midgard/cppwrap.cpp',
> diff --git a/src/gallium/drivers/panfrost/midgard/compiler.h
> b/src/gallium/drivers/panfrost/midgard/compiler.h
> index 5fe1d80692c..820831d35dd 100644
> --- a/src/gallium/drivers/panfrost/midgard/compiler.h
> +++ b/src/gallium/drivers/panfrost/midgard/compiler.h
> @@ -444,4 +444,10 @@ void emit_binary_bundle(
> midgard_bundle *bundle,
> struct util_dynarray *emission,
> int next_tag);
> +
> +/* NIR stuff */
> +
> +bool
> +nir_undef_to_zero(nir_shader *shader);
> +
> #endif
> diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
> b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
> index 1e08e349eee..9c86f19fd06 100644
> --- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
> +++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
> @@ -404,6 +404,8 @@ midgard_nir_lower_fdot2(nir_shader *shader)
> return progress;
> }
>
> +/* Flushes undefined values to zero */
> +
> static void
> optimise_nir(nir_shader *nir)
> {
> @@ -464,6 +466,8 @@ optimise_nir(nir_shader *nir)
> }
>
> NIR_PASS(progress, nir, nir_opt_undef);
> +NIR_PASS(progress, nir, nir_undef_to_zero);
> +
> NIR_PASS(progress, nir, nir_opt_loop_unroll,
> nir_var_shader_in |
> nir_var_shader_out |
> diff --git a/src/gallium/drivers/panfrost/midgard/nir_undef_to_zero.c
> b/src/gallium/drivers/panfrost/midgard/nir_undef_to_zero.c
> new file mode 100644
> index 000..aacecc17e9d
> --- /dev/null
> +++ b/src/gallium/drivers/panfrost/midgard/nir_undef_to_zero.c
> @@ -0,0 +1,89 @@
> +/*
> + * Copyright (C) 2019 Collabora, Ltd.
> + *
> + * Permission is hereby granted, free of charge, to any person
> obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> the
> + * Software is furnished to do so, subject to the following
> conditions:
> + *
> + * The above copyright notice and this permission notice (including
> the next
> + * paragraph) shall be included in all copies or substantial
> portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT SHALL
> + * THE
[Mesa-dev] [PATCH 0/5] gallium: kill PIPE_CAP_SM3
Every time I stumble over PIPE_CAP_SM3, I get a bit depressed. This cap is different than most caps in Gallium, as it's much broader, and I need to read up a lot to try to figure out anything specific about what it does. Shader Model 3.0 is a *big* feature-set. It seems I'm not the only one who feels this way, because of the comment in screen.rst, saying "XXX oh god this is horrible". But there's some more direct issues lurking as well: Some mobile GPUs can support some, but not all of the SM3 features. For instance, Mali- 400 supports OES_standard_derivatives but not FP32 precision (which is a SM3 requirement). So when it's time for the Lima driver to implement OES_standard_derivatives, something needs to be done anyway. So, here's patches that turns PIPE_CAP_SM3 into PIPE_CAP_FRAGMENT_SHADER_TEXTURE_LOD, PIPE_CAP_FRAGMENT_SHADER_DERIVATIVES and PIPE_CAP_VERTEX_SHADER_SATURATE, which is what we care about anyway. As I don't know much about the hardware capabilities of the various drivers, I've just kept functionality as it is for now. I can imagine some drivers might want to benefit from this already. For instance, some drivers might be able to enable PIPE_CAP_VERTEX_SHADER_SATURATE without enabling the rest. But for now, I leave that up to follow-up patches. I'm intentionally sending just the cover-letter here. You can see the merge request on gitlab here: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1266 Erik Faye-Lund (5): mesa/st: drop needless has_shader_model3 boolean gallium: give fragment-shader texture-lod its own cap gallium: give fragment-shader derivatives its own cap gallium: give vertex-shader saturate its own cap gallium: get rid of PIPE_CAP_SM3 src/gallium/auxiliary/util/u_screen.c| 4 +++- src/gallium/docs/source/screen.rst | 8 ++-- src/gallium/drivers/etnaviv/etnaviv_screen.c | 4 +++- src/gallium/drivers/freedreno/freedreno_screen.c | 4 +++- src/gallium/drivers/i915/i915_screen.c | 4 +++- src/gallium/drivers/iris/iris_screen.c | 4 +++- src/gallium/drivers/llvmpipe/lp_screen.c | 4 +++- src/gallium/drivers/nouveau/nv30/nv30_screen.c | 4 +++- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 4 +++- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 4 +++- src/gallium/drivers/panfrost/pan_screen.c| 4 +++- src/gallium/drivers/r300/r300_screen.c | 4 +++- src/gallium/drivers/r600/r600_pipe.c | 4 +++- src/gallium/drivers/radeonsi/si_get.c| 4 +++- src/gallium/drivers/softpipe/sp_screen.c | 4 +++- src/gallium/drivers/svga/svga_screen.c | 4 +++- src/gallium/drivers/swr/swr_screen.cpp | 5 +++-- src/gallium/drivers/v3d/v3d_screen.c | 4 +++- src/gallium/drivers/virgl/virgl_screen.c | 4 +++- src/gallium/include/pipe/p_defines.h | 4 +++- src/gallium/state_trackers/nine/adapter9.c | 10 +- src/mesa/state_tracker/st_context.c | 3 +-- src/mesa/state_tracker/st_context.h | 1 - src/mesa/state_tracker/st_extensions.c | 4 ++-- 24 files changed, 75 insertions(+), 28 deletions(-) -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Take into account off-screen FBOs
On Thu, 2019-07-04 at 10:02 +0200, Tomeu Vizoso wrote:
> In that case, ctx->pipe_framebuffer.cbufs[0] can be NULL.
>
> Signed-off-by: Tomeu Vizoso
> Cc: Boris Brezillon
> Fixes: 5375d009be18 ("panfrost: Pass referenced BOs to the SUBMIT
> ioctls")
Nit: this isn't really about off-screen vs on-screen, but rendering
with vs without a color-buffer. Sure, non-color buffers can't be on-
screen, but you can have off-screen color-buffers as well.
I know this patch already landed, but if you keep this in mind for the
future, perhaps we can avoid confusing commit messages.
> ---
> src/gallium/drivers/panfrost/pan_drm.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_drm.c
> b/src/gallium/drivers/panfrost/pan_drm.c
> index 8de4f483435c..b89f8e66a877 100644
> --- a/src/gallium/drivers/panfrost/pan_drm.c
> +++ b/src/gallium/drivers/panfrost/pan_drm.c
> @@ -238,7 +238,6 @@ panfrost_drm_submit_job(struct panfrost_context
> *ctx, u64 job_desc, int reqs)
> int
> panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool
> has_draws, bool is_scanout)
> {
> -struct pipe_surface *surf = ctx->pipe_framebuffer.cbufs[0];
> int ret;
>
> struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
> @@ -256,9 +255,12 @@ panfrost_drm_submit_vs_fs_job(struct
> panfrost_context *ctx, bool has_draws, bool
> }
>
> if (job->first_tiler.gpu || job->clear) {
> -struct panfrost_resource *res = pan_resource(surf-
> >texture);
> -assert(res->bo);
> -panfrost_job_add_bo(job, res->bo);
> +struct pipe_surface *surf = ctx-
> >pipe_framebuffer.cbufs[0];
> +if (surf) {
> +struct panfrost_resource *res =
> pan_resource(surf->texture);
> +assert(res->bo);
> +panfrost_job_add_bo(job, res->bo);
> +}
> ret = panfrost_drm_submit_job(ctx,
> panfrost_fragment_job(ctx, has_draws), PANFROST_JD_REQ_FS);
> assert(!ret);
> }
I'm not sure this is actually correct either. I don't think there's any
guarantee that the currently bound framebuffer is what was actually
last rendered to. For instance if an application renders to the
backbuffer, switches to some FBO, does some rendering, switches back
and swaps buffers right away. I believe the currently bound framebuffer
will be the FBO at this point, because framebuffer-state is bound
lazily.
I think instead you'd want to add a reference in
panfrost_set_framebuffer_state(), right before you start rendering to
it... And at this point, you shouldn't need to special-case cbuf 0, you
should just add a reference to all cbufs as well as the zsbuf.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 4/5] st/dri2: Implement DRI2bufferDamageExtension
On Wed, 2019-07-03 at 12:33 +0200, Boris Brezillon wrote:
> On Wed, 03 Jul 2019 11:54:29 +0200
> Erik Faye-Lund wrote:
>
> > On Wed, 2019-06-26 at 10:34 -0700, Alyssa Rosenzweig wrote:
> > > Ah-ha, now we're into parts of the stack I can claim to
> > > understand!
> > > > :)
> > >
> > > Reviewed-by: Alyssa Rosenzweig
> > >
> > > On Tue, Jun 25, 2019 at 06:37:48PM +0200, Boris Brezillon
> > > wrote:
> > > > From: Daniel Stone
> > > >
> > > > Add a pipe_screen->set_damage_region() hook to propagate
> > > > set-damage-region requests to the driver, it's then up to the
> > > > driver to
> > > > decide what to do with this piece of information.
> > > >
> > > > If the hook is left unassigned, the buffer-damage extension is
> > > > considered unsupported.
> > > >
> > > > Signed-off-by: Daniel Stone
> > > > Signed-off-by: Boris Brezillon
> > > > ---
> > > > src/gallium/include/pipe/p_screen.h | 7 +++
> > > > src/gallium/state_trackers/dri/dri2.c | 22
> > > > ++
> > > > 2 files changed, 29 insertions(+)
> > > >
> > > > diff --git a/src/gallium/include/pipe/p_screen.h
> > > > b/src/gallium/include/pipe/p_screen.h
> > > > index 3f9bad470950..8df12ee4f865 100644
> > > > --- a/src/gallium/include/pipe/p_screen.h
> > > > +++ b/src/gallium/include/pipe/p_screen.h
> > > > @@ -464,6 +464,13 @@ struct pipe_screen {
> > > > bool (*is_parallel_shader_compilation_finished)(struct
> > > > pipe_screen *screen,
> > > > void
> > > > *shader,
> > > > unsigned
> > > > shader_type);
> > > > +
> > > > + /**
> > > > +* Set damage region.
> > > > +*/
> > > > + void (*set_damage_region)(struct pipe_screen *screen,
> > > > + struct pipe_resource *resource,
> > > > + unsigned int nrects, int
> > > > *rects);
> >
> > I would kinda have expected rects to be an array of pipe_box
> > instead of
> > just an array of integers, as that'd be a bit easier to know the
> > semantics of...
>
> Sure, I can do that. Should I do the Y-flip as part of the ints ->
> box
> conversion or should I keep the "origin is bottom-left" semantic?
Good question? :)
My instinct would be to have the regions in "memory layout order"
rather than "window sytem presentation order", which I guess would be
without any sort of y-flipping or rotation applied. I guess that would
make the answer "no"? But I'm not sure, I haven't read up on the spec
here.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] boolean usage in gallium
On Sat, 2019-06-29 at 00:08 -0400, Ilia Mirkin wrote: > Ken pointed out on IRC today that there was still a lot of "boolean" > (vs bool/_Bool) usage in gallium. In fact, many interfaces are > specified with boolean. > > I had it in my mind that I had at some point removed most boolean > usage, but that is just not the case - first of all, the interfaces > remain with it, and I could find no evidence of such a commit. I must > have imagined it. > > Is there any reason to keep boolean around? I know conversions must > be > done carefully (since incorrect-but-working usage would not currently > be caught by the compiler), but are there any practical reasons to > avoid C99 _Bool in gallium code? > > If not, I may begin converting things over. > I would love to see patches for this! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 4/5] st/dri2: Implement DRI2bufferDamageExtension
On Wed, 2019-06-26 at 10:34 -0700, Alyssa Rosenzweig wrote:
> Ah-ha, now we're into parts of the stack I can claim to understand!
> >:)
>
> Reviewed-by: Alyssa Rosenzweig
>
> On Tue, Jun 25, 2019 at 06:37:48PM +0200, Boris Brezillon wrote:
> > From: Daniel Stone
> >
> > Add a pipe_screen->set_damage_region() hook to propagate
> > set-damage-region requests to the driver, it's then up to the
> > driver to
> > decide what to do with this piece of information.
> >
> > If the hook is left unassigned, the buffer-damage extension is
> > considered unsupported.
> >
> > Signed-off-by: Daniel Stone
> > Signed-off-by: Boris Brezillon
> > ---
> > src/gallium/include/pipe/p_screen.h | 7 +++
> > src/gallium/state_trackers/dri/dri2.c | 22 ++
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/src/gallium/include/pipe/p_screen.h
> > b/src/gallium/include/pipe/p_screen.h
> > index 3f9bad470950..8df12ee4f865 100644
> > --- a/src/gallium/include/pipe/p_screen.h
> > +++ b/src/gallium/include/pipe/p_screen.h
> > @@ -464,6 +464,13 @@ struct pipe_screen {
> > bool (*is_parallel_shader_compilation_finished)(struct
> > pipe_screen *screen,
> > void *shader,
> > unsigned
> > shader_type);
> > +
> > + /**
> > +* Set damage region.
> > +*/
> > + void (*set_damage_region)(struct pipe_screen *screen,
> > + struct pipe_resource *resource,
> > + unsigned int nrects, int *rects);
I would kinda have expected rects to be an array of pipe_box instead of
just an array of integers, as that'd be a bit easier to know the
semantics of...
> > };
> >
> >
> > diff --git a/src/gallium/state_trackers/dri/dri2.c
> > b/src/gallium/state_trackers/dri/dri2.c
> > index 5caaa9deac41..df22e7c41642 100644
> > --- a/src/gallium/state_trackers/dri/dri2.c
> > +++ b/src/gallium/state_trackers/dri/dri2.c
> > @@ -1806,6 +1806,23 @@ static const __DRI2interopExtension
> > dri2InteropExtension = {
> > .export_object = dri2_interop_export_object
> > };
> >
> > +/**
> > + * \brief the DRI2bufferDamageExtension set_damage_region method
> > + */
> > +static void
> > +dri2_set_damage_region(__DRIdrawable *dPriv, unsigned int nrects,
> > int *rects)
> > +{
> > + struct dri_drawable *drawable = dri_drawable(dPriv);
> > + struct pipe_resource *resource = drawable-
> > >textures[ST_ATTACHMENT_BACK_LEFT];
> > + struct pipe_screen *screen = resource->screen;
> > +
> > + screen->set_damage_region(screen, resource, nrects, rects);
> > +}
> > +
> > +static __DRI2bufferDamageExtension dri2BufferDamageExtension = {
> > + .base = { __DRI2_BUFFER_DAMAGE, 1 },
> > +};
> > +
> > /**
> > * \brief the DRI2ConfigQueryExtension configQueryb method
> > */
> > @@ -1907,6 +1924,7 @@ static const __DRIextension
> > *dri_screen_extensions[] = {
> > ,
> > ,
> > ,
> > + ,
> > ,
> > ,
> > ,
> > @@ -1922,6 +1940,7 @@ static const __DRIextension
> > *dri_robust_screen_extensions[] = {
> > ,
> > ,
> > ,
> > + ,
> > ,
> > ,
> > ,
> > @@ -1982,6 +2001,9 @@ dri2_init_screen(__DRIscreen * sPriv)
> >}
> > }
> >
> > + if (pscreen->set_damage_region)
> > + dri2BufferDamageExtension.set_damage_region =
> > dri2_set_damage_region;
> > +
> > if (pscreen->get_param(pscreen,
> > PIPE_CAP_DEVICE_RESET_STATUS_QUERY)) {
> >sPriv->extensions = dri_robust_screen_extensions;
> >screen->has_reset_status_query = true;
> > --
> > 2.20.1
> >
>
> ___
> 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
Re: [Mesa-dev] [PATCH v4 0/5] EGL_KHR_partial_update support
On Tue, 2019-06-25 at 18:37 +0200, Boris Brezillon wrote: > This is an attempt at resurrecting Daniel's MR [1] which was already > resurrecting Harish's EGL_KHR_partial_update series [2]. This version > implements Marek's suggestion to pass the set_damage_region() > directly > to the gallium driver and let it decide how to handle the request. > Some > drivers might just calculate the damage extent (as done in Daniel's > initial proposal and in the panfrost implementation), others might do > extra optimizations like trying to reduce the area we're supposed to > reload (only valid for tile-based rendering) even further. > > This patch series has been tested with weston (see Daniel's MR[3]) on > panfrost. Note that the panfrost implementation is rather simple > (just > limits the rendering area to the damage extent and picks the biggest > damage rect as the only damage region) but we can improve it if we > feel > the need. > > Any feedback and suggestions on how to do it better are welcome. > I haven't looked at the panfrost end of it, but the overall approach seems solid to me, and it solves the issue I had with the initial approach. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Rewrite u-interleaving code
On Tue, 2019-06-25 at 12:36 -0700, Vasily Khoruzhick wrote:
> On Tue, Jun 25, 2019 at 11:54 AM Alyssa Rosenzweig
> wrote:
>
> Hi Alyssa,
>
> > Rather than using a magic lookup table with no explanations, let's
> > add
> > liberal comments to the code to explain what this tiling scheme is
> > and
> > how to encode/decode it efficiently.
> >
> > It's not so mysterious after all -- just reordering bits with some
> > XORs
> > thrown in.
> >
> > Signed-off-by: Alyssa Rosenzweig
> > Cc: Vasily Khoruzhick
> > ---
> > src/panfrost/shared/pan_tiling.c | 330 +
> > --
> > 1 file changed, 229 insertions(+), 101 deletions(-)
> >
> > diff --git a/src/panfrost/shared/pan_tiling.c
> > b/src/panfrost/shared/pan_tiling.c
> > index 413cd89420b..de0d6812831 100644
> > --- a/src/panfrost/shared/pan_tiling.c
> > +++ b/src/panfrost/shared/pan_tiling.c
> > @@ -2,6 +2,7 @@
> > * Copyright (c) 2011-2013 Luc Verhaegen
> > * Copyright (c) 2018 Alyssa Rosenzweig
> > * Copyright (c) 2018 Vasily Khoruzhick
> > + * Copyright (c) 2019 Collabora
> > *
> > * Permission is hereby granted, free of charge, to any person
> > obtaining a
> > * copy of this software and associated documentation files (the
> > "Software"),
> > @@ -26,127 +27,230 @@
> >
> > #include "pan_tiling.h"
> >
> > -uint32_t space_filler[16][16] = {
> > - {
> > 0, 1, 4, 5, 16, 17, 20, 21, 64, 65, 68, 69, 80, 81
> > , 84, 85, },
> > - {
> > 3, 2, 7, 6, 19, 18, 23, 22, 67, 66, 71, 70, 83, 82
> > , 87, 86, },
> > - {
> > 12, 13, 8, 9, 28, 29, 24, 25, 76, 77, 72, 73, 92, 93
> > , 88, 89, },
> > - {
> > 15, 14, 11, 10, 31, 30, 27, 26, 79, 78, 75, 74, 95, 94
> > , 91, 90, },
> > - { 48, 49, 52, 53, 32, 33, 36, 37, 112, 113, 116, 117,
> > 96, 97, 100, 101, },
> > - { 51, 50, 55, 54, 35, 34, 39, 38, 115, 114, 119, 118,
> > 99, 98, 103, 102, },
> > - { 60, 61, 56, 57, 44, 45, 40, 41, 124, 125, 120, 121,
> > 108, 109, 104, 105, },
> > - { 63, 62, 59, 58, 47, 46, 43, 42, 127, 126, 123, 122,
> > 111, 110, 107, 106, },
> > - { 192, 193, 196, 197, 208, 209, 212, 213, 128, 129, 132, 133,
> > 144, 145, 148, 149, },
> > - { 195, 194, 199, 198, 211, 210, 215, 214, 131, 130, 135, 134,
> > 147, 146, 151, 150, },
> > - { 204, 205, 200, 201, 220, 221, 216, 217, 140, 141, 136, 137,
> > 156, 157, 152, 153, },
> > - { 207, 206, 203, 202, 223, 222, 219, 218, 143, 142, 139, 138,
> > 159, 158, 155, 154, },
> > - { 240, 241, 244, 245, 224, 225, 228, 229, 176, 177, 180, 181,
> > 160, 161, 164, 165, },
> > - { 243, 242, 247, 246, 227, 226, 231, 230, 179, 178, 183, 182,
> > 163, 162, 167, 166, },
> > - { 252, 253, 248, 249, 236, 237, 232, 233, 188, 189, 184, 185,
> > 172, 173, 168, 169, },
> > - { 255, 254, 251, 250, 239, 238, 235, 234, 191, 190, 187, 186,
> > 175, 174, 171, 170, },
> > +/* This file implements software encode/decode of the tiling
> > format used for
> > + * textures and framebuffers primarily on Utgard GPUs. Names for
> > this format
> > + * include "Utgard-style tiling", "(Mali) swizzled textures", and
> > + * "U-interleaved" (the former two names being used in the
> > community
> > + * Lima/Panfrost drivers; the latter name used internally at Arm).
> > + * Conceptually, like any tiling scheme, the pixel reordering
> > attempts to 2D
> > + * spatial locality, to improve cache locality in both horizontal
> > and vertical
> > + * directions.
> > + *
> > + * This format is tiled: first, the image dimensions must be
> > aligned to 16
> > + * pixels in each axis. Once aligned, the image is divided into
> > 16x16 tiles.
> > + * This size harmonizes with other properties of the GPU; on
> > Midgard,
> > + * framebuffer tiles are logically 16x16 (this is the tile size
> > used in
> > + * Transaction Elimination and the minimum tile size used in
> > Hierarchical
> > + * Tiling). Conversely, for a standard 4 bytes-per-pixel format
> > (like
> > + * RGBA), 16 pixels * 4 bytes/pixel = 64 bytes, equal to the
> > cache line
> > + * size.
> > + *
> > + * Within each 16x16 block, the bits are reordered according to
> > this pattern:
> > + *
> > + * | y3 | (x3 ^ y3) | y2 | (y2 ^ x2) | y1 | (y1 ^ x1) | y0 | (y0 ^
> > x0) |
> > + *
> > + * Basically, interleaving the X and Y bits, with XORs thrown in
> > for every
> > + * adjacent bit pair.
> > + *
> > + * This is cheap to implement both encode/decode in both hardware
> > and software.
> > + * In hardware, lines are simply rerouted to reorder and some XOR
> > gates are
> > + * thrown in. Software has to be a bit more clever.
> > + *
> > + * In software, the trick is to divide the pattern into two lines:
> > + *
> > + *| y3 | y3 | y2 | y2 | y1 | y1 | y0 | y0 |
> > + * ^ | 0 | x3 | 0 | x2 | 0 | x1 | 0 | x0 |
> > + *
> > + * That is, duplicate the bits of the Y and space out the bits of
> > the X. The
> > + * top line is a function only of Y, so it can be
[Mesa-dev] Proposal for the future of www.mesa3d.org
A while back, Laura and Jean was working on a Sphinx-conversion of the mesa-documentation. Sadly this work stranded due to it also trying to move to using GitLab Pages for hosting www.mesa3d.org, and because the documentation and the websit eis the same thing, this lead to problems with hosting the release-archive (www.mesa3d.org/archive/). Since then, I've taken a look at trying to revive this work. So far, I've taken most of the changed Laura did to the website post-RST conversion, and performed them before instead. I've also automated more of the conversion process, so we can easier get an up-to-date conversion. The result can be viewed here: https://kusma.pages.freedesktop.org/mesa/ https://gitlab.freedesktop.org/kusma/mesa/tree/docs-sphinx-v2 Please note that there's some differences: - I don't do any "mesa-specific styling". This can be done on top if needed, simply by cherry-picking Laura's commits for this. But I'm not sure we need it, more about this further down. - Some of the commit history might be incorrectly attributed to me instead of Laura. I intend to fix this up before upstreaming anything here. - The conversion isn't entirely up-to-date, but it's *fairly* recent. So yeah, the big elephant in the room is what to do with www.mesa3d.org/archive. This is where I have an alternative suggestion: How about we split the documentation and the website into two sites, www.mesa3d.org and docs.mesa3d.org, and maintain the website in a separate repository? We would of course have to set up some redirects to make old URLs point to the latest version (at least for a transition period). This has some additional benefits: - We don't need to push things to master to update things like news, that aren't really related to the code. - We can separate information that is technical documentation from information that are is "project marketing". - ...And because we don't need for the docs to appeal as "project marketing", we can keep the neutral readthedocs theme as-is, as it's a bit more easy on the eye IMO. - It makes the article index a bit more logical, as there's a few articles that doesn't really make sense to read after you already have the source tree. Why would you wonder who the webmaster is (docs/webmaster.html) or where to download mesa (docs/download.html) when reading the source? - We can host docs.mesa3d.org using GitLab pages (or point it to something like readthedocs.org) without having to change the hosting for www.mesa3d.org. In addition to this, I've also had a look at modernizing www.mesa.org as well, and I've made a proposal for a new, responisive website: https://kusma.pages.freedesktop.org/ https://gitlab.freedesktop.org/kusma/kusma.pages.freedesktop.org/ Quite a few things to notice: - Many links here forward to docs.mesa3d.org, which doesn't exist yet. - The redirects are done using meta-refresh tags instead of HTTP redirects, so they will only be redirected by an actual user-agent, not by curl or wget. - The site is using logos of Khronos APIs which might not be OK without approval. The legality of this needs to be researched. - Most of the content here is "usable placeholder" text, but by no means final. For instance, the descriptions of the APIs and drivers probably needs work. Especially the driver-decription should probably be written by the driver-teams rather than me. - Some drivers are missing. I just didn't bother writing more placeholder. - What content goes in which site is by no means decided on. - Some content isn't yet in either site; in particular, non-html files, like for instance the contents of www.mesa3d.org/specs. And since GitLab pages doesn't do directory listings, that folder (regardless of where it'd be reciding) would need an index added. - The site is made using Jekyll, but any static-site generator would do, really. The redirect-issue is due to the prototype currently being hosted in GitLab pages, and is a GitLab pages limitation. See https://gitlab.com/gitlab-org/gitlab-pages/issues/24 for more details. I doubt this would be a problem for documentation, but the same approach won't work for www.mesa3d.org/archive. Without solving that problem, we can't really go live with this while hosting it on GitLab pages. But we could go forward *without* hosting www.mesa3d.org in GitLab pages in the short term. I don't know how we currently deploy the website, I guess that's done manually by someone at some points? If so, we'd just update the manual recipie, I guess. I think the long-term goal should be to also move www.mesa3d.org to GitLab pages as well, and I have some ideas for how to deal with the www.mesa3d.org/archive-problem, but this is a much longer discussion, and this email is already too long. So if someone wants to discuss that, feel free to reply, and I'll happily tell you about it! Anyway, thoughts? Objections? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] mirroring ogl-sample source code in gitlab?
On Wed, 2019-06-12 at 14:03 -0400, Adam Jackson wrote: > 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! > Thanks, I can see it now :) > > > > 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. > Yeah, fair enough. I don't really feel the need to decide on this right now. I want to add a link to the ogl-sample code in our FAQ, so that's the only repo I have a motivation to do something with right now. I would say we move both the ogl-sample repo and the glx repo to the mesa organization, and mark them as read-only as we reasonably can. I'm pretty much indifferent to archiving vs permissions-tweaks, but I do very slightly lean towards archiving (AFAIK, owners can always push regardless of premissins-tweaks, so there's a *very* theoretical chance of something going wrong then). The glx-repo can wait until there's a motivation, I think. ___ 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?
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. > > > 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... ___ 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?
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. > 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. > > 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. > Yeah, I was kinda left a bit disappointed when I read that archived projects don't show up in searches as well. But I guess it makes sense for most uses of archived projects. It would be nice if there was a separate switch for searchability, just so code-historians can find things like this easily ;) And just to be clear, they would show up here, together with other no- longer-in-use projects: https://gitlab.freedesktop.org/groups/mesa/-/archived I don't really feel strongly about archived or not. We should make sure nobody thinks this is somewhere they can contribute fixes. Perhaps it's enough to just state this in the project description, disable merge- requests, and protect all branches. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] mirroring ogl-sample source code in gitlab?
While looking into dead-links on our website, I noticed that the OpenGL Sample Implementation that SGI open sourced lacks a proper public mirror. So I'm looking to fix this. The tarballs are currently available from here: http://www.servu.org/mirror/old/mirrors.bufferoverflow.xyz/oss.sgi.com/projects/ogl-sample/download/ Additionally, Jeff Muizelaar of Mozilla provides a github-mirror here: https://github.com/jrmuizel/ogl-sample I downloaded the tarballs from servu.org, and imported them to a git- repo here: https://gitlab.freedesktop.org/kusma/ogl-sample I've verified that the trees are identical to those of Jeff Muizelaar. But unlike his mirror, I've made sure the commits have time-stamps that match the time-stamp of the arcives, as well as attributing the authorship to SGI (using "Silicon Graphics International Corp < ogl-sam...@oss.sgi.com>" as the git author). The code is all licensed under SGI's FreeB license, which is the same license as is used for the GLX code we have in Mesa. It should be fine to redistribute like this as far as I can tell. Now, I would prefer not to host this under my own user, as this isn't really related to me other than me doing the actual archive. 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. 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] list: add some iterator debug
On Mon, 2019-05-27 at 13:37 +0200, Erik Faye-Lund wrote: > On Mon, 2019-05-27 at 04:23 -0700, Rob Clark wrote: > > On Mon, May 27, 2019 at 2:50 AM Erik Faye-Lund > > wrote: > > > On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote: > > > > This ends up embedded in a for loop expression, ie. the C part > > > > in > > > > an > > > > for (A;B;C) > > > > > > > > iirc, that means it needs to be a C expr rather than > > > > statement.. > > > > or > > > > something roughly like that, I'm too lazy to dig out my C > > > > grammar > > > > > > > > > > Can't you just call a static helper function to do the > > > validation? > > > Function calls are valid expressions... > > > > I do like the fact that with the current patch I get the correct > > line > > # in the assert msg.. but perhaps #ifdef MSVC we can make it a > > static > > inline instead? I'm not sure how many people do active feature dev > > of > > mesa on windows (as opposed to doing dev on linux and then > > compiling/shipping non-debug builds on windows), so maybe just > > disabling the list debug on MSVC is fine. > > > > BR, > > -R I guess I should also have mentioned that I *do* sometimes do feature development for Mesa on Windows, so I'd really like to get to benefit from debug-helpers. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] list: add some iterator debug
On Mon, 2019-05-27 at 04:23 -0700, Rob Clark wrote:
> On Mon, May 27, 2019 at 2:50 AM Erik Faye-Lund
> wrote:
> > On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote:
> > > This ends up embedded in a for loop expression, ie. the C part in
> > > an
> > > for (A;B;C)
> > >
> > > iirc, that means it needs to be a C expr rather than statement..
> > > or
> > > something roughly like that, I'm too lazy to dig out my C grammar
> > >
> >
> > Can't you just call a static helper function to do the validation?
> > Function calls are valid expressions...
>
> I do like the fact that with the current patch I get the correct line
> # in the assert msg.. but perhaps #ifdef MSVC we can make it a static
> inline instead? I'm not sure how many people do active feature dev
> of
> mesa on windows (as opposed to doing dev on linux and then
> compiling/shipping non-debug builds on windows), so maybe just
> disabling the list debug on MSVC is fine.
>
> BR,
> -R
You can just pass __FILE__ and __LINE__ as arguments to the helper, and
not use assert directy but rather fprintf(stderr, ...) and abort. This
is in fact how most custom assert-macros are implemented.
Something like this:
static void
list_assert_helper(bool cond, const char *expr, const char *msg,
const char *file, int line)
{
if (cond) {
fprintf(stderr, "list_assert failed: %s:%d: %s",
file, line, expr);
abort();
}
}
#define list_assert(cond, msg) \
list_assert_helper(LIST_DEBUG && cond, #cond, msg, \
__FILE__, __LINE__)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] list: add some iterator debug
On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote:
> This ends up embedded in a for loop expression, ie. the C part in an
> for (A;B;C)
>
> iirc, that means it needs to be a C expr rather than statement.. or
> something roughly like that, I'm too lazy to dig out my C grammar
>
Can't you just call a static helper function to do the validation?
Function calls are valid expressions...
> BR,
> -R
>
>
> On Sat, May 25, 2019 at 3:39 PM Ilia Mirkin
> wrote:
> > Why not just do it in a way that works for everyone? Both the
> > do/while
> > method and the ifdef-based method that I suggested work everywhere.
> > Or
> > is there another reason you prefer to use those statement
> > expressions?
> >
> > On Sat, May 25, 2019 at 6:21 PM Rob Clark
> > wrote:
> > > Is there a convenient #ifdef I can use to guard the list_assert()
> > > macro.. I don't really mind if MSVC can't have this, but would
> > > rather
> > > not let it prevent the rest of us from having nice things
> > >
> > > BR,
> > > -R
> > >
> > > On Sat, May 25, 2019 at 1:23 PM Jason Ekstrand <
> > > ja...@jlekstrand.net> wrote:
> > > > Yeah, that's a GNU extension. It also works in clang but not
> > > > MSVC which is
> > > > used to build NIR.
> > > >
> > > > On May 25, 2019 13:30:29 Rob Clark wrote:
> > > >
> > > > > On Sat, May 25, 2019 at 11:13 AM Ilia Mirkin <
> > > > > imir...@alum.mit.edu> wrote:
> > > > > > On Sat, May 25, 2019 at 2:03 PM Rob Clark <
> > > > > > robdcl...@gmail.com> wrote:
> > > > > > > From: Rob Clark
> > > > > > >
> > > > > > > Debugging use of unsafe iterators when you should have
> > > > > > > used the _safe
> > > > > > > version sucks. Add some DEBUG build support to catch and
> > > > > > > assert if
> > > > > > > someone does that.
> > > > > > >
> > > > > > > I didn't update the UPPERCASE verions of the
> > > > > > > iterators. They should
> > > > > > > probably be deprecated/removed.
> > > > > > >
> > > > > > > Signed-off-by: Rob Clark
> > > > > > > ---
> > > > > > > src/util/list.h | 23 ++-
> > > > > > > 1 file changed, 18 insertions(+), 5 deletions(-)
> > > > > > >
> > > > > > > diff --git a/src/util/list.h b/src/util/list.h
> > > > > > > index 09d1b4cae64..6d89a42b226 100644
> > > > > > > --- a/src/util/list.h
> > > > > > > +++ b/src/util/list.h
> > > > > > > @@ -43,6 +43,13 @@
> > > > > > > #include
> > > > > > > #include "c99_compat.h"
> > > > > > >
> > > > > > > +#ifdef DEBUG
> > > > > > > +# define LIST_DEBUG 1
> > > > > > > +#else
> > > > > > > +# define LIST_DEBUG 0
> > > > > > > +#endif
> > > > > > > +
> > > > > > > +#define list_assert(cond, msg) ({ if (LIST_DEBUG)
> > > > > > > assert((cond) && msg); })
> > > > > >
> > > > > > Not sure if it's worth worrying about, but this style of
> > > > > > macro
> > > > > > definition can be dangerous. One might use it as
> > > > > >
> > > > > > if (x) list_assert()
> > > > > > else blah;
> > > > > >
> > > > > > With the macro defined as-is, the "else blah" will get
> > > > > > attached to the
> > > > > > if in the macro. I believe the common style is to do do
> > > > > > {}while(0) to
> > > > > > avoid such issues (or to use an inline function).
> > > > > > Alternatively, just
> > > > > > define it differently for LIST_DEBUG vs not.
> > > > > >
> > > > >
> > > > > I think the ({ ... }) should save the day..
> > > > >
> > > > > (hmm, is that c99 or a gnu thing? I've it isn't avail on
> > > > > some
> > > > > compilers I guess we should disable list_assert() for those?)
> > > > >
> > > > > BR,
> > > > > -R
> > > > > ___
> > > > > 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
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
On Wed, 2019-05-22 at 18:06 +0200, Akim Demaille wrote: > Hi Erik, > > > Le 22 mai 2019 à 08:54, Erik Faye-Lund < > > erik.faye-l...@collabora.com> a écrit : > > > > I ended up reverting the change [from-%error-verbose to %define > > parse.error verbose] , and I can't find an obcious way to > > support both old and new versions with the same source file. > > Well, you just disable warnings about deprecated features. > -Wno-deprecated. > > > The Android SDK also ships a pre-3.x version of Bison, so you're > > not > > the only one affected. Also, Chocolatey doesn't provide a new > > enough > > version of Bison for Windows either. > > I would be interested in knowing why some distros lag. Do you > happen to know why for some of them? > The only clear examples I know of are the Android SDK and Chocolatey. As I said before, we mighit not have to use the bison version shipped in the Android SDK, so perhaps that's fixable. And for Chocolatey, it turns out they have a winflexbison pacakge and a winflexbison3 package, and the latter has a more recent Bison version. So looking at this again, it looks like it might be solveable, at least in the cases where this is visible to me. Brian: do you think VMWare cuold upgrade the Bison version used in the forseeable future? > > The problem is that Bison doesn't seem to have any mechanism for > > doing > > statements like these conditionally. > > We try to keep your sources nice and clean, and using %if or > things like this is anything but nice. So far these old > directives are not a maintenance burden, so there is no plan > to drop support for them. But still, at least for consistency, > I promote the newest forms. > Thanks for that clarification, makes sense. > > The only way around that that I > > can see is to pre-process the source files somehow. But especially > > with > > three different build systems, that's not really a venue I find > > particularly attractive. If someone can think of a neat solution, I > > would certainly love to hear about it :) > > Don't do that! > Yeah, I'm not planning on going down that road, as it seems needlessly convoluted. > > For now I guess we can just live with the warning. But whenever the > > Bison devs decide to remove support for %error-verbose, I fear that > > we'll either have to drop support for older versions or live with > > pre- > > processing. > > This should not happen. What should happen though, is that distros > stop shipping old versions. > I fully agree. > [generating the parsers in the tarballs] > > I don't really think this would work for us in Mesa. We no longer > > generate the distribution using autotools since we switched to > > Meson, > > we just do git archive these days. > > Well, I think that's a pity. The distinction between end user tools > and maintainer tools is a useful one. As exemplified by the issue > at hand. > I don't think this would have solved the issue for VCS users anyway, which is a large portion of our users these days, so I'm not sure it would have helped all that much. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
On Wed, 2019-05-22 at 20:41 +0200, Akim Demaille wrote: > > Le 22 mai 2019 à 18:06, Akim Demaille a écrit > > : > > > > Hi Erik, > > > > > Le 22 mai 2019 à 08:54, Erik Faye-Lund < > > > erik.faye-l...@collabora.com> a écrit : > > > The Android SDK also ships a pre-3.x version of Bison, so you're > > > not > > > the only one affected. Also, Chocolatey doesn't provide a new > > > enough > > > version of Bison for Windows either. > > > > I would be interested in knowing why some distros lag. Do you > > happen to know why for some of them? > > Well, it appears that Bison 3.3.2 is available. Bundled with Flex > for some reason I find debatable, but it's there. > > https://chocolatey.org/packages/winflexbison3 > Thanks for the pointer! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
On Wed, 2019-05-22 at 15:21 +0200, Hans Åberg wrote: > > On 22 May 2019, at 08:54, Erik Faye-Lund < > > erik.faye-l...@collabora.com> wrote: > > > > The problem is that Bison doesn't seem to have any mechanism for > > doing > > statements like these conditionally. The only way around that that > > I > > can see is to pre-process the source files somehow. But especially > > with > > three different build systems, that's not really a venue I find > > particularly attractive. If someone can think of a neat solution, I > > would certainly love to hear about it :) > > One can set the distribution so that the Bison sources are only re- > compiled if modified. > This would only work for tarballs, though, no? Otherwise we'd need to commit the generated files, which is tricky because the location depends on where the build-dir is located, and would probably not play well with different developers having different versions, leading to variance in the generated result. I don't really think this would work for us in Mesa. We no longer generate the distribution using autotools since we switched to Meson, we just do git archive these days. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
I ended up reverting the change, and I can't find an obcious way to
support both old and new versions with the same source file.
The Android SDK also ships a pre-3.x version of Bison, so you're not
the only one affected. Also, Chocolatey doesn't provide a new enough
version of Bison for Windows either.
The problem is that Bison doesn't seem to have any mechanism for doing
statements like these conditionally. The only way around that that I
can see is to pre-process the source files somehow. But especially with
three different build systems, that's not really a venue I find
particularly attractive. If someone can think of a neat solution, I
would certainly love to hear about it :)
For now I guess we can just live with the warning. But whenever the
Bison devs decide to remove support for %error-verbose, I fear that
we'll either have to drop support for older versions or live with pre-
processing.
We can cross that bridge when we get there. Perhaps by then the world
looks a bit differently?
On Tue, 2019-05-21 at 15:51 +0200, Erik Faye-Lund wrote:
> Right. I guess with an old enough bison version, this can happen.
> I'll see if I can come up with something better.
>
> On May 21, 2019 15:47, Brian Paul wrote:
> > I think this change broke the MSVC build for us.
> >
> > I may not have time to investigate until later today.
> >
> > -Brian
> >
> >
> > On 05/21/2019 05:41 AM, GitLab Mirror wrote:
> > > Module: Mesa
> > > Branch: master
> > > Commit: eb85124a9f6e9cb94d0d4a99f91bbae374777e3a
> > > URL:
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3Deb85124a9f6e9cb94d0d4a99f91bbae374777e3adata=02%7C01%7Cbrianp%40vmware.com%7C8fb4b04aba0f46cf005d08d6dde15558%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636940357210597924sdata=N0sBC6rz%2F4KcpZyCKuNbNqNNhSE%2Fu6d8DcMCQY7STkY%3Dreserved=0
> >
> > >
> > > Author: Erik Faye-Lund
> > > Date: Mon May 20 13:29:05 2019 +0200
> > >
> > > glsl: do not use deprecated bison-keyword
> > >
> > > %error-verbose has been deprecated since Bison 3.0, which was
> > released
> > > in 2013. In Bison 3.3.1 which was recently released, this has
> > started
> > > causing warnings. Let's update the code to do this in the modern
> > way
> > > intead, to avoid cluttering the output needlessly.
> > >
> > > Signed-off-by: Erik Faye-Lund
> > > Reviewed-by: Timothy Arceri
> > >
> > > ---
> > >
> > > src/compiler/glsl/glcpp/glcpp-parse.y | 2 +-
> > > src/compiler/glsl/glsl_parser.yy | 2 +-
> > > src/mesa/program/program_parse.y | 2 +-
> > > 3 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y
> > b/src/compiler/glsl/glcpp/glcpp-parse.y
> > > index 1c095cb66f9..736af7e680d 100644
> > > --- a/src/compiler/glsl/glcpp/glcpp-parse.y
> > > +++ b/src/compiler/glsl/glcpp/glcpp-parse.y
> > > @@ -155,7 +155,7 @@ add_builtin_define(glcpp_parser_t *parser,
> > const char *name, int value);
> > > %}
> > >
> > > %pure-parser
> > > -%error-verbose
> > > +%define parse.error verbose
> > >
> > > %locations
> > > %initial-action {
> > > diff --git a/src/compiler/glsl/glsl_parser.yy
> > b/src/compiler/glsl/glsl_parser.yy
> > > index 6426f890b9e..dc6aade2643 100644
> > > --- a/src/compiler/glsl/glsl_parser.yy
> > > +++ b/src/compiler/glsl/glsl_parser.yy
> > > @@ -81,7 +81,7 @@ static bool match_layout_qualifier(const char
> > *s1, const char *s2,
> > > %expect 0
> > >
> > > %pure-parser
> > > -%error-verbose
> > > +%define parse.error verbose
> > >
> > > %locations
> > > %initial-action {
> > > diff --git a/src/mesa/program/program_parse.y
> > b/src/mesa/program/program_parse.y
> > > index 7398f5f507a..3d0c1e2ea9e 100644
> > > --- a/src/mesa/program/program_parse.y
> > > +++ b/src/mesa/program/program_parse.y
> > > @@ -124,7 +124,7 @@ static struct asm_instruction
> > *asm_instruction_copy_ctor(
> > > %locations
> > > %lex-param { struct asm_parser_state *state }
> > > %parse-param { struct asm_parser_state *state }
> > > -%error-verbose
> > > +%define parse.error verbose
> > >
> > > %union {
> > > struct asm_instruction *inst;
> > >
> >
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
Right. I guess with an old enough bison version, this can happen. I'll see if I can come up with something better.On May 21, 2019 15:47, Brian Paul wrote:I think this change broke the MSVC build for us.
I may not have time to investigate until later today.
-Brian
On 05/21/2019 05:41 AM, GitLab Mirror wrote:
> Module: Mesa
> Branch: master
> Commit: eb85124a9f6e9cb94d0d4a99f91bbae374777e3a
> URL: https://nam04.safelinks.protection.outlook.com/?url=""
>
> Author: Erik Faye-Lund
> Date: Mon May 20 13:29:05 2019 +0200
>
> glsl: do not use deprecated bison-keyword
>
> %error-verbose has been deprecated since Bison 3.0, which was released
> in 2013. In Bison 3.3.1 which was recently released, this has started
> causing warnings. Let's update the code to do this in the modern way
> intead, to avoid cluttering the output needlessly.
>
> Signed-off-by: Erik Faye-Lund
> Reviewed-by: Timothy Arceri
>
> ---
>
> src/compiler/glsl/glcpp/glcpp-parse.y | 2 +-
> src/compiler/glsl/glsl_parser.yy | 2 +-
> src/mesa/program/program_parse.y | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y b/src/compiler/glsl/glcpp/glcpp-parse.y
> index 1c095cb66f9..736af7e680d 100644
> --- a/src/compiler/glsl/glcpp/glcpp-parse.y
> +++ b/src/compiler/glsl/glcpp/glcpp-parse.y
> @@ -155,7 +155,7 @@ add_builtin_define(glcpp_parser_t *parser, const char *name, int value);
> %}
>
> %pure-parser
> -%error-verbose
> +%define parse.error verbose
>
> %locations
> %initial-action {
> diff --git a/src/compiler/glsl/glsl_parser.yy b/src/compiler/glsl/glsl_parser.yy
> index 6426f890b9e..dc6aade2643 100644
> --- a/src/compiler/glsl/glsl_parser.yy
> +++ b/src/compiler/glsl/glsl_parser.yy
> @@ -81,7 +81,7 @@ static bool match_layout_qualifier(const char *s1, const char *s2,
> %expect 0
>
> %pure-parser
> -%error-verbose
> +%define parse.error verbose
>
> %locations
> %initial-action {
> diff --git a/src/mesa/program/program_parse.y b/src/mesa/program/program_parse.y
> index 7398f5f507a..3d0c1e2ea9e 100644
> --- a/src/mesa/program/program_parse.y
> +++ b/src/mesa/program/program_parse.y
> @@ -124,7 +124,7 @@ static struct asm_instruction *asm_instruction_copy_ctor(
> %locations
> %lex-param { struct asm_parser_state *state }
> %parse-param { struct asm_parser_state *state }
> -%error-verbose
> +%define parse.error verbose
>
> %union {
> struct asm_instruction *inst;
>
> ___
> mesa-commit mailing list
> mesa-com...@lists.freedesktop.org
> https://nam04.safelinks.protection.outlook.com/?url=""
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Track BO lifetime with jobs and reference counts
On Tue, 2019-04-16 at 01:49 +, Alyssa Rosenzweig wrote:
> This (fairly large) patch continues work surrounding the panfrost_job
> abstraction to improve job lifetime management. In particular, we add
> infrastructure to track which BOs are used by a particular job
> (currently limited to the vertex buffer BOs), to reference count
> these
> BOs, and to automatically manage the BOs memory based on the
> reference
> count. This set of changes serves as a code cleanup, as a way of
> future
> proofing for allowing flushing BOs, and immediately as a bugfix to
> workaround the missing reference counting for vertex buffer BOs.
> Meanwhile, there are a few cleanups to vertex buffer handling code
> itself, so in the short-term, this allows us to remove the costly VBO
> staging workaround, since this patch addresses the underlying causes.
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gallium/drivers/panfrost/pan_context.c | 37 --
> src/gallium/drivers/panfrost/pan_context.h | 6 +-
> src/gallium/drivers/panfrost/pan_drm.c | 6 ++
> src/gallium/drivers/panfrost/pan_job.c | 82
> +
> src/gallium/drivers/panfrost/pan_job.h | 16
> src/gallium/drivers/panfrost/pan_resource.c | 70 +-
> src/gallium/drivers/panfrost/pan_resource.h | 13
> src/gallium/drivers/panfrost/pan_screen.c | 2 +-
> src/gallium/drivers/panfrost/pan_screen.h | 5 +-
> 9 files changed, 208 insertions(+), 29 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_context.c
> b/src/gallium/drivers/panfrost/pan_context.c
> index 0c97c0a2b43..75a975871db 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -36,6 +36,8 @@
> #include "util/u_memory.h"
> #include "util/u_vbuf.h"
> #include "util/half_float.h"
> +#include "util/u_helpers.h"
> +#include "util/u_format.h"
> #include "indices/u_primconvert.h"
> #include "tgsi/tgsi_parse.h"
>
> @@ -737,7 +739,7 @@ panfrost_emit_varying_descriptor(
> * excepting some obscure circumstances */
>
> static void
> -panfrost_emit_vertex_data(struct panfrost_context *ctx)
> +panfrost_emit_vertex_data(struct panfrost_context *ctx, struct
> panfrost_job *job)
> {
> /* TODO: Only update the dirtied buffers */
> union mali_attr attrs[PIPE_MAX_ATTRIBS];
> @@ -745,6 +747,8 @@ panfrost_emit_vertex_data(struct panfrost_context
> *ctx)
> unsigned invocation_count = MALI_NEGATIVE(ctx-
> >payload_tiler.prefix.invocation_count);
>
> for (int i = 0; i < ctx->vertex_buffer_count; ++i) {
> +if (!(ctx->vb_mask & (1 << i))) continue;
> +
> struct pipe_vertex_buffer *buf =
> >vertex_buffers[i];
> struct panfrost_resource *rsrc = (struct
> panfrost_resource *) (buf->buffer.resource);
>
> @@ -776,9 +780,10 @@ panfrost_emit_vertex_data(struct
> panfrost_context *ctx)
>
> mali_ptr effective_address = rsrc ? (rsrc->bo->gpu +
> buf->buffer_offset) : 0;
>
> -if (effective_address) {
> +if (effective_address & 63) {
> attrs[i].elements =
> panfrost_upload_transient(ctx, rsrc->bo->cpu + buf->buffer_offset,
> attrs[i].size) | MALI_ATTR_LINEAR;
> } else if (effective_address) {
> +panfrost_job_add_bo(job, rsrc->bo);
> attrs[i].elements = effective_address |
> MALI_ATTR_LINEAR;
> } else {
> /* Leave unset? */
> @@ -807,7 +812,7 @@ panfrost_emit_for_draw(struct panfrost_context
> *ctx, bool with_vertex_data)
> struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
>
> if (with_vertex_data) {
> -panfrost_emit_vertex_data(ctx);
> +panfrost_emit_vertex_data(ctx, job);
> }
>
> bool msaa = ctx->rasterizer->base.multisample;
> @@ -1252,7 +1257,8 @@ panfrost_link_jobs(struct panfrost_context
> *ctx)
>
> static void
> panfrost_submit_frame(struct panfrost_context *ctx, bool
> flush_immediate,
> - struct pipe_fence_handle **fence)
> + struct pipe_fence_handle **fence,
> + struct panfrost_job *job)
> {
> struct pipe_context *gallium = (struct pipe_context *) ctx;
> struct panfrost_screen *screen = pan_screen(gallium-
> >screen);
> @@ -1274,15 +1280,15 @@ panfrost_submit_frame(struct panfrost_context
> *ctx, bool flush_immediate,
> #ifndef DRY_RUN
>
> bool is_scanout = panfrost_is_scanout(ctx);
> -int fragment_id = screen->driver->submit_vs_fs_job(ctx,
> has_draws, is_scanout);
> +screen->driver->submit_vs_fs_job(ctx, has_draws,
> is_scanout);
>
> /* If visual, we can stall a frame */
>
> if (!flush_immediate)
> screen->driver->force_flush_fragment(ctx, fence);
>
> -
Re: [Mesa-dev] Move adriconf to mesa repositories
Yeah, moving this to the mesa group in gitlab would be great for visibility. On Sat, 2019-04-13 at 12:22 +, Jean Hertel wrote: > Any other mesa developer interested in seeing this move forward? > > Kind Regards, > Jean Hertel > > ___ > 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
Re: [Mesa-dev] [PATCH v2] virgl: Set bind when creating temp resource.
Nice move to put the logic in its own function!
Reviewed-by: Erik Faye-Lund
On Mon, 2019-04-08 at 09:39 -0700, Lepton Wu wrote:
> virgl render complains about "Illegal resource" when running
> dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
> the reason is that a zero bind value was given for temp resource.
>
> Signed-off-by: Lepton Wu
> ---
> src/gallium/drivers/virgl/virgl_texture.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/gallium/drivers/virgl/virgl_texture.c
> b/src/gallium/drivers/virgl/virgl_texture.c
> index 231319899e0..12b05b52508 100644
> --- a/src/gallium/drivers/virgl/virgl_texture.c
> +++ b/src/gallium/drivers/virgl/virgl_texture.c
> @@ -60,12 +60,22 @@ static void virgl_copy_region_with_blit(struct
> pipe_context *pipe,
>pipe->blit(pipe, );
> }
> }
> +
> +static unsigned int temp_bind(unsigned int orig)
> +{
> + if (orig & ~(PIPE_BIND_RENDER_TARGET | PIPE_BIND_DEPTH_STENCIL |
> +PIPE_BIND_SAMPLER_VIEW))
> + fprintf(stderr, "Waring, possibly unhandled bind: %x\n",
> orig);
> + return orig & (PIPE_BIND_DEPTH_STENCIL |
> PIPE_BIND_RENDER_TARGET);
> +}
> +
> static void virgl_init_temp_resource_from_box(struct pipe_resource
> *res,
>struct pipe_resource
> *orig,
>const struct pipe_box
> *box,
>unsigned level,
> unsigned flags)
> {
> memset(res, 0, sizeof(*res));
> + res->bind = temp_bind(orig->bind);
> res->format = orig->format;
> res->width0 = box->width;
> res->height0 = box->height;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: fix intrinsic names for atomic operations with LLVM 9+
On Mon, 2019-04-08 at 12:39 +0200, Samuel Pitoiset wrote:
> On 4/8/19 12:32 PM, Erik Faye-Lund wrote:
> > On Mon, 2019-04-08 at 11:39 +0200, Samuel Pitoiset wrote:
> > > This fixes the following LLVM error when using
> > > RADV_DEBUG=checkir:
> > > Intrinsic name not mangled correctly for type arguments! Should
> > > be:
> > > llvm.amdgcn.buffer.atomic.add.i32
> > > i32 (i32, <4 x i32>, i32, i32, i1)*
> > > @llvm.amdgcn.buffer.atomic.add
> > >
> > > The cmpswap operation still uses the old intrinsic.
> > >
> > > Signed-off-by: Samuel Pitoiset
> > > ---
> > > src/amd/common/ac_nir_to_llvm.c | 32 +-
> > > ---
> > > ---
> > > 1 file changed, 21 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/src/amd/common/ac_nir_to_llvm.c
> > > b/src/amd/common/ac_nir_to_llvm.c
> > > index 6739551ca26..cc819286c65 100644
> > > --- a/src/amd/common/ac_nir_to_llvm.c
> > > +++ b/src/amd/common/ac_nir_to_llvm.c
> > > @@ -1679,7 +1679,8 @@ static void visit_store_ssbo(struct
> > > ac_nir_context *ctx,
> > > static LLVMValueRef visit_atomic_ssbo(struct ac_nir_context
> > > *ctx,
> > > const nir_intrinsic_instr
> > > *instr)
> > > {
> > > - const char *name;
> > > + const char *op;
> > > + char name[64];
> > > LLVMValueRef params[6];
> > > int arg_count = 0;
> > >
> > > @@ -1696,39 +1697,48 @@ static LLVMValueRef
> > > visit_atomic_ssbo(struct
> > > ac_nir_context *ctx,
> > >
> > > switch (instr->intrinsic) {
> > > case nir_intrinsic_ssbo_atomic_add:
> > > - name = "llvm.amdgcn.buffer.atomic.add";
> > > + op = "add";
> > > break;
> > > case nir_intrinsic_ssbo_atomic_imin:
> > > - name = "llvm.amdgcn.buffer.atomic.smin";
> > > + op = "smin";
> > > break;
> > > case nir_intrinsic_ssbo_atomic_umin:
> > > - name = "llvm.amdgcn.buffer.atomic.umin";
> > > + op = "umin";
> > > break;
> > > case nir_intrinsic_ssbo_atomic_imax:
> > > - name = "llvm.amdgcn.buffer.atomic.smax";
> > > + op = "smax";
> > > break;
> > > case nir_intrinsic_ssbo_atomic_umax:
> > > - name = "llvm.amdgcn.buffer.atomic.umax";
> > > + op = "umax";
> > > break;
> > > case nir_intrinsic_ssbo_atomic_and:
> > > - name = "llvm.amdgcn.buffer.atomic.and";
> > > + op = "and";
> > > break;
> > > case nir_intrinsic_ssbo_atomic_or:
> > > - name = "llvm.amdgcn.buffer.atomic.or";
> > > + op = "or";
> > > break;
> > > case nir_intrinsic_ssbo_atomic_xor:
> > > - name = "llvm.amdgcn.buffer.atomic.xor";
> > > + op = "xor";
> > > break;
> > > case nir_intrinsic_ssbo_atomic_exchange:
> > > - name = "llvm.amdgcn.buffer.atomic.swap";
> > > + op = "swap";
> > > break;
> > > case nir_intrinsic_ssbo_atomic_comp_swap:
> > > - name = "llvm.amdgcn.buffer.atomic.cmpswap";
> > > + op = "cmpswap";
> > > break;
> > > default:
> > > abort();
> > > }
> > >
> > > + if (HAVE_LLVM >= 0x900 &&
> > > + instr->intrinsic != nir_intrinsic_ssbo_atomic_comp_swap) {
> > > + snprintf(name, sizeof(name),
> > > + "llvm.amdgcn.buffer.atomic.%s.i32",
> > > op);
> > The indention here seems off, compared to the else-case... (tabs vs
> > spaces?)
> Will fix before pushing.
> > > + } else {
> > > + snprintf(name, sizeof(name),
> > > + "llvm.amdgcn.buffer.atomic.%s", op);
> > > + }
> > > +
I'm not an expert on LLVM, but the code changes looks good to me, and
the reasoning makes sense. So if you want:
Reviewed-by: Erik Faye-Lund
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: fix intrinsic names for atomic operations with LLVM 9+
On Mon, 2019-04-08 at 11:39 +0200, Samuel Pitoiset wrote:
> This fixes the following LLVM error when using RADV_DEBUG=checkir:
> Intrinsic name not mangled correctly for type arguments! Should be:
> llvm.amdgcn.buffer.atomic.add.i32
> i32 (i32, <4 x i32>, i32, i32, i1)* @llvm.amdgcn.buffer.atomic.add
>
> The cmpswap operation still uses the old intrinsic.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/common/ac_nir_to_llvm.c | 32 +
> ---
> 1 file changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 6739551ca26..cc819286c65 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1679,7 +1679,8 @@ static void visit_store_ssbo(struct
> ac_nir_context *ctx,
> static LLVMValueRef visit_atomic_ssbo(struct ac_nir_context *ctx,
>const nir_intrinsic_instr
> *instr)
> {
> - const char *name;
> + const char *op;
> + char name[64];
> LLVMValueRef params[6];
> int arg_count = 0;
>
> @@ -1696,39 +1697,48 @@ static LLVMValueRef visit_atomic_ssbo(struct
> ac_nir_context *ctx,
>
> switch (instr->intrinsic) {
> case nir_intrinsic_ssbo_atomic_add:
> - name = "llvm.amdgcn.buffer.atomic.add";
> + op = "add";
> break;
> case nir_intrinsic_ssbo_atomic_imin:
> - name = "llvm.amdgcn.buffer.atomic.smin";
> + op = "smin";
> break;
> case nir_intrinsic_ssbo_atomic_umin:
> - name = "llvm.amdgcn.buffer.atomic.umin";
> + op = "umin";
> break;
> case nir_intrinsic_ssbo_atomic_imax:
> - name = "llvm.amdgcn.buffer.atomic.smax";
> + op = "smax";
> break;
> case nir_intrinsic_ssbo_atomic_umax:
> - name = "llvm.amdgcn.buffer.atomic.umax";
> + op = "umax";
> break;
> case nir_intrinsic_ssbo_atomic_and:
> - name = "llvm.amdgcn.buffer.atomic.and";
> + op = "and";
> break;
> case nir_intrinsic_ssbo_atomic_or:
> - name = "llvm.amdgcn.buffer.atomic.or";
> + op = "or";
> break;
> case nir_intrinsic_ssbo_atomic_xor:
> - name = "llvm.amdgcn.buffer.atomic.xor";
> + op = "xor";
> break;
> case nir_intrinsic_ssbo_atomic_exchange:
> - name = "llvm.amdgcn.buffer.atomic.swap";
> + op = "swap";
> break;
> case nir_intrinsic_ssbo_atomic_comp_swap:
> - name = "llvm.amdgcn.buffer.atomic.cmpswap";
> + op = "cmpswap";
> break;
> default:
> abort();
> }
>
> + if (HAVE_LLVM >= 0x900 &&
> + instr->intrinsic != nir_intrinsic_ssbo_atomic_comp_swap) {
> + snprintf(name, sizeof(name),
> + "llvm.amdgcn.buffer.atomic.%s.i32", op);
The indention here seems off, compared to the else-case... (tabs vs
spaces?)
> + } else {
> + snprintf(name, sizeof(name),
> + "llvm.amdgcn.buffer.atomic.%s", op);
> + }
> +
> return ac_build_intrinsic(>ac, name, ctx->ac.i32, params,
> arg_count, 0);
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Set bind when creating temp resource.
On Mon, 2019-04-01 at 12:43 -0700, Lepton Wu wrote:
>
>
> On Tue, Mar 19, 2019 at 4:29 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
> > On Mon, 2019-03-18 at 14:44 -0700, Lepton Wu wrote:
> > > virgl render complains about "Illegal resource" when running
> > > dEQP-
> > EGL.functional.color_clears.single_context.gles2.rgb888_window,
> > > the reason is that a zero bind value was given for temp resource.
> > >
> > > Signed-off-by: Lepton Wu
> > > ---
> > > src/gallium/drivers/virgl/virgl_texture.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/src/gallium/drivers/virgl/virgl_texture.c
> > > b/src/gallium/drivers/virgl/virgl_texture.c
> > > index 231319899e0..563dbacba7e 100644
> > > --- a/src/gallium/drivers/virgl/virgl_texture.c
> > > +++ b/src/gallium/drivers/virgl/virgl_texture.c
> > > @@ -66,6 +66,7 @@ static void
> > > virgl_init_temp_resource_from_box(struct pipe_resource *res,
> > >unsigned level,
> > > unsigned flags)
> > > {
> > > memset(res, 0, sizeof(*res));
> > > + res->bind = orig->bind;
> > > res->format = orig->format;
> > > res->width0 = box->width;
> > > res->height0 = box->height;
> >
> > I have a similar-ish patch for the same issue in a branch I'll be
> > sending out soon:
> >
> > https://gitlab.freedesktop.org/kusma/mesa/commit/6c19b6b98025a1be31eabdb559709b18eecdbafa#note_132855
> >
> > Now, as Dave pointed out, there might be some more cases missing in
> > my
> > patch. I also tried your approach, and it works for me. But I'm not
> > entirely sure it's the right one; for instance I don't think we'd
> > ever
> > want to carry flags like PIPE_BIND_DISPLAY_TARGET and
> > PIPE_BIND_BLENDABLE forward.
> >
> > Perhaps the right thing is to do something like:
> >
> > res->bind = orig->bind & (PIPE_BIND_DEPTH_STENCIL |
> > PIPE_BIND_RENDER_TARGET);
> >
> > But I'm not sure if that's enough; what if we get a surface with
> > PIPE_BIND_SHADER_IMAGE set? We probably still want to use
> > PIPE_BIND_RENDER_TARGET for the blit then...
>
> How about this, let's deal with PIPE_BIND_DEPTH_STENCIL
> and PIPE_BIND_RENDER_TARGET first in this patch, also add a warning
> here
> if we see any other bind so later people can fix things based on
> real cases. Then at least we fix something in this patch.
Sounds good to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] virgl: Set bind when creating temp resource.
On Mon, 2019-03-18 at 14:44 -0700, Lepton Wu wrote:
> virgl render complains about "Illegal resource" when running
> dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
> the reason is that a zero bind value was given for temp resource.
>
> Signed-off-by: Lepton Wu
> ---
> src/gallium/drivers/virgl/virgl_texture.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/virgl/virgl_texture.c
> b/src/gallium/drivers/virgl/virgl_texture.c
> index 231319899e0..563dbacba7e 100644
> --- a/src/gallium/drivers/virgl/virgl_texture.c
> +++ b/src/gallium/drivers/virgl/virgl_texture.c
> @@ -66,6 +66,7 @@ static void
> virgl_init_temp_resource_from_box(struct pipe_resource *res,
>unsigned level,
> unsigned flags)
> {
> memset(res, 0, sizeof(*res));
> + res->bind = orig->bind;
> res->format = orig->format;
> res->width0 = box->width;
> res->height0 = box->height;
I have a similar-ish patch for the same issue in a branch I'll be
sending out soon:
https://gitlab.freedesktop.org/kusma/mesa/commit/6c19b6b98025a1be31eabdb559709b18eecdbafa#note_132855
Now, as Dave pointed out, there might be some more cases missing in my
patch. I also tried your approach, and it works for me. But I'm not
entirely sure it's the right one; for instance I don't think we'd ever
want to carry flags like PIPE_BIND_DISPLAY_TARGET and
PIPE_BIND_BLENDABLE forward.
Perhaps the right thing is to do something like:
res->bind = orig->bind & (PIPE_BIND_DEPTH_STENCIL |
PIPE_BIND_RENDER_TARGET);
But I'm not sure if that's enough; what if we get a surface with
PIPE_BIND_SHADER_IMAGE set? We probably still want to use
PIPE_BIND_RENDER_TARGET for the blit then...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [virglrenderer-devel] virglrenderer on gles, format conversion
On Wed, 2019-03-06 at 13:39 +1000, Dave Airlie wrote: > On Wed, 6 Mar 2019 at 01:01, Erik Faye-Lund > wrote: > > When we try to do a vrend transfer from a renderable texture, we > > end up > > using glReadPixels to read the data. However, OpenGL ES has > > restrictions on what formats are allowed to be used for > > glReadPixels. > > In partcular, only GL_UNSIGNED_BYTE + GL_RGBA are guaranteed to be > > supported (for OpenGL ES 2.0; for OpenGL ES 3.x there's some other > > variants for integer and float textures - it seems we can rely on > > the > > destination format having at least as much range/precision as the > > source format). > > > > But vrend transfers expect no format conversion at all, they want > > to > > read the data verbatim. > > > > I thought the obvious choice was to modify virglrenderer to convert > > back from RGBA to the source format. After a typing out a lot of > > code, > > I realized that even though we have util_format_translate in > > u_format.h, the actual implementation was deleted in d01f462[1]. > > > > OK, so that leaves me with a couple of choices: > > > > 1) Restore the format conversion code in virglrenderer. > > 2) Use some 3rd party pixel-format conversion code instead. > > 3) Do format-conversion back to the desired format in Mesa. > > > > I gave 1) a go by reverting the removal, but this conflicted pretty > > badly due to the 3 years of development that has happened since. It > > might be possible to continue this effort, but I also don't really > > like > > the idea of crash-prone format converion code in virglrenderer. You > > know, for security reasons; virglrenderer runs inside the virtual > > machine manager, which makes it pretty high priviledge code. If we > > don't do 1), I have sent a MR[2] that removes the rest of the > > format > > conversion, so others won't be led astray in the future. > > It's likely we should just pull that in anyways, and start from a > clean base if you decide that is the best path. > OK, I'll untag this with WIP soon. A review would also be nice :) > I agree I don't think this could should be in the host layer if we > can avoid it. > > > I have relatively low expectations that we'd find a good fit for 3) > > as > > we have a very specific and *big* set of formats we need to > > support. > > Format conversion across APIs is often a big pain-point in my > > experience. > > > > As for 3), it's not quite as easily said as done, because we > > currently > > only have protocol commands for reading a format verbatim. So I > > guess > > we'd have to add a new format, and inform the Mesa driver that > > we're > > limited in what formats we support. With this approach, we don't > > need > > conversion code both in mesa *and* in virglrenderer, and we don't > > have > > to actively maintain a fork of the pixel-format code separately. > > > > I'm currently leaning towards 3) for now, but I would like input > > from > > the list, as I feel this is a rather important directional choice. > > I think we'd need to define a list of formats we can readback, and > then somehow convince the guest mesa to do the conversions for us, it > should have all the necessary code already shouldn't it? > Yes, or at least almost. I got this approach working: https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/191 https://gitlab.freedesktop.org/kusma/mesa/tree/virgl-readback-formats I'm pretty happy with how this worked out. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] virglrenderer on gles, format conversion
When we try to do a vrend transfer from a renderable texture, we end up using glReadPixels to read the data. However, OpenGL ES has restrictions on what formats are allowed to be used for glReadPixels. In partcular, only GL_UNSIGNED_BYTE + GL_RGBA are guaranteed to be supported (for OpenGL ES 2.0; for OpenGL ES 3.x there's some other variants for integer and float textures - it seems we can rely on the destination format having at least as much range/precision as the source format). But vrend transfers expect no format conversion at all, they want to read the data verbatim. I thought the obvious choice was to modify virglrenderer to convert back from RGBA to the source format. After a typing out a lot of code, I realized that even though we have util_format_translate in u_format.h, the actual implementation was deleted in d01f462[1]. OK, so that leaves me with a couple of choices: 1) Restore the format conversion code in virglrenderer. 2) Use some 3rd party pixel-format conversion code instead. 3) Do format-conversion back to the desired format in Mesa. I gave 1) a go by reverting the removal, but this conflicted pretty badly due to the 3 years of development that has happened since. It might be possible to continue this effort, but I also don't really like the idea of crash-prone format converion code in virglrenderer. You know, for security reasons; virglrenderer runs inside the virtual machine manager, which makes it pretty high priviledge code. If we don't do 1), I have sent a MR[2] that removes the rest of the format conversion, so others won't be led astray in the future. I have relatively low expectations that we'd find a good fit for 3) as we have a very specific and *big* set of formats we need to support. Format conversion across APIs is often a big pain-point in my experience. As for 3), it's not quite as easily said as done, because we currently only have protocol commands for reading a format verbatim. So I guess we'd have to add a new format, and inform the Mesa driver that we're limited in what formats we support. With this approach, we don't need conversion code both in mesa *and* in virglrenderer, and we don't have to actively maintain a fork of the pixel-format code separately. I'm currently leaning towards 3) for now, but I would like input from the list, as I feel this is a rather important directional choice. I'm also intererested in if someone has some alternative approaches. Perhaps we could use some lower-level API (GBM? Some sort of PBuffer or EGLimage?) to create a lockable, linear surface of the same format, blit to that and read the result from there? Does something like this exist? If so, can we depend on this? [1]: https://gitlab.freedesktop.org/virgl/virglrenderer/commit/d01f462c53f079e79b10617798abc56582e5124f [2]: https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/174 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: mention "Allow commits from members who can merge..."
Yeah, good move! Reivewed-by: Erik Faye-Lund On Mon, 2019-02-25 at 11:57 +, Emil Velikov wrote: > From: Emil Velikov > > Mention the tick-box otherwise only the MR author can rebase the > series. > > Cc: Jordan Justen > Cc: Dylan Baker > Cc: Erik Faye-Lund > Cc: Eric Engestrom > Signed-off-by: Emil Velikov > --- > docs/submittingpatches.html | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/docs/submittingpatches.html > b/docs/submittingpatches.html > index 137e39c925d..65af32d4bba 100644 > --- a/docs/submittingpatches.html > +++ b/docs/submittingpatches.html > @@ -236,6 +236,11 @@ your email administrator for this.) > Other tag examples: gallium, util > > > + > + Tick the following when creating the MR. It allows developers to > + rebase your work on top of master. > + Allow commits from members who can merge to the target > branch > + > >If you revise your patches based on code review and push an update >to your branch, you should maintain a clean > history ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Thu, 2019-02-14 at 16:25 +0100, Gert Wollny wrote: > > > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier < > > > > tournier.e...@gmail.com> wrote: > [...] > > > > > A solution would be to inline the > > > > > function in GLSL but I'm scared than the following shader > > > > > will > > > > > be huge. > From my adventures in R600 Evergreen NIR land I can say that the > shaders with inlined functions get really huge, there were test cases > in the piglits that resulted in >64k temporaries in ssa form (For > using > the NIR lowering fp64 to the emulation code one has to convert the > shader to from vector to scalar operations first though, this may > make > the shader a bit longer too). > > > > > I suspect that's par for the course; the solution we pick will > > > > not be pretty either way. > > > > > > > > Another option is to send TGSI f64 down the wire and lower in > > > > the > > > > host, in virglrenderer, by emitting glsl helper functions which > > > > implement fp64 and calling those. > > > > > > Options are then: > > > > > > a) do an Apple on evergreen - export GL4.x don't expose the > > > ARB_gpu_shader_fp64 string, a lie, but a consistent lie. > > > b) do fp32 for all fp64 - conversion to/from fp64 is still messy, > > > but > > > might cover at least some basic tests > > > c) lower in guest - ugly tgsi, slow > > > d) lower in host - emulate in virglrenderer, > > > > > > I'm actually considering (d) might not be the worst solution, we > > > could in theory reuse the GLSL shaders code from mesa, and just > > > link > > > it in as another GLSL string. > > > > > > > I would propose a fifth "option": > > > > - Do a) and/or b) for now (i.e expose a not-technically-conformant > > 4.0) > I wonder why this was never done for r600/evergreen, and unless > conformance is the aim I'd say that this seems to be the best short > term option. When I look at the state of D-GL on GLES hosts then I > think there are more important issues that need to be fixed (e.g. > KHR- > GL33 failures) than sinking much time in implementing an extension > that > is used by nearly nobody. (a) is probably better in case someone > wants > to use this and expects correct results, because then no result is > better then a result that is slightly off. > > > - Move to productize Zink, which: > > 1) Targets Vulkan, where FP64 is an optional feature that > > doesn't > > require an extension > > (VkPhysicalDeviceFeatures::shaderFloat64). > > 2) Uses NIR, where lowering of FP64 is already supported for > > those > > devices that doesn't support FP64. > I second that given that Vulkan is the next step anyway, I want to add to this that increasing the OpenGL version support on top of OpenGL ES with the current (non-vulkan) solution is going to be more and more difficult for each version, because fewer and fewer drivers are using TGSI, which means TGSI will start lagging more and more behind NIR in terms of functionality unless we put in a rather sizable effort to keep TGSI alive. There's good reasons why drivers are moving away from TGSI; it's a dated IR that even for its time didn't use modern compiler techniques. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: move ALU instruction before the jump instruction
On Wed, 2019-02-13 at 11:53 -0800, Ian Romanick wrote: > On 2/13/19 9:59 AM, Juan A. Suarez Romero wrote: > > On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote: > > > On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote: > > > > On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote: > > > > > On 2/12/19 12:58 AM, Juan A. Suarez Romero wrote: > > > > > > opt_split_alu_of_phi moves ALU instruction to the end of > > > > > > continue block. > > > > > > > > > > > > But if the continue block ends with a jump instruction (an > > > > > > explicit > > > > > > "continue" instruction) then the ALU must be inserted > > > > > > before the jump, > > > > > > as it is illegal to add instructions after the jump. > > > > > > > > > > I'm assuming you found this by inspection? Since this pass > > > > > only > > > > > operates when the first block of the loop only has two > > > > > predecessors (the > > > > > block before the loop and the implicit continue at the end of > > > > > the loop), > > > > > this shouldn't be a a problem in practice... or were you able > > > > > to trigger > > > > > it somehow? > > > > > > > > Found when dealing with the SPIR-V code that I've sent in > > > > https://lists.freedesktop.org/archives/mesa-dev/2019-February/214906.html > > > > > > > > > > > > The obtained NIR code has an explicit continue at the end of > > > > the loop (see > > > > http://paste.debian.net/1067619/, in particular the loop with > > > > header block_2). > > > > > > That loop is a mess. Wow... I'm impressed. :) I see a continue > > > inside > > > an else-clause at line 107 and a break at line 112. I now > > > understand > > > the fundamental problem. Am I correct that this problem would > > > also > > > occur before 8fb8ebfbb05? And that's what "nir: allow stitching > > > of > > > non-empty block" fixes? > > > > Yeah :) It's a SPIR-V code generated with some fuzzy tool. > > > > > > And yes, even with this patch applied, it will break later when > > stitching the > > code. > > > > Fortunately, I got rid of the "nir: allow stitching of non-empty > > block" patch > > and sent instead another one that removes one of the jumps to avoid > > the issue. > > > > > Did nir_validate trip on this? If not, it seems like it > > > should... > > > though that might cause problems when nir_validate is run > > > immediately > > > following translation into NIR. > > > > The NIR code seems valid. The error (assert) was caught by > > nir_instr_insert, > > when applying the optimization. > > Having instructions in a block after an unconditional jump seems > bogus. > It's technically valid, but it can never be correct. I'm pretty > sure > we scrub that from the GLSL frontend, and I'm not sure it's legal in > SPIR-V. I'll look into it more. > It's definitely illegal in SPIR-V, as *all* control flow instructions terminate blocks. You would have to start a new block (by inserting a label) to make it legal. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts on fp64 for GLES?
On Thu, 2019-02-14 at 08:53 +1000, Dave Airlie wrote: > On Thu, 14 Feb 2019 at 06:04, Stéphane Marchesin > wrote: > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier < > > tournier.e...@gmail.com> wrote: > > > > > > > > > On Wednesday, 13 February 2019, Stéphane Marchesin < > > > stephane.marche...@gmail.com> wrote: > > > > On Wed, Feb 13, 2019 at 10:29 AM Elie Tournier < > > > > tournier.e...@gmail.com> wrote: > > > > > > > > > > > > > > > On Wednesday, 13 February 2019, Ilia Mirkin < > > > > > imir...@alum.mit.edu> wrote: > > > > > > On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier < > > > > > > tournier.e...@gmail.com> wrote: > > > > > > > On Fri, Jan 25, 2019 at 11:52:56AM -0800, Stéphane > > > > > > > Marchesin wrote: > > > > > > > > On Fri, Jan 25, 2019 at 2:25 AM Gert Wollny < > > > > > > > > gw.foss...@gmail.com> wrote: > > > > > > > > > Am Donnerstag, den 24.01.2019, 22:25 -0800 schrieb > > > > > > > > > Stéphane Marchesin: > > > > > > > > > > Yes, it's for running virgl on top of GLES. To > > > > > > > > > > emulate fp64 in GL on > > > > > > > > > > the guest side, we need fp64 on the host... > > > > > > > > > > > > > > > > > > BTW: we could also get it emulated from the guest > > > > > > > > > side. When Elie (in > > > > > > > > > CC) initially proposed the fp64 emulation series it > > > > > > > > > was for r600 and > > > > > > > > > TGSI was emitted. The created shaders are horribly > > > > > > > > > long and it is > > > > > > > > > certainly not performant, but if it's just for > > > > > > > > > getting OpenGL 4.0 > > > > > > > > > exposed it should be good enough. > > > > > > > > > > > > > > > > Yes, Ilia suggested this on IRC yesterday. My > > > > > > > > impression is that not > > > > > > > > many applications/games need high performance fp64 > > > > > > > > (it's likely mostly > > > > > > > > compute stuff, which is not our target). I could be > > > > > > > > wrong though. If > > > > > > > > anyone knows differently, please tell us :) > > > > > > > > > > > > > > > > > I'm not sure though how much work it would be to add > > > > > > > > > this to the soft > > > > > > > > > fp64 as it has now landed for NIR, though. > > > > > > > > > > > > > > > > Yes, with virgl not using NIR, I am not sure how much > > > > > > > > work soft fp64 > > > > > > > > will require. > > > > > > > > > > > > > > I spent a bit of time on the project recently. > > > > > > > My thinking so far: > > > > > > > * FP64 is bad . But everyone knows that. :) > > > > > > > * Using the current soft fp64 require to emulate int64. > > > > > > > * Soft fp64 and int64 involve function call which is, > > > > > > > iiuc, not really > > > > > > > supported in TGSI. > > > > > > > * Soft fp64 is tied to NIR. Some pass/hack need to be > > > > > > > port to GLSLIR. > > > > > > > > > > > > > > So the project will require a lot of work. > > > > > > > > > > > > But what's the alternative? Let's say you make a spec to > > > > > > expose > > > > > > "proper" fp64 in GLES. No one outside mesa will implement > > > > > > this (why > > > > > > bother). Certainly not the Adreno/Mali proprietary stacks > > > > > > of the > > > > > > world. > > > > > > > > > > I'm not saying that we should get an extension. > > > > > My point was, it's a lot of work. > > > > > > > > > > > > And if you are on a stack that implements this in GLES, you > > > > > > might as > > > > > > well be using desktop GL anyways... > > > > > > > > > > > > So going back to the original -- what use-case are you > > > > > > trying to cover > > > > > > that's not already covered some other way? > > > > > > > > > > iiuc, Stephane want to run GL desktop on top of GLES. > > > > > In order to expose a bigger version of GL, he need fp64 > > > > > support. > > > > > > > > Yes, at a high level, softfp64 seems to solve the problem we > > > > have. If > > > > a TGSI lowering pass is too complex, could we do it as a GLSL > > > > lowering > > > > pass? > > > > > > > Hi Stéphane, > > > > > > Currently, we lower everything in GLSL then we convert to TGSI. > > > The issue is that the lowering pass generate something like 'call > > > _umul builtin'. Then we try to convert it to TGSI. The problem > > > appears here. > > > A solution would be to inline the function in GLSL but I'm scared > > > than the following shader will be huge. > > > > I suspect that's par for the course; the solution we pick will not > > be > > pretty either way. > > > > Another option is to send TGSI f64 down the wire and lower in the > > host, in virglrenderer, by emitting glsl helper functions which > > implement fp64 and calling those. > > Options are then: > > a) do an Apple on evergreen - export GL4.x don't expose the > ARB_gpu_shader_fp64 string, a lie, but a consistent lie. > b) do fp32 for all fp64 - conversion to/from fp64 is still messy, but > might cover at least some basic tests > c) lower in guest - ugly tgsi, slow > d) lower in host - emulate in virglrenderer, > > I'm actually considering (d)
Re: [Mesa-dev] [PATCH 2/3] st/mesa: enable GL_EXT_float_blend when possible
Reviewed-by: Erik Faye-Lund
And just for the record, I think this is the right "compromise" between
checking all possible formats and facilitating fallbacks.
On Tue, 2019-02-12 at 22:40 -0500, Ilia Mirkin wrote:
> If the driver supports PIPE_BIND_BLENABLE on RGBA32F, flip
> EXT_float_blend on (which will affect ES3 contexts).
>
> Signed-off-by: Ilia Mirkin
> ---
> src/mesa/state_tracker/st_extensions.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index d2660099fc1..528e6b74a54 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -820,6 +820,12 @@ void st_init_extensions(struct pipe_screen
> *screen,
>PIPE_FORMAT_R16G16B16A16_SNORM } },
> };
>
> + /* Required: render target, sampler, and blending */
> + static const struct st_extension_format_mapping rt_blendable[] =
> {
> + { { o(EXT_float_blend) },
> +{ PIPE_FORMAT_R32G32B32A32_FLOAT } },
> + };
> +
> /* Required: depth stencil and sampler support */
> static const struct st_extension_format_mapping
> depthstencil_mapping[] = {
>{ { o(ARB_depth_buffer_float) },
> @@ -1025,6 +1031,10 @@ void st_init_extensions(struct pipe_screen
> *screen,
> init_format_extensions(screen, extensions, rendertarget_mapping,
>ARRAY_SIZE(rendertarget_mapping),
> PIPE_TEXTURE_2D,
>PIPE_BIND_RENDER_TARGET |
> PIPE_BIND_SAMPLER_VIEW);
> + init_format_extensions(screen, extensions, rt_blendable,
> + ARRAY_SIZE(rt_blendable), PIPE_TEXTURE_2D,
> + PIPE_BIND_RENDER_TARGET |
> PIPE_BIND_SAMPLER_VIEW |
> + PIPE_BIND_BLENDABLE);
> init_format_extensions(screen, extensions, depthstencil_mapping,
>ARRAY_SIZE(depthstencil_mapping),
> PIPE_TEXTURE_2D,
>PIPE_BIND_DEPTH_STENCIL |
> PIPE_BIND_SAMPLER_VIEW);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] panfrost: Include glue for out-of-tree legacy code
On Tue, 2019-02-05 at 06:26 +, Alyssa Rosenzweig wrote: > In addition to the DRM interface in active development, for legacy > kernels Panfrost has a small, optional, out-of-tree glue repository. > For > various reasons, this legacy code should not be included in Mesa > proper, > but this commit allows it to coexist peacefully with upstream > Panfrost. > If the nondrm repo is cloned/symlinked to the directory > `src/gallium/drivers/panfrost/nondrm`, legacy functionality will be > built. Otherwise, the driver will build normally, though a runtime > error > message will be printed if a legacy kernel is detected. > > This workaround is icky, but it allows a nearly-upstream Panfrost to > work on real hardware, today. Ideally, this patch will be reverted > when > the Panfrost kernel module is mature and we drop legacy support. > > Signed-off-by: Alyssa Rosenzweig > --- > src/gallium/drivers/panfrost/.gitignore| 1 + > src/gallium/drivers/panfrost/meson.build | 21 ++ > --- > src/gallium/drivers/panfrost/pan_context.c | 3 ++- > src/gallium/drivers/panfrost/pan_screen.c | 9 +++-- > src/gallium/drivers/panfrost/pan_screen.h | 2 +- > 5 files changed, 29 insertions(+), 7 deletions(-) > create mode 100644 src/gallium/drivers/panfrost/.gitignore > > diff --git a/src/gallium/drivers/panfrost/.gitignore > b/src/gallium/drivers/panfrost/.gitignore > new file mode 100644 > index 000..9d2c2c18bef > --- /dev/null > +++ b/src/gallium/drivers/panfrost/.gitignore > @@ -0,0 +1 @@ > +nondrm > diff --git a/src/gallium/drivers/panfrost/meson.build > b/src/gallium/drivers/panfrost/meson.build > index 9b90035d691..5e799eae119 100644 > --- a/src/gallium/drivers/panfrost/meson.build > +++ b/src/gallium/drivers/panfrost/meson.build > @@ -39,7 +39,7 @@ files_panfrost = files( >'pan_blending.c', >'pan_blend_shaders.c', >'pan_wallpaper.c', > - 'pan_pretty_print.c' > + 'pan_pretty_print.c', > ) > > inc_panfrost = [ This hunk seems unrelated... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meson: drop the xcb-xrandr version requirement
On Sat, 2019-02-02 at 12:58 -0500, Marek Olšák wrote: > > > On Sat, Feb 2, 2019, 12:41 PM Eric Engestrom < > eric.engest...@intel.com wrote: > > On Saturday, 2019-02-02 10:32:15 -0500, Marek Olšák wrote: > > > On Sat, Feb 2, 2019, 7:17 AM Eric Engestrom < > > eric.engest...@intel.com wrote: > > > > > > > On Friday, 2019-02-01 15:42:17 -0500, Marek Olšák wrote: > > > > > If there is no feedback soon, I'll push this. > > > > > > > > Have you tested that xcb-randr < 1.12 works? > > > > Probably shouldn't remove a restriction unless you're sure it > > isn't > > > > needed :) > > > > > > > > > > Is this a joke? I'm just mirroring autotools. Supporting the same > > linux > > > distributions as autotools is a requirement for meson's general > > acceptance. > > > > No, I'm being serious: just because a restriction didn't exist on > > autotools doesn't mean that code path was exercised by people > > running > > an old xcb-randr, hence the need to test it :) > > > > I didn't mean to offend you, I was just asking the question to make > > sure > > this was tested before we claim to support xcb-randr < 1.12, as it > > might > > be that autotools was simply missing the version check. > > Ok. I use old xcb-xrandr on some of my systems, one of them used to > be my main system. Not being able to use meson on those systems > without this patch is a big deal for me. This sounds like you have indeed tested on xcb-randr < 1.12, so I suppose the answer to the question is "yes"? If so, I think it's all good, no? Anyway, I think this seems like the right move, and since Keith has't responded, feel free to add: Reviewed-by: Erik Faye-Lund ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meson: drop the xcb-xrandr version requirement
On Wed, 2019-01-30 at 12:32 -0500, Marek Olšák wrote:
> ping
>
Probably worth including Keith, who added this line...
But yeah, I tend to think that this makes sense. The autotools-build
doesn't seem to tie this to a specific version, and seems to have been
used without problems for almost a year. But let's hear what Keith
things first...
> On Fri, Jan 25, 2019 at 5:48 PM Marek Olšák wrote:
> > From: Marek Olšák
> >
> > autotools doesn't have any requirement. This fixes meson on Ubuntu
> > 16.04.
> > ---
> > meson.build | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meson.build b/meson.build
> > index 34e2a032548..7f16c3070fe 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1389,21 +1389,21 @@ if with_platform_x11
> >dep_xxf86vm = dependency('xxf86vm')
> > endif
> > dep_glproto = dependency('glproto', version : '>= 1.4.14')
> >endif
> >if (with_egl or (
> >with_gallium_vdpau or with_gallium_xvmc or with_gallium_xa
> > or
> >with_gallium_omx != 'disabled'))
> > dep_xcb_xfixes = dependency('xcb-xfixes')
> >endif
> >if with_xlib_lease
> > -dep_xcb_xrandr = dependency('xcb-randr', version : '>= 1.12')
> > +dep_xcb_xrandr = dependency('xcb-randr')
> > dep_xlib_xrandr = dependency('xrandr', version : '>= 1.3')
> >endif
> > endif
> >
> > if get_option('gallium-extra-hud')
> >pre_args += '-DHAVE_GALLIUM_EXTRA_HUD=1'
> > endif
> >
> > _sensors = get_option('lmsensors')
> > if _sensors != 'false'
> > ___
> > 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
Re: [Mesa-dev] [PATCH] nir: Optimize double-precision lower_round_even()
On Tue, 2019-01-29 at 14:41 +, Roland Scheidegger wrote: > Am 29.01.19 um 10:10 schrieb Erik Faye-Lund: > > On Mon, 2019-01-28 at 09:31 -0800, Matt Turner wrote: > > > Use the trick of adding and then subtracting 2**52 (52 is the > > > number > > > of > > > explicit mantissa bits a double-precision floating-point value > > > has) > > > to > > > implement round-to-even. > > > > > > Cuts the number of instructions on SKL of the piglit test > > > fs-roundEven-double.shader_test from 109 to 21. > > > > Won't this approach only work for "small" values, that is values > > equal > > to or smaller than DBL_MAX - 2**52? Once you add 2**52, you'll get > > infinity, and you can't subtract 2**52 away again without being > > stuck > > with infinity, no... > > It would actually work for very large numbers in theory. > The only numbers the magic trick won't work are those with magnitude > between 2^52 and 2^104 (those are already integral and the add will > cause some of them to be rounded up to another number with the sub > not > doing anything afterwards), for larger ones it will work again, up to > and including inf. > But in any case, that's what the bcsel is for, for numbers larger > than > 2^52 no operations are performed at all. > Doh, I missed the bcsel somehow. Thanks for setting me straight. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts after hitting 100 merge requests?
On Mon, 2019-01-28 at 17:20 -0500, Rob Clark wrote: > On Mon, Jan 28, 2019 at 2:29 PM Ilia Mirkin > wrote: > > 2. I've seen a bunch of things land where I would have had comments > > beforehand. Once the patch is in, I don't really have an easy way > > to > > provide feedback. In the past if such a thing would happen, I just > > take the subject of the patch, pop it into the search in gmail, and > > reply to the email. It's unclear what I should do now -- for most > > things thus far, just pinging on IRC has worked out, but there's > > nowhere to either see the discussion that led to the change nor to > > provide post-commit feedback. In most places where I've done > > "tracked" > > reviews, there's linkage in the commit message to be able to find > > the > > reviews in the review system. > > it would be nice to see gitlab injecting some tags (not just r-b, but > also a link back to the MR) into the git commit msg > They kinda do, just not in the commit message: https://gitlab.freedesktop.org/mesa/mesa/commit/3cb65cf8aa090c39b520ae26fa32097ad18fd067 Notice there's a "1 merge request !75"-link in there. That takes you back to the MR. This should be present for all commits in a merge request. If you want to access this information from the command-line, you can setup a fetch-spec for the merge-requests, like so: git config --add remote.origin.fetch +refs/merge- requests/*/head:refs/remotes/origin/merge-requests/* Make sure you've fetched the remote first, and do this: $ git describe --all --contains 3cb65cf remotes/origin/merge-requests/75 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: Optimize double-precision lower_round_even()
On Mon, 2019-01-28 at 09:31 -0800, Matt Turner wrote: > Use the trick of adding and then subtracting 2**52 (52 is the number > of > explicit mantissa bits a double-precision floating-point value has) > to > implement round-to-even. > > Cuts the number of instructions on SKL of the piglit test > fs-roundEven-double.shader_test from 109 to 21. Won't this approach only work for "small" values, that is values equal to or smaller than DBL_MAX - 2**52? Once you add 2**52, you'll get infinity, and you can't subtract 2**52 away again without being stuck with infinity, no... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: GLES2 fix for OES float/half-float textures.
On Mon, 2019-01-28 at 09:22 -0800, Eric Anholt wrote: > Erik Faye-Lund writes: > > > On Fri, 2019-01-25 at 13:41 -0800, Eric Anholt wrote: > > > Nick Kreeger writes: > > > > > > > The OES_texture* extensions for float and half-float are valid > > > > when > > > > GLES2 is present w/ the matching > > > > OES_texture_float/OES_texture_half_float extensions. This fix > > > > ensures > > > > that these formats are valid for this configuration. > > > > > > I don't see OES_texture_float.txt specifying these tokens as > > > additions > > > to the list of valid base internal formats (table 3.8 of the > > > GLES2 > > > spec), so I think this change is invalid. Sized internalformats > > > were > > > introduced with GLES3. > > > > > > > Hmm, seems you're right. I suppose this should be reverted? Nick, > > what > > do you think? > > I don't see it in the tree, though. Right. I now feel a bit embaressed for my poor memory :P Seems I noticed this in the discussion for the v3 of the patch, which lead to it being dropped: https://lists.freedesktop.org/archives/mesa-dev/2018-December/211819.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: GLES2 fix for OES float/half-float textures.
On Fri, 2019-01-25 at 13:41 -0800, Eric Anholt wrote: > Nick Kreeger writes: > > > The OES_texture* extensions for float and half-float are valid when > > GLES2 is present w/ the matching > > OES_texture_float/OES_texture_half_float extensions. This fix > > ensures > > that these formats are valid for this configuration. > > I don't see OES_texture_float.txt specifying these tokens as > additions > to the list of valid base internal formats (table 3.8 of the GLES2 > spec), so I think this change is invalid. Sized internalformats were > introduced with GLES3. > Hmm, seems you're right. I suppose this should be reverted? Nick, what do you think? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts after hitting 100 merge requests?
On Wed, 2019-01-23 at 14:47 +, Eric Engestrom wrote: > On Thursday, 2019-01-17 15:55:44 +0100, Erik Faye-Lund wrote: > > It could have been made obvious for instance by showing the commit- > > graph next to the commit-list, decorating it with the branch head > > in > > one end and clear continuation in the other. > > I'd love that, it would really help a lot! > > Care to raise an issue at gitlab asking for this? :) > https://gitlab.com/gitlab-org/gitlab-ce/issues/new > Done: https://gitlab.com/gitlab-org/gitlab-ce/issues/56799 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: add note about sending merge-requests from forks
On Wed, 2019-01-23 at 17:03 +, Emil Velikov wrote: > Hi all, > > In case the patch is still outstanding, feel free to add > Reviewed-by: Emil Velikov > Thanks, pushed. > On Wed, 23 Jan 2019 at 11:20, Erik Faye-Lund > wrote: > > On Wed, 2019-01-23 at 10:42 +, Eric Engestrom wrote: > > > On Wednesday, 2019-01-23 11:21:27 +0100, Erik Faye-Lund wrote: > > > > On Wed, 2019-01-23 at 10:14 +, Daniel Stone wrote: > > > > > Hi, > > > > > > > > > > On Wed, 23 Jan 2019 at 10:09, Eric Engestrom < > > > > > eric.engest...@intel.com> wrote: > > > > > > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund > > > > > > wrote: > > > > > > > Sending MRs from the main Mesa repository increase > > > > > > > clutter in > > > > > > > the > > > > > > > repository, and decrease visibility of project-wide > > > > > > > branches. > > > > > > > So > > > > > > > it's > > > > > > > better if MRs are sent from forks instead. > > > > > > > > > > > > > > Let's add a note about this, in case its not obvious to > > > > > > > everyone. > > > > > > > > > > > > Yes please, we already have way too many dead branches in > > > > > > the > > > > > > main > > > > > > repo > > > > > > without adding that kind of things to it. > > > > > > > > > > > > One other thing is that (last time I checked) the scripts > > > > > > propagating > > > > > > the repo to github et al. don't propagate branch deletions, > > > > > > which > > > > > > means > > > > > > the clutter never gets cleaned there. > > > > > > > > > > They're propagated from gitlab.fd.o to git.fd.o, as the hook > > > > > is > > > > > run > > > > > within regular post-receive, but you're right that pushing > > > > > from > > > > > git.fd.o to GitHub doesn't notice old branches, as it just > > > > > pushes > > > > > everything present in the git.fd.o repo to GitHub, and > > > > > doesn't > > > > > notice > > > > > any branches no longer present. > > > > > > > > Yeah, and then add the problem that forking in Github copies > > > > *all* > > > > branches as well (not just the default branch), means that > > > > these > > > > branches keeps getting replicated over there. It gets nasty > > > > quickly. > > > > > > > > Perhaps we should do a manual spring cleaning in the repo soon, > > > > moving > > > > old, stale branches out to some historical repo and making sure > > > > official forks don't have any cruft? > > > > > > I looked at that a year or two ago, but I quickly gave up. You're > > > welcome > > > to give it a go, but be aware that there's a very large number of > > > very old > > > branches. > > > > Looks quite managable to me. There's really only a few branches > > that I > > think should be kept int he main repo, and I think they can be > > enumerated like this: > > > > git for-each-ref refs/remotes/origin --format "%(refname:lstrip=3)" > > | > > grep -E "^[0-9]+\.[0-9]+$|^mesa_[0-9]+_[0-9]+_branch$|^staging/[0- > > 9]+\.[0-9]+$" > > > > Those seems to be *actual* release-branches. There's some other > > "almost > > release-branches", like these: > > > > $ git for-each-ref refs/remotes/origin --format > > "%(refname:lstrip=3)" | > > grep -vE "^[0-9]+\.[0-9]+$|^mesa_[0-9]+_[0-9]+_branch$|^staging/[0- > > 9]+\.[0-9]+$" | grep -E "^mesa_[0-9]+_branch$|^staging/|^[0- > > 9]+\.[0- > > 9]+" > > 18.1-proposed > > 7.8-gles > > mesa_20040127_branch > > mesa_20040309_branch > > mesa_20050114_branch > > staging/18.2-ci > > > > I suppose to be conservative we could include these as well. > > > > But perhaps someone like Emil could chime in here? > > > > Personally, I think we could go as far as removing all "closed" > > release > > branches as well; we can just branch out from the most recent tag > > if we &
Re: [Mesa-dev] [PATCH] docs: add note about sending merge-requests from forks
On Wed, 2019-01-23 at 10:42 +, Eric Engestrom wrote: > On Wednesday, 2019-01-23 11:21:27 +0100, Erik Faye-Lund wrote: > > On Wed, 2019-01-23 at 10:14 +, Daniel Stone wrote: > > > Hi, > > > > > > On Wed, 23 Jan 2019 at 10:09, Eric Engestrom < > > > eric.engest...@intel.com> wrote: > > > > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote: > > > > > Sending MRs from the main Mesa repository increase clutter in > > > > > the > > > > > repository, and decrease visibility of project-wide branches. > > > > > So > > > > > it's > > > > > better if MRs are sent from forks instead. > > > > > > > > > > Let's add a note about this, in case its not obvious to > > > > > everyone. > > > > > > > > Yes please, we already have way too many dead branches in the > > > > main > > > > repo > > > > without adding that kind of things to it. > > > > > > > > One other thing is that (last time I checked) the scripts > > > > propagating > > > > the repo to github et al. don't propagate branch deletions, > > > > which > > > > means > > > > the clutter never gets cleaned there. > > > > > > They're propagated from gitlab.fd.o to git.fd.o, as the hook is > > > run > > > within regular post-receive, but you're right that pushing from > > > git.fd.o to GitHub doesn't notice old branches, as it just pushes > > > everything present in the git.fd.o repo to GitHub, and doesn't > > > notice > > > any branches no longer present. > > > > Yeah, and then add the problem that forking in Github copies *all* > > branches as well (not just the default branch), means that these > > branches keeps getting replicated over there. It gets nasty > > quickly. > > > > Perhaps we should do a manual spring cleaning in the repo soon, > > moving > > old, stale branches out to some historical repo and making sure > > official forks don't have any cruft? > > I looked at that a year or two ago, but I quickly gave up. You're > welcome > to give it a go, but be aware that there's a very large number of > very old > branches. Looks quite managable to me. There's really only a few branches that I think should be kept int he main repo, and I think they can be enumerated like this: git for-each-ref refs/remotes/origin --format "%(refname:lstrip=3)" | grep -E "^[0-9]+\.[0-9]+$|^mesa_[0-9]+_[0-9]+_branch$|^staging/[0- 9]+\.[0-9]+$" Those seems to be *actual* release-branches. There's some other "almost release-branches", like these: $ git for-each-ref refs/remotes/origin --format "%(refname:lstrip=3)" | grep -vE "^[0-9]+\.[0-9]+$|^mesa_[0-9]+_[0-9]+_branch$|^staging/[0- 9]+\.[0-9]+$" | grep -E "^mesa_[0-9]+_branch$|^staging/|^[0-9]+\.[0- 9]+" 18.1-proposed 7.8-gles mesa_20040127_branch mesa_20040309_branch mesa_20050114_branch staging/18.2-ci I suppose to be conservative we could include these as well. But perhaps someone like Emil could chime in here? Personally, I think we could go as far as removing all "closed" release branches as well; we can just branch out from the most recent tag if we need to back-port something in the future. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: add note about sending merge-requests from forks
On Wed, 2019-01-23 at 10:08 +, Eric Engestrom wrote: > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote: > > Sending MRs from the main Mesa repository increase clutter in the > > repository, and decrease visibility of project-wide branches. So > > it's > > better if MRs are sent from forks instead. > > > > Let's add a note about this, in case its not obvious to everyone. > > Yes please, we already have way too many dead branches in the main > repo > without adding that kind of things to it. > > One other thing is that (last time I checked) the scripts propagating > the repo to github et al. don't propagate branch deletions, which > means > the clutter never gets cleaned there. > > > Signed-off-by: Erik Faye-Lund > > --- > > docs/submittingpatches.html | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/docs/submittingpatches.html > > b/docs/submittingpatches.html > > index 736cbd64de8..b5a70523acd 100644 > > --- a/docs/submittingpatches.html > > +++ b/docs/submittingpatches.html > > @@ -258,6 +258,8 @@ your email administrator for this.) > >rebased > > Make sure your MR is closed if your patches get pushed > > outside > >of GitLab > > +Please send MRs from a personal fork rather than from the > > main > > + Mesa repository > > I would add "as it clutters it unnecessarily" as you mentioned in the > commit message. I was considering this, but decided against it as the other things in this list didn't really specify motivation either. But I think you're right, it's better to include it in this case. Fixed locally (but I added a comma first, which I *think* is correct?): diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html index 736cbd64de8..137e39c925d 100644 --- a/docs/submittingpatches.html +++ b/docs/submittingpatches.html @@ -258,6 +258,8 @@ your email administrator for this.) rebased Make sure your MR is closed if your patches get pushed outside of GitLab +Please send MRs from a personal fork rather than from the main + Mesa repository, as it clutters it unnecessarily. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: add note about sending merge-requests from forks
On Wed, 2019-01-23 at 10:14 +, Daniel Stone wrote: > Hi, > > On Wed, 23 Jan 2019 at 10:09, Eric Engestrom < > eric.engest...@intel.com> wrote: > > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote: > > > Sending MRs from the main Mesa repository increase clutter in the > > > repository, and decrease visibility of project-wide branches. So > > > it's > > > better if MRs are sent from forks instead. > > > > > > Let's add a note about this, in case its not obvious to everyone. > > > > Yes please, we already have way too many dead branches in the main > > repo > > without adding that kind of things to it. > > > > One other thing is that (last time I checked) the scripts > > propagating > > the repo to github et al. don't propagate branch deletions, which > > means > > the clutter never gets cleaned there. > > They're propagated from gitlab.fd.o to git.fd.o, as the hook is run > within regular post-receive, but you're right that pushing from > git.fd.o to GitHub doesn't notice old branches, as it just pushes > everything present in the git.fd.o repo to GitHub, and doesn't notice > any branches no longer present. Yeah, and then add the problem that forking in Github copies *all* branches as well (not just the default branch), means that these branches keeps getting replicated over there. It gets nasty quickly. Perhaps we should do a manual spring cleaning in the repo soon, moving old, stale branches out to some historical repo and making sure official forks don't have any cruft? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Thoughts after hitting 100 merge requests?
On Thu, 2019-01-17 at 08:38 +0100, Erik Faye-Lund wrote: > On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote: > > All, > > > > The mesa project has now hit 100 merge requests (36 are still > > open). > > I (and I'm sure others) would be curious to hear people's initial > > thoughts on the process. What's working well? What's not > > working? > > Is it total fail and should we go back to mailing lists? > > > > So, overall I think it works pretty well. I have some things I think > maybe we could do better, some of which has already been pointed out: > > 1. New MRs should probably get their cover-letter automatically sent > to > the mailing list for incrased visibility. OK, I think that after having enabled e-mail notifications and spent some time setting up mail filters, this is much less of a pressing issue for me personally. I'm not even sure I think this is worth the time any more, as the notification support in GitLab is *really* good, and allows nice and finely-grained control, much better than what an automatic mail-bot could do. This doesn't mean that I would opose it, though. Just that I think I would strike this from *my* personal list of things to improve. > 2. Perhaps we should ban sending MRs from the main mesa repo? With > gitlab, it's trivial to make your own fork, and you can delegate > permissions to other users for collaborators. I don't think there's > any > reason to clutter up the main mesa repo with all kinds of branches. > But > it seems some people send their MRs from the main-repo anyway. > Perhaps > we should document that this isn't how to send MRs? I've sent out a patch to add a note about this. > 3. There's some browsing-pain with the commit list. For instance, I > always second-guess if the latest commit is at the top or bottom. > Some > times this is not a problem due to timestamps, but sometimes this > isn't > clear from that either. I also tend to get a bit lost in context. > Some > of this is probably habit, though. > And I don't really think this is a big deal, especially after the discussion on this point below; GitHub is the oddball here, and that's not GitLab's fault. So all in all, I think all of my issues with the process has been resolved (assuming we land the patch with the MR-note in some form, and if we don't that's probably also for a good reason). So from my point of view, I would love to see us move to a MR-only workflow as soon as possible. Doing both is a little bit messy (as was anticipated). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: add note about sending merge-requests from forks
Sending MRs from the main Mesa repository increase clutter in the repository, and decrease visibility of project-wide branches. So it's better if MRs are sent from forks instead. Let's add a note about this, in case its not obvious to everyone. Signed-off-by: Erik Faye-Lund --- docs/submittingpatches.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html index 736cbd64de8..b5a70523acd 100644 --- a/docs/submittingpatches.html +++ b/docs/submittingpatches.html @@ -258,6 +258,8 @@ your email administrator for this.) rebased Make sure your MR is closed if your patches get pushed outside of GitLab +Please send MRs from a personal fork rather than from the main + Mesa repository -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
