search for: mappabl

Dynamically resizing the framebuffer on nv04 was like playing Russian roulette (and it often happened gratuitously) because it seems unable to scan out from buffers above 16MB. This patch splits the mappable VRAM into two chunks when that's the case, and makes the higher one to be used as well when applicable. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 24 ++++++++++++++++++++++-- drivers/gpu/drm/nouveau/nouveau_drv.c | 2 ++...

...uct ttm_bo_device *bdev, struct ttm_mem_reg *mem) } static int -nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo) -{ - struct nouveau_drm *drm = nouveau_bdev(bo->bdev); - struct nouveau_bo *nvbo = nouveau_bo(bo); - struct nouveau_device *device = nv_device(drm->device); - u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT; - - /* as long as the bo isn't in vram, and isn't tiled, we've got - * nothing to do here. - */ - if (bo->mem.mem_type != TTM_PL_VRAM) { - if (nv_device(drm->device)->card_type < NV_50 || - !nouveau_bo_tile...

.../gpu/drm/nouveau/nouveau_bo.c index d506da5..762bfcd 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -1346,14 +1361,13 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo) struct nouveau_device *device = nv_device(drm->device); u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT; - /* as long as the bo isn't in vram, and isn't tiled, we've got - * nothing to do here. + /* + * if the bo is not in vram, or remapping can be done (nv50+) + * do not worry about placement, any location is valid */ -...

...00 __debug_ranges_end 0000000000000000 g .debug_ranges 0000000000000000 __debug_ranges_start 000000000000399f g .debug_str 0000000000000000 __debug_str_end 0000000000000000 g .debug_str 0000000000000000 __debug_str_start is there a workaround to force LLD to make these sections mappable/loadable so that the executable can access them? Regards, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/att...

...static int > -nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo) > -{ > - struct nouveau_drm *drm = nouveau_bdev(bo->bdev); > - struct nouveau_bo *nvbo = nouveau_bo(bo); > - struct nouveau_device *device = nv_device(drm->device); > - u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT; > - > - /* as long as the bo isn't in vram, and isn't tiled, we've got > - * nothing to do here. > - */ > - if (bo->mem.mem_type != TTM_PL_VRAM) { > - if (nv_device(...

...506da5..762bfcd 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c > @@ -1346,14 +1361,13 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo) > struct nouveau_device *device = nv_device(drm->device); > u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT; > > - /* as long as the bo isn't in vram, and isn't tiled, we've got > - * nothing to do here. > + /* > + * if the bo is not in vram, or remapping can be done (nv50+) > + * do...

I think Eli made a good point. In addition to that, if you are writing a OS kernel, I guess you are also writing a loader, so you can map anything as you want, no? On Mon, Dec 3, 2018 at 2:06 PM Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 12/3/2018 12:34 PM, Andrew Kelley via llvm-dev wrote: > > Context: https://bugs.llvm.org/show_bug.cgi?id=39862 >

...= mem->mm_node; ret = bar->umap(bar, node, NV_MEM_ACCESS_RW, &node->bar_vma); @@ -1324,6 +1327,7 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo) struct nouveau_bo *nvbo = nouveau_bo(bo); struct nouveau_device *device = nv_device(drm->device); u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT; + int ret; /* as long as the bo isn't in vram, and isn't tiled, we've got * nothing to do here. @@ -1332,10 +1336,20 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo) if (nv_device(drm->device)-&gt...

...rivers/gpu/drm/nouveau/nouveau_bo.c @@ -63,6 +63,8 @@ nouveau_bo_new(struct drm_device *dev, struct nouveau_channel *chan, nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL); if (!nvbo) return -ENOMEM; + INIT_LIST_HEAD(&nvbo->head); + INIT_LIST_HEAD(&nvbo->entry); nvbo->mappable = mappable; nvbo->no_vm = no_vm; nvbo->tile_mode = tile_mode; diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c b/drivers/gpu/drm/nouveau/nouveau_channel.c index 382c5b5..6c31d7f 100644 --- a/drivers/gpu/drm/nouveau/nouveau_channel.c +++ b/drivers/gpu/drm/nouveau/nouveau_channel.c @...

...44 >> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c >> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c >> @@ -1346,14 +1361,13 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo) >> struct nouveau_device *device = nv_device(drm->device); >> u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT; >> >> - /* as long as the bo isn't in vram, and isn't tiled, we've got >> - * nothing to do here. >> + /* >> + * if the bo is not in vram, or remapping can be done (nv50+...

...n500 at yahoo.com> wrote: > > I guess the backends could know about the instructions. But I am not convinced why it is beneficial not to have ROR and ROL instructions within llvm. > I guess I could ask you the opposite question: What is the benefit of having these? They would have to be mappable to the source language in some way. I'm not sure about Ada, but I don't know of a "rotate" operator for any of the C variants, or any other high-level language. (This could be my lack of knowledge about other languages.) In C, you specify a rotate by doing shifts and bit-wise ope...

Hi Bill, > I guess I could ask you the opposite question: What is the benefit of > having these? They would have to be mappable to the source language in > some way. I'm not sure about Ada, but I don't know of a "rotate" > operator for any of the C variants, or any other high-level language.. Ada has rotate. Ciao, Duncan.

...e notes in [1] there was a plan to raise inline assembly blocks to the level of LLVM intrinsics or 'actual' LLVM IR. Is anyone aware of progress in this area? I'm aware that a complete solution in general is unlikely but a partial solution (that handles a subset of instructions directly mappable to the LLVM IR AST) could be very relevant. [1] http://nondot.org/sabre/LLVMNotes/InlineAsm.txt Thanks in advance, Marcelo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130614/8610fc36/attachment.html&gt...

I''m using Geokit gem to query mappable records within some distance to a mappable user. When geocoding an address such as "Madrid", lat&lng represent a point, in this case the center of the city. Suppose I have some records with location "Madrid", which are mapped with lat & lng to the center of the city....

Hi, I am in a situation where I am going to have to rewrite a working Ruby on Rails application in CakePHP with PHP5. I have a whole bunch of specs written with rspec, and I was wondering if it would be possible to somehow use these specs to test the Models and Controllers that I am rewriting in CakePHP. I am going to be basically just exactly duplicating the Rails application, with identical

--- On Tue, 2/3/09, Bill Wendling <isanbard at gmail.com> wrote: > From: Bill Wendling <isanbard at gmail.com> > Subject: Re: [LLVMdev] rol/ror llvm instruction set > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Cc: kasra_n500 at yahoo.com > Date: Tuesday, February 3, 2009, 2:52 PM > On Tue, Feb 3, 2009 at 2:45 PM, Dale Johannesen

On 07/02/2013 08:07:53 PM, Alexander Graf wrote: > > On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote: > > > 8. Open Issues > > > > -how to handle cases where VFIO is requested to handle > > a device where the valid, mappable range for a region > > is less than a page size. See example above where an > > advertised region in the DMA node is 4 bytes. If exposed > > to a guest VM, the guest has to be able to map a full page > > of I/O space which opens a potential security issue. &g...

On 07/02/2013 08:07:53 PM, Alexander Graf wrote: > > On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote: > > > 8. Open Issues > > > > -how to handle cases where VFIO is requested to handle > > a device where the valid, mappable range for a region > > is less than a page size. See example above where an > > advertised region in the DMA node is 4 bytes. If exposed > > to a guest VM, the guest has to be able to map a full page > > of I/O space which opens a potential security issue. &g...

How suitable do the developers think that LLVM would be as a code-generator for a dynamically typed langage? Would the lack of static type information make the traditional code optimizations performed by LLVM relatively ineffective? Sincerely, Rayiner Hashem

Hi Alex, That sounds like the sort of information that should be extractable from the debug information metadata. Once you're in LLVM IR, things like class names and source types are not guaranteed to be preserved in a reverse-mappable sort of way (from IR names to source names) in the IR itself. The debug information, however, is intended to do exactly that. -Jim On Oct 19, 2010, at 12:52 AM, Alexander Herz wrote: > Hi, > > we use the llvm to lower c++ code to c code which can be run through our abstract interpret...