Re: revenge of CALLOC_STRUCT
I've used it at least once too. Mike On Fri, 07 Jan 2022 17:20:11 -0800 Kenneth Graunke wrote: > I've definitely used the pipe_reference_described debugging code to > track down some issues when working on iris. > > --Ken > > On Monday, December 27, 2021 4:18:16 PM PST Marek Olšák wrote: > > I remember that it wasn't unusual on Windows to define malloc, calloc, > > strdup, and free macros to redirect those calls to custom wrappers. That > > would eliminate the need to have non-standard names like MALLOC. > > > > There is also the pipe_reference debug code. Is anybody using that? > > > > Marek > > > > On Sun., Dec. 26, 2021, 05:37 Jose Fonseca, wrote: > > > > > I believe that as long as the CALLOC_STRUCT continue to get paired with > > > right FREE call (or equivalent if these get renamed) either way should > > > work > > > for us. Whatever option proposed gets followed, there's a risk these can > > > get out of balanced, but the risk seems comparable. > > > > > > > > > For context, IIRC, the main reason these macros remain useful for VMware > > > is the sad state of memory debugging tools on Windows. AFAICT, best hope > > > of one day deprecating this would be use AddressSanitizer, which is > > > supported on MSVC [1], but unfortunately not yet on MinGW w/ GCC [2], and > > > we rely upon a lot for day-to-day development, using Linux > > > cross-compilation. Using MinGW w/ Clang cross compiler seems be a way to > > > overcome this difficulty, but that too was still in somewhat experimental > > > state when I last tried it. > > > > > > > > > Jose > > > > > > [1] > > > https://devblogs.microsoft.com/cppblog/asan-for-windows-x64-and-debug-build-support/ > > > [2] > > > https://stackoverflow.com/questions/67619314/cannot-use-fsanitize-address-in-mingw-compiler > > > -- > > > *From:* Dave Airlie > > > *Sent:* Wednesday, December 22, 2021 22:35 > > > *To:* mesa-dev ; Jose Fonseca < > > > jfons...@vmware.com>; Brian Paul > > > *Subject:* revenge of CALLOC_STRUCT > > > > > > Hey, > > > > > > Happy holidays, and as though to consider over the break, > > > > > > We have the vmware used MALLOC/FREE/CALLOC/CALLOC_STRUCT wrappers used > > > throughout gallium. > > > > > > We have ST_CALLOC_STRUCT in use in the mesa state tracker, not used in > > > gallium. > > > > > > Merging the state tracker into mesa proper, and even prior to this a > > > few CALLOC_STRUCT have started to leak into src/mesa/*. > > > > > > Now I don't think we want that, but CALLOC_STRUCT is a genuinely > > > useful macro on it's own, > > > I'm considering just defined a calloc_struct instead for the > > > non-gallium use that goes with malloc/calloc/free. > > > > > > Any opinions, or should mesa just get u_memory.h support for Xmas? > > > > > > Dave. > > > > > > pgpXntYJpSKDj.pgp Description: OpenPGP digital signature
Re: [Mesa-dev] vulkan video + beta header enables
I think maybe a simple policy like: * always disable them for release builds * require env vars to enable at runtime would be enough to avoid having distros pick them up and block people from "relying" on them. Otherwise Jason's comment on collaboration seems sufficient for doing updates to the headers/xml. Might just be something we work with a bit more ad-hoc as more people start to work on/with beta features too. On Thu, 4 Nov 2021 20:59:11 -0500 Jason Ekstrand wrote: > On Thu, Nov 4, 2021 at 8:53 PM Dave Airlie wrote: > > > > Just polling for opinions here on how best to move forward with > > enabling the provisional vulkan beta headers in Mesa and the fallout > > from doing so for people importing updated vulkan headers. > > > > Do we want to allow beta/provisional features in main? > > IMO, it's fine as long as you never land the final patch which flips > on the extension or, if you do, make sure it's very carefully guarded. > > > Do we want to do it only under a meson option that distros never enable? > > RADV_I_KNOW_IM_ASKING_FOR_BETA_FEATURES_WHICH_MAY_NOT_WORK= > > That way, it's harder to put in your .profile. :-P Honestly, though, > just leave the last patch which flips it on in an MR that doesn't get > merged until the extension is final. > > > If we do, who is responsible for updating the beta code on new header > > import, since the video headers are under quite regular changes? > > That needs to be a collaboration between the people working on the > beta feature. Thanks to all the XML code-gen we do, it's pretty hard > to update it one driver at a time. Maybe that'd be possible but > ugh > > --Jason
[Mesa-dev] GitLab Tag Proposal
Hi, I'd like to propose adding/changing two tags: * change `feature_request` -> `Feature` (this is barely used at present, so renaming shouldn't affect anyone negatively) * add `Bug` I would use these primarily for tagging open MRs so that reviewers can more appropriately prioritize bug fixes at a glance over (less urgent) feature implementations. They would also service the same feature for issues, though those are usually more obvious from the title anyway. Does anyone else think these would be useful? Mike
Re: [Mesa-dev] llvmpipe is OpenGL 4.5 conformant.
Congrats, that's huge! On Sat, 31 Oct 2020 06:24:32 +1000 Dave Airlie wrote: > Just to let everyone know, a month ago I submitted the 20.2 llvmpipe > driver for OpenGL 4.5 conformance under the SPI/X.org umbrella, and it > is now official[1]. > > Thanks to everyone who helped me drive this forward, and to all the > contributors both to llvmpipe and the general Mesa stack that enabled > this. > > Big shout out to Roland Scheidegger for helping review the mountain of > patches I produced in this effort. > > My next plans involved submitting lavapipe for Vulkan 1.0, it's at 99% > or so CTS, but there are line drawing, sampler accuracy and some snorm > blending failure I have to work out. > I also ran the OpenCL 3.0 conformance suite against clover/llvmpipe > yesterday and have some vague hopes of driving that to some sort of > completion. > > (for GL 4.6 only texture anisotropy is really missing, I've got > patches for SPIR-V support, in case someone was feeling adventurous). > > Dave. > > [1] > https://www.khronos.org/conformance/adopters/conformant-products/opengl#submission_272 > ___ > 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
