similar to: [PATCH] nv50/ir: only use FILE_LOCAL_MEMORY for temp arrays that use indirection

Reduces local memory usage in a lot of Metro 2033 Redux and a few KSP shaders: total local used in shared programs : 54116 -> 30372 (-43.88%) Probably modest advantage to execution, but it's an imporant prerequisite to dropping some of the TGSI optimizations done by the state tracker. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Seems like there ought to be a simpler

Use the dst temp variable which was used in the TGSI_FILE_OUTPUT case everywhere. This makes the code somewhat easier to reads and helps avoiding going over 80 chars with upcoming changes. This also brings the dst handling more in line with the src handling. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 12

On 1/29/2015 7:21 PM, Jatin Davey wrote: > [root at localhost ~]# lspci | grep RAID > 05:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 > 3108 [Invader] (rev 02) to get info out of those, you need to install MegaCli64 from LSI Logic, which has the ugliest command lines and output you've ever seen. I use the python script below, which I put in

On 2/16/2016 3:23 PM, Zube wrote: > Does anyone know what program can be used to query the RAID status > from the OS for an on-board LSI SAS 2308-4i? the 2308 isn't actually a megaraid, its a simple SAS HBA that has an optional raid mode IF its flashed with IR firmware... this only supports raid 0/1/10. I always(!) flash these with the IT firmware that turns them back into a

On 1/30/2015 9:44 AM, John R Pierce wrote: > On 1/29/2015 7:21 PM, Jatin Davey wrote: >> [root at localhost ~]# lspci | grep RAID >> 05:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 >> 3108 [Invader] (rev 02) > > to get info out of those, you need to install MegaCli64 from LSI > Logic, which has the ugliest command lines and output you've

Hi all, I have a dataset which includes 84 rows and 4313 columns. Starting from the 2nd row, each row represents a patient. The 1st column is for "arrayID" 2nd column is for "time" 3rd column is for "cancer" 4th column is for "patientID" Starting for the 5th columns, each

Add support for OpenCL global memory buffers, note this has only been tested with regular load and stores and likely needs more work for e.g. atomic ops. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 + .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 31 +++++++++++++++++-----

R-help, I would like to place nine (3X3) plots per page. I am not properly implement mfrow(3,3) in the script below: jpeg("xyplot.jpg") #names output file my_args <- commandArgs() #sets up to take args from dos batch command mfcol(3,3) #set page for 3X3 TEMPS <- c(-15,25,85)#list of temps VBATS <- c(3,3.6,4.7)#list of Bats BOARDS <-

Hi, On 16-03-16 11:37, Samuel Pitoiset wrote: > Could you please get rid of the cosmetic changes (eg. the switch ones)? > Because this doesn't really improve readability and in my opinion these changes should be eventually done in a separate patch. I need at least halve of those cosmetic changes, because half of them is not cosmetic, e.g. : - case FILE_MEMORY_BUFFER: code[1] =

Could you please get rid of the cosmetic changes (eg. the switch ones)? Because this doesn't really improve readability and in my opinion these changes should be eventually done in a separate patch. Other than that, this patch is : Reviewed-by: Samuel Pitoiset <samuel.pitoiset at gmail.com> Yes, this probably won't work as is for atomic operations but the lowering pass is

Hi All, I generate a pdf report that contains a table. The report is 14 pages, and it takes 20s to be rendered. Most of these 20s are spend in the render_on method. I wonder if it is possible to speed up that process? To create the report, I do the following: 1) Setup pdf layout: # Setup pdf layout pdf.select_font("Helvetica", { :encoding => "WinAnsiEncoding"})

OK, so there's a bunch of stuff in here. The geometry stuff is based on the work started by Bryan Cain and Christoph Bumiller. Patches 01-12: Add support for geometry shaders and fix related issues Patches 13-14: Make it possible for fb clears to operate on texture attachments with an explicit layer set (as is allowed in gl 3.2). Patches 15-17: Make ARB_texture_multisample work

Does anyone know what program can be used to query the RAID status from the OS for an on-board LSI SAS 2308-4i? On this page: http://docs.avagotech.com/docs/12351997 there is a curious note on the left that reads: "Integrated MegaRAID support available upon request" After one mostly fruitless round of chatting with LSI/Avago/Broadcom and one completely fruitless round of chatting

On 1/30/2015 1:53 AM, Gordon Messmer wrote: > On 01/29/2015 05:07 AM, Jatin Davey wrote: >> Yes , it is a SATA disk. I am not sure of the speed. Can you tell me >> how to find out this information ? Additionally we are using RAID 10 >> configuration with 4 disks. > > What RAID controller are you using? > > # lspci | grep RAID [Jatin] [root at localhost ~]# lspci |

On Thursday 02 November 2017 14:10:25 Bowie Bailey wrote: > If you want raid 5 or 6, then you should get a hardware controller. For > raid 1, mdadm should work just fine.? I would suggest trying it before > buying a raid controller.? If it works for you, you save a few hundred > dollars and you have one less piece of hardware to worry about. > > I haven't looked at them in

I just had an IBM in a remote location with a hardware raid1 have both drives go bad. With local machines I probably would have caught it from the drive light before the 2nd one died... What is the state of the art in linux software monitoring for this? Long ago when that box was set up I think the best I could have done was a Java GUI tool that IBM had for their servers - and that seemed like

Make use of tgsi_shader_info to determine how many nv50_regs we need to allocate, if program uses KIL, or writes DEPR. --- src/gallium/drivers/nv50/nv50_program.c | 284 ++++++++++++++----------------- 1 files changed, 129 insertions(+), 155 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_program.c b/src/gallium/drivers/nv50/nv50_program.c index e2adeca..c8157f1 100644 ---

This fixes the previous patches, and add some debugging output if NV50_PROGRAM_DUMP is un-commented. Will merge this into the patches, later. --- src/gallium/drivers/nv50/nv50_program.c | 94 +++++++++++++++++++------------ 1 files changed, 58 insertions(+), 36 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_program.c b/src/gallium/drivers/nv50/nv50_program.c index 4b05075..caf03c9

tgsi_default_instruction_memory / tgsi_build_instruction_memory were returning uninitialized memory for tgsi_instruction_memory.Texture and tgsi_instruction_memory.Format. Note 0 means not set, and thus is a correct default initializer for these. Fixes: 3243b6fc97 ("tgsi: add Texture and Format to tgsi_instruction_memory") Cc: Nicolai Hähnle <nicolai.haehnle at amd.com>

We're going to try to reorder the scalar ops of a vector instr to accomodate swizzles that would otherwise require us to emit to an additional TEMP first (like MOV R0.xy, R0.zx). --- src/gallium/drivers/nv50/nv50_program.c | 148 ++++++++++++++++++++++++------ 1 files changed, 118 insertions(+), 30 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_program.c