search for: mesa3d

...rd.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: http://www.mesa3d.org/ <http://www.mesa3d.org/> > > Mesa has a glsl frontend that is used to emit LLVM IR for newer AMD > GPUs, which is fed into the R600 backend to produce native GPU code. > > Besides hardware accelerated drivers, the Mesa3d project also comes...

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

So, basically, you allocate the rasterizer units according to the vertex shader, and when the fragment shader comes up, you say "write rasterizer output 4 to fragment input 1000000"? The current nouveau drivers can't do this. There are "routing" registers in hardware, but I think the nVidia proprietary driver (at least without GLSL) leaves them unaltered after

Attached are two patches with MSVC build enchancements. They are quite trivial, but were necessary to correctly link LLVM libraries with Mesa3D on Windows. Jose -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-to-build-against-static-MSVC-runtime.patch Type: text/x-patch Size: 2055 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100306/69a65259/attachm...

Alex wrote: > Hello. > > Sorry I am not sure this question should go to llvm or mesa3d-dev mailing > list, so I post it to both. > > I am writing a llvm backend for a modern graphics processor which has a ISA > very similar to that of Direct 3D. > > I am reading the code in Gallium-3D driver in a mesa3d branch, which > converts the shader programs (TGSI tokens)...

Zack Rusin wrote: >> Sure, it would be very reasonable to make these target-specific >> builtins when targeting a GPU, the same way we have target-specific >> builtins for SSE. > > Actually currently the plan is to have essentially a "two pass" LLVM IR. I > wanted the first one to never lower any of the GPU instructions so we'd have > intrinsics or

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 'insert- >> element' >> instruction. Using scalar operations

...Can I use the APP SDK to load the binary, > > perhaps through the CAL interfaces? How about the OpenCL binary interface? > > > > Hi Justin, > > The binary produced by this backend is meant to be consumed by AMD's Open > Source 3D/Compute drivers which are part of the Mesa3D[1] project. The > backend is integrated into the driver, so you don't need to compile > shaders offline. Currently we are using the backend for graphics and > compute shaders in our r600g driver (HD2xxx-HD6xxx GPUs) and for graphics > in our radeonsi (HD7xxx GPUs). In the future...

Chris Lattner wrote: > The direction we're going is to expose more and more vector operations in > LLVM IR. For example, compares and select are currently being worked on, > so you can do a comparison of two vectors which returns a vector of bools, > and use that as the compare value of a select instruction (selecting between > two vectors). This would allow implementing min

...>> The idea here is indeed to use an external stdint.h in MSVC builds. >> >> The problem is that everybody except Microsoft recognized the >> usefulness of stdint.h types [1], and they work around it for MSVC by >> defining the stdint.h types themselves. LLVM does it. Mesa3D did it >> too. But that won't work when two such projects try to interoperate -- >> you'll get errors that uint8_t/uint16_t/uint32_t/etc has been >> redefined. >> >> There is more than one way to address this. The solution I came up >> with was to make al...

...gt; executing it on an AMD GPU? Can I use the APP SDK to load the binary, > perhaps through the CAL interfaces? How about the OpenCL binary interface? > Hi Justin, The binary produced by this backend is meant to be consumed by AMD's Open Source 3D/Compute drivers which are part of the Mesa3D[1] project. The backend is integrated into the driver, so you don't need to compile shaders offline. Currently we are using the backend for graphics and compute shaders in our r600g driver (HD2xxx-HD6xxx GPUs) and for graphics in our radeonsi (HD7xxx GPUs). In the future we will use it for c...

...ow about the > > > > OpenCL binary > > interface? > > > > > > > > > > Hi Justin, > > > > > > The binary produced by this backend is meant to be consumed by AMD's > > > Open Source 3D/Compute drivers which are part of the Mesa3D[1] > > > project. The backend is integrated into the driver, so you don't > > > need to compile shaders offline. Currently we are using the backend > > > for graphics and compute shaders in our r600g driver (HD2xxx-HD6xxx > > > GPUs) and for graphics in our...

José Fonseca <jose.r.fonseca at gmail.com> writes: > Attached are two patches with MSVC build enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. [snip] > add_llvm_definitions( -D_SCL_SECURE_NO_DEPRECATE ) > + add_llvm_definitions( -D_SECURE_SCL=0 ) With this setting the default LLVM build becomes incompatible with libraries compiled with _SECURE_SCL=1 (which is the default setting). The right thing here is to use an...

..., > > > perhaps through the CAL interfaces? How about the OpenCL binary > interface? > > > > > > > Hi Justin, > > > > The binary produced by this backend is meant to be consumed by AMD's Open > > Source 3D/Compute drivers which are part of the Mesa3D[1] project. The > > backend is integrated into the driver, so you don't need to compile > > shaders offline. Currently we are using the backend for graphics and > > compute shaders in our r600g driver (HD2xxx-HD6xxx GPUs) and for graphics > > in our radeonsi (HD7xxx GP...

...enCL binary > > > interface? > > > > > > > > > > > > > Hi Justin, > > > > > > > > The binary produced by this backend is meant to be consumed by AMD's > > > > Open Source 3D/Compute drivers which are part of the Mesa3D[1] > > > > project. The backend is integrated into the driver, so you don't > > > > need to compile shaders offline. Currently we are using the backend > > > > for graphics and compute shaders in our r600g driver (HD2xxx-HD6xxx > > > > GPUs) and...

Hello. Sorry I am not sure this question should go to llvm or mesa3d-dev mailing list, so I post it to both. I am writing a llvm backend for a modern graphics processor which has a ISA very similar to that of Direct 3D. I am reading the code in Gallium-3D driver in a mesa3d branch, which converts the shader programs (TGSI tokens) to LLVM IR. For the shader instru...

...lar/llvm/snapshot/llvm-r600-initial-review.tar.gz > > The R600 backend is located in lib/Target/AMDIL > > > > First, a brief description of the backend: > > > > The r600 backend is being developed as a part of the Open Source compute > > stack in Mesa (http://www.mesa3d.org/), which uses the Gallium API. > > It uses large portions of the AMDIL backend which was open-sourced > > last December and you'll notice the TargetMachine for this backend > > (AMDGPUTargetMachine) is a sub-class of AMDILTargetMachine. We are also > > currently wor...

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

Currently the nv30 and nv40 Gallium drivers are very similar, and contain about 5000 lines of essentially duplicate code. I prepared a patchset (which can be found at http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) which gradually unifies the drivers, one file per the commit. A new "nvfx" directory is created, and unified files are put there one by one.

Le 06/03/2010 11:43, José Fonseca a écrit : > Attached are two patches with MSVC build enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. > > Jose > > Are you volontary trying to break everyone build (just to build your own project), or have you no idea of the effect of this change: +add_llvm_definitions( -D_SECURE_SCL=0 ) While I personnaly use this flag in all my projects, it should not be silently...