search for: hlsl

...r of my proposals for this year's Google Summer of Code. (The first is on cfe-dev.) It was suggested to me by Dan Kegel (from the Wine project, they really want this). Title: Microsoft Direct3D shader bytecode backend Abstract: There is a distinct lack of open-source frameworks for compiling HLSL, the shader language used by Direct3D, into bytecode that D3D can understand. Currently, the only such framework is Ryan Gordon's MojoShader, whose HLSL compiler component is still under heavy development. By utilizing LLVM, it may be possible to generate high-performance shader code from HLSL,...

...Google Summer of Code. > (The first is on cfe-dev.) It was suggested to me by Dan Kegel (from the > Wine project, they really want this). > > Title: Microsoft Direct3D shader bytecode backend > > Abstract: > > There is a distinct lack of open-source frameworks for compiling HLSL, > the shader language used by Direct3D, into bytecode that D3D can > understand. Currently, the only such framework is Ryan Gordon's > MojoShader, whose HLSL compiler component is still under heavy > development. By utilizing LLVM, it may be possible to generate > high-performan...

...> (The first is on cfe-dev.) It was suggested to me by Dan Kegel (from the > Wine project, they really want this). > > Title: Microsoft Direct3D shader bytecode backend > > Abstract: > > There is a distinct lack of open-source frameworks for compiling HLSL, > the shader language used by Direct3D, into bytecode that D3D can > understand. Currently, the only such framework is Ryan Gordon's > MojoShader, whose HLSL compiler component is still under heavy > development. By utilizing LLVM, it may be possible to generate &gt...

...articularly >> in GPUs) that the IEEE version does. >> > > The IEEE version can also be expanded in LLVM IR. And for GPUs, many GPU > input languages leave the behavior on NaN unspecified, so it's not > obviously the best guide. > > > That’s not generally true. HLSL (DirectX), CUDA, OpenCL, and Metal all > have defined semantics for NaNs which include not propagating them through > min/max. GLSL (OpenGL) is the odd one out in this area. > > HLSL leaves it undefined: http://msdn.microsoft.com/en-us/library/windows/desktop/bb509624%28v=vs.85%29.asp...

...on cfe-dev.) It was suggested to me by Dan Kegel (from the >> Wine project, they really want this). >> >> Title: Microsoft Direct3D shader bytecode backend >> >> Abstract: >> >> There is a distinct lack of open-source frameworks for compiling HLSL, >> the shader language used by Direct3D, into bytecode that D3D can >> understand. Currently, the only such framework is Ryan Gordon's >> MojoShader, whose HLSL compiler component is still under heavy >> development. By utilizing LLVM, it may be possible to...

