May 2023 - Wine-GitLab - list.winehq.org

[PATCH v8 0/4] MR2387: winegstreamer: Use stream format in stream_props_GetMediaType.
by Ziqing Hui (＠zhui) May 1, 2023

May 1, 2023

According to the tests in 23b72ad, when we are reading a compressed stream, the type returned by `stream_props_GetMediaType()` should reflect compressed format even if we finnally output uncomressed data. For example, if we use wmvcore reader to read a WMV3 stream and output RGB24, the format information returned by `stream_props_GetMediaType()` should be WMV3, not RGB24. -- v8: winegstreamer: Use codec format in stream_props_GetMediaType. https://gitlab.winehq.org/wine/wine/-/merge_requests/2387

3 6

Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.
by Zebediah Figura (＠zfigura) May 1, 2023

May 1, 2023

> > > If we want it to be usable for things like disassembly (and assembly), we need v_s_i to be able to express everything that *any* frontend or backend can. > > And I don't think we want it, it would be unmanageable. > > > should v-s IR exist just as a common, "neutral" format, and then we'd have basically frontend- and/or backend-specific IR that we'd do passes over? > > Ideally this would feel a good design to me. Though I would say that it is not a hard requirement for frontends and backends to have their specific IR, even if it is conceivable that past a certain complexity threshold it is difficult to do without. Also, my idea is that you can do passes over {front,back}end specific IRs, but also over the common IR. At least, I'd design the common IR in such a way that they can be done. This is what I originally thought, but I'm having slight second thoughts now. The thing is that the tradeoff is now you need a new IR for every bytecode language you have, which in our case means at least sm1, sm4, and eventually I think sm6. That's a lot of extra support code to add. Consider how much we'd need to add by putting that intermediate step into HLSL -> smX translation. The advantage of making v_s_i the IR is that you don't actually need any of that. It does feel conceptually ugly to have a CISC IR, but looking past that, I'm not sure it's that bad? Some additions (new opcodes, new register types) aren't a problem, since the backends can just vkd3d_shader_error(). Some additions (new source fields, new instruction flags) are worse, though, since now you need to make sure that nothing else cares... It may also not be that much of a concern if the number of languages we have doesn't actually grow that large. It may make sense to start with something underdesigned—which I think means CISC—and if that starts to get actually unwieldy, then we can start overdesigning a RISC IR to mediate. > In practice I see a number of difficulties: > > * Shaders are not just code; they also embed interface information (input and output signatures, uniforms, buffers, object bindings, ...) and other random metadata (for example for the hull shaders). Should this be representable in the common IR? We need *some* way to represent that information so it doesn't get lost, at least. I think we don't want side channels, to be clear: I think that there should be a point where all of the information relevant to a shader is represented in v_s_i format, including metadata. And contrary to the instructions themselves, I think we want this information to be in a relatively simple and well-designed form. In a sense, it doesn't need to be "complex" like the instructions since we're not doing optimization passes over it [if that makes sense]. I think Conor has basically been pushing v_s_i in this direction in order to accommodate sm6 (at least wrt semantics), and given the tribulations I've had to endure to get sm1 to work, I think that's the right approach. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31612

1 0

[PATCH v4 0/1] MR180: vkd3d-shader/hlsl: Partially implement static expressions evaluation.
by Nikolay Sivov (＠nsivov) May 1, 2023

May 1, 2023

-- v4: vkd3d-shader/hlsl: Partially implement static expressions evaluation. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/180

3 3

[PATCH 0/4] MR191: tests: Add more interesting HLSL tests for mipmap levels.
by Zebediah Figura (＠zfigura) May 1, 2023

May 1, 2023

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/191

2 4

[PATCH 0/3] MR2727: hrtfapo: Add CreateHrtfApo() stub.
by Mohamad Al-Jaf (＠maljaf) May 1, 2023

May 1, 2023

Needed by Britannia VR: Out of Your Mind. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2727

3 4

Re: [PATCH v2 0/3] MR2727: hrtfapo: Add CreateHrtfApo() stub.
by Zebediah Figura (＠zfigura) May 1, 2023

May 1, 2023

Zebediah Figura (@zfigura) commented about dlls/hrtfapo/main.c: > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "hrtfapoapi.h" > +#include "wine/debug.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(hrtfapo); Let's use the existing xaudio2 channel here. And in general, matching the style used in xaudio2 would probably be good. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2727#note_31599

1 0

Re: [PATCH v2 0/3] MR2727: hrtfapo: Add CreateHrtfApo() stub.
by Zebediah Figura (＠zfigura) May 1, 2023

May 1, 2023

Zebediah Figura (@zfigura) commented about include/hrtfapoapi.idl: > + float unityGainDistance; > + float cutoffDistance; > +} HrtfDistanceDecay; > + > +typedef struct HrtfApoInit > +{ > + HrtfDistanceDecay *distanceDecay; > + HrtfDirectivity *directivity; > +} HrtfApoInit; > + > +cpp_quote("STDAPI CreateHrtfApo(const HrtfApoInit *init, IXAPO **xapo);") > + > +[ > + object, > + uuid(15b3cd66-e9de-4464-b6e6-2bc3cf63d455), > + pointer_default(unique) You don't need the pointer_default(unique) attribute; it's the default. Yes, it's everywhere in Wine headers, but it's really unnecessary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2727#note_31597

1 0

Re: [PATCH v2 0/3] MR2727: hrtfapo: Add CreateHrtfApo() stub.
by Zebediah Figura (＠zfigura) May 1, 2023

May 1, 2023

Zebediah Figura (@zfigura) commented about include/hrtfapoapi.idl: > + HrtfDirectivity *directivity; > +} HrtfApoInit; > + > +cpp_quote("STDAPI CreateHrtfApo(const HrtfApoInit *init, IXAPO **xapo);") > + > +[ > + object, > + uuid(15b3cd66-e9de-4464-b6e6-2bc3cf63d455), > + pointer_default(unique) > +] > +interface IXAPOHrtfParameters : IUnknown > +{ > + HRESULT SetSourcePosition([in] const HrtfPosition *position); > + HRESULT SetSourceOrientation([in] const HrtfOrientation *orientation); > + HRESULT SetSourceGain([in] float gain); > + HRESULT SetEnvironment([in] HrtfEnvironment environment); You don't need these [in] attributes; they only matter for remoting. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2727#note_31598

1 0

Re: [PATCH v2 0/3] MR2727: hrtfapo: Add CreateHrtfApo() stub.
by Zebediah Figura (＠zfigura) May 1, 2023

May 1, 2023

Zebediah Figura (@zfigura) commented about include/hrtfapoapi.idl: > +typedef struct HrtfDistanceDecay > +{ > + HrtfDistanceDecayType type; > + float maxGain; > + float minGain; > + float unityGainDistance; > + float cutoffDistance; > +} HrtfDistanceDecay; > + > +typedef struct HrtfApoInit > +{ > + HrtfDistanceDecay *distanceDecay; > + HrtfDirectivity *directivity; > +} HrtfApoInit; > + > +cpp_quote("STDAPI CreateHrtfApo(const HrtfApoInit *init, IXAPO **xapo);") You can declare this directly in the IDL. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2727#note_31596

1 0