TODO revision 1.1
1 - Acceleration 2 - Blits and solid fill 3 4 - XAA and the shadow buffer will not work together, because the 5 shadow buffer updates in the block handler, so if we got any XAA 6 calls in between, things would get messed up. 7 8 Current plan: 9 - Add our own damage tracker that produces raw rectangles 10 - Whenever it fires, submit the copy immediately 11 12 - Wrap the necessary ops in such a way that the original 13 implementation gets called first. The original implementation 14 will use fb, which will produce damage, which will get 15 submitted. 16 17 If we decide to accelerate a particular operation, first set 18 a flag that the immediately following damage event should not 19 result in spice protocol being sent. Ie., 20 21 on_op: 22 qxl->enable_copying = FALSE 23 24 call original; 25 26 send acceleration command 27 28 qxl->enable_copying = TRUE 29 30 Note damage is added before the drawing hits the framebuffer, so 31 it will have to be stored, then cleared 32 - in a block handler 33 - before accelerating 34 35 Ie., 36 37 on_op: 38 clear damage 39 disable damage reporting 40 call original (this will generate unreported damage and 41 paint to the shadow) 42 submit command 43 enable damage 44 45 It may be possible to use the shadow code if we added a 46 shadowReportNow() that would report any existing 47 damage. Ie., basically export shadowRedisplay() 48 49 1. Get damage added, out of CreateScreenResources 50 2. Make sure it works 51 3. Submit copies and disable shadow 52 4. Delete shadow 53 5. Wrap some of the ops, or use XAA? 54 55 The input we get is: 56 57 - First a damage notification: "I am going to draw here" 58 - Then maybe an exa notification 59 60 So the algorithm is. 61 62 Maintain a "to_copy" region to be copied into the device 63 64 - in damage, if there is anything in to_copy, copy it 65 66 - in block handler, if there is anything in to_copy, copy it 67 68 - in exa, if we manage to accelerate, delete to_copy. 69 70 Unfortunately, for core text, what happens is 71 - damage is produced for the glyph box 72 - solid fill is generated 73 - the glyph is drawn 74 And the algorithm above means the damage is thrown away. 75 76 - Coding style fixes 77 78 - Better malloc() implementation 79 - Take malloc() from the windows driver? 80 - Put blocks in a tree? 81 82 - Find out why it picks 8x6 rather than a reasonable mode 83 - Possibly has to do with the timings it reports. RandR only 84 allows 8x6 and 6x4. 85 86 - Only compile mmtest if glib is installed 87 Or maybe just get rid of mmtest.c 88 89 - Notes on offscreen pixmaps 90 91 Yaniv says that PCI resources is a concern and that it would be better 92 if we can use guest memory instead of video memory. I guess we can 93 do that, given a kernel driver that can allocate pinned memory. 94 95 - If/when we add hardware acceleration to pixman, pixman will need to 96 generate QXL protocol. This could be tricky because DRM assumes that 97 everything is a pixmap, but qxl explicitly has a framebuffer. Same 98 goes for cairo-drm. 99 100 - Hashing 101 102 QXL has a feature where it can send hash codes for pixmaps. Unfortunately 103 most of the pixmaps we use are very shortlived. But there may be a benefit 104 for the root pixmap (and in general for the (few) windows that have 105 a pixmap background). 106 107 - When copying from pixmap to framebuffer, right now we just copy 108 the bits from the fb allocated pixmap. 109 110 - With hashing, we need to copy it to video memory, hash it, then set the 111 "unique" field to that hash value (plus the QXL_CACHE 112 flag). Presumably we'll get a normal remove on it when it is no 113 longer in use. 114 115 - If we know an image is available in video memory already, we should just 116 submit it. There is no race condition here because the image is 117 ultimately removed from vmem by the driver. 118 119 (Note hash value could probably just be XID plus a serial number). 120 121 - So for the proof of concept we'll be hashing complete pixmaps every time 122 we submit them. 123 124 - Tiles 125 126 It may be beneficial to send pixmaps in smaller tiles, though Yaniv 127 says we will need atomic drawing to prevent tearing. 128 129 - Video 130 131 We should certainly support Xv. The scaled blits should be sent 132 as commands, rather than as software. Does spice support YUV images? 133 If not, then it probably should. 134 135 - Multi-monitor: 136 137 - Windows may not support more than dual-head, but we do support more than 138 dual-head in spice. This is why they do the multi-pci device. 139 140 Ie,. the claim is that Yaniv did not find any API that would 141 support more than two outputs per PCI device. (This seems dubious 142 given that four-head cards do exist). 143 144 - Linux multi-monitor configuration supports hotplug of monitors, 145 and you can't make up PCI devices from inside the driver. 146 147 - On windows the guest agent is responsible for setting the monitors 148 and resolutions. 149 150 - On linux we should support EDID information, and enabling and 151 disabling PCI devices on the fly is pretty difficult to deal with 152 in X. Ie., we would need working support for both GPU hotplug and 153 for shatter. This is just not happening in RHEL 5 or 6. 154 155 - Reading back EDID over the spice protocol would be necessary 156 because when you hit detect displays, that's what needs to happen. 157 158 Better acceleration: 159 160 - Given offscreen pixmaps, we should get rid of the shadow framebuffer. 161 If we have to fall back to software, we can use the drawing area to 162 get the area in question, then copy them to qxl_malloced memory, 163 then draw there, then finally send the bits. 164 165 -=-=-=-=- 166 167 Done: 168 169 Question: 170 171 - Submit cursor images 172 173 - Note: when we set a mode, all allocated memory should be considered 174 released. 175 176 - What is the "vram" PCI range used for? 177 178 As I read the Windows driver, it can be mapped with the ioctl 179 VIDEO_MAP_VIDEO_MEMORY. In driver.c it is mapped as pdev->fb, but 180 it is then never used for anything as far as I can tell. 181 182 Does Windows itself use that ioctl, and if so, for what. The area 183 is only 32K in size so it can't really be used for any realistic 184 bitmaps. 185 186 It's a required ioctl. I believe it's needed for DGA-like things. 187 I have no idea how the Windows driver manages syncing for that, 188 but I think we can safely ignore it. [ajax] 189 190 - Hook up randr if it isn't already 191 192 - Garbage collection 193 - Before every allocation? 194 - When we run out of memory? 195 - Whenever we overflow some fixed pool? 196 197 - Get rid of qxl_mem.h header; just use qxl.h 198 199 - Split out ring code into qxl_ring.c 200 201 - Don't keep the maps around that are just used in preinit 202 (Is there any real reason to not just do the CheckDevice in 203 ScreenInit?) 204 205 206
Indexes created Tue Oct 27 00:25:24 UTC 2026