...olaris/whatever executable? 2.We have a source of some new fancy game that use pixelshader, verhexshaders and so on... Again - assuming this game, works perfectly under wine, would it be possible to compile the code with winelib, and if so - would that speed up the game by "translating" HLSL to GLSL during compilation (so the translation wouldn't have to occure "on the fly", when the program is running)? Thanks in advance. Best regards.

Would it be feasible to compile LLVM IR into shading language assembler? If so, is this already being done? This would provide the obvious benefits of not having to differentiate between GLSL and HLSL (et al.) and the pleasure of using some other language to write and test the shader's that have support as an LLVM frontend. I've googled and found nothing about this. The only LLVM and OpenGL talk I can find it about Apple using it in Leopard but I don't think that's the same thin...

...oes not have the wide hardware support (particularly in GPUs) that the IEEE version does. > > The IEEE version can also be expanded in LLVM IR. And for GPUs, many GPU input languages leave the behavior on NaN unspecified, so it's not obviously the best guide. That’s not generally true. HLSL (DirectX), CUDA, OpenCL, and Metal all have defined semantics for NaNs which include not propagating them through min/max. GLSL (OpenGL) is the odd one out in this area. —Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-...

I saw on the LLVM mailing list some time ago that something like this was desired for Wine (but it was talking about an LLVM backend then). I figured I'd contact you guys to tell you that I found something like this, MojoShader by Ryan Gordon (zlib licensed). http://icculus.org/mojoshader/ http://hg.icculus.org/icculus/mojoshader/ Sorry if someone already suggested this, or if something like

...yz src1.yxzw src2.zwxy which performs an addition that stores the result to the dst operated (each operarand is a vector type of four data elements) The instruction uses source swizzle modifiers and destination mask modifier. So if a language is capable of expressing such constructs (as GLSL, HLSL and few others are) I'd like to make sure that the code generator is actually capable of generating instructions with exactly those semantics. Right now vector operations utilizing swizzling and write masks in LLVM IR have to expressed with series of load/extractelement/instertelement/stor...

Hi Carter, I would strongly advise you against this direction. I’m aware of two directions that existing languages go in defining min/max operations: - IEEE 754, C, Fortran, Matlab, OpenCL, and HLSL all define it not to propagate NaNs - C++ (std::min/std::max) and OpenGL define it in the trinary operator manner: (a < b) ? a : b What you’re proposing does not match any existing languages that I’m aware of, and seems likely to hamper cross-language portability for you in the future. More ge...

...surfaces always setting DDSCAPS_VISIBLE. ddraw: Surfaces with DDSCAPS_3DDEVICE and DDSCAPS_ZBUFFER can't be render targets. Sven Baars (2): jscript: Update the Dutch translation. taskkill: Update the Dutch translation. Travis Athougies (4): d3dcompiler_43/tests: Added HLSL test suite. d3dcompiler_43/tests: Added order of operations test to HLSL test suite. d3dcompiler_43/tests: Added tests for conditional expressions to HLSL test suite. d3dcompiler_43/tests: Added float vector tests to HLSL test suite. Trygve Vea (5): msi: Updated Norwegian t...

I am trying to run RaiderZ, that is a alpha game. However, the game crashes when running the launcher. Here is the crash report: http://pastebin.com/EvHLKDA7 I have tried to identify the problem, there are something wrong with msvcr90.dll: Code: wine: Call from 0x7b83a802 to unimplemented function msvcr90.dll._byteswap_ulong, aborting wine: Unimplemented function msvcr90.dll._byteswap_ulong

...> which performs an addition that stores the result to the dst operated (each > operarand is a vector type of four data elements) The instruction uses source > swizzle modifiers and destination mask modifier. Right. > So if a language is capable of expressing such constructs (as GLSL, HLSL and > few others are) I'd like to make sure that the code generator is actually > capable of generating instructions with exactly those semantics. Ok. Are you planning to use the LLVM code generator, or roll your own? > Right now vector operations utilizing swizzling and write masks...

> On Feb 11, 2015, at 11:37 AM, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Feb 11, 2015 at 04:06:10PM +0000, Sam Kellett wrote: >> Would it be feasible to compile LLVM IR into shading language assembler? If >> so, is this already being done? >> > > The R600 backend does this in conjunction with the Open Source mesa3D > project:

...how to best represent them. So far, the strange (read: non-LLVM) things seem to be: - No pointers. - No traditional load and store concepts. - Only one type, v4f32. - No modifiable stack, no frame pointers, no calling conventions. - No variable-length loops. I can tell you for sure that the ATI HLSL compiler unwinds and unrolls everything, so that they don't have to deal with call and ret. Other than that, I don't know how to handle this stuff. ~ C.

[+CC Andy] Hi Elena, I don't have any fundamental issues with teaching SCEV about floating point types, but given this will be a major change, I think a high level roadmap should be discussed on llvm-dev before we start reviewing and committing changes. Here are some issues that I think are worth discussing: - Core motivation: why do we even care about optimizing floating point

...s so pardon the possibly stupid question) > in the example you gave, why do you need SCEV to analyze the > increment to vectorize the loop (i.e how does it help)? What are > some other concrete cases you'll want to optimize? > > > Graphics shading languages like GLSL or HLSL have floating point types as > the “default” types. Integers weren’t even added until later revisions of > GLSL. In that world, it’s not especially strange to imagine a loop counter > written in floating point. > But most of those are convertible to integer IVs which as Andy pointed...

On Tuesday 30 December 2008 15:30:35 Chris Lattner wrote: > On Dec 30, 2008, at 6:39 AM, Corbin Simpson wrote: > >> However, the special instrucions cannot directly be mapped to LLVM > >> IR, like > >> "min", the conversion involves in 'extract' the vector, create > >> less-than-compare, create 'select' instruction, and create

...sic CoInternetGetSecurityUrlEx implementation. urlmon/tests: Added pluggable protocol tests for CoInternetGetSecurityUrlEx. urlmon: Added pluggable protocol support to CoInternetGetSecurityUrlEx. Travis Athougies (2): d3dcompiler_43/tests: Fixed nonconformant C string literals in HLSL test suite. d3dcompiler_43/tests: Added error tests to HLSL test suite. Vincent Povirk (9): windowscodecs: Ignore the alpha channel of ICO files if it's empty. windowscodecs: Add a utility function for swapping 8-bit BGR/RGB data. windowscodecs: Support 8-bit RGB (as op